<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-sam-mac-address-as-string-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="MAC Strings">MAC Address as String</title>
    <seriesInfo name="Internet-Draft" value="draft-sam-mac-address-as-string-00"/>
    <author initials="S." surname="Mansfield" fullname="Scott Mansfield">
      <organization>Ericsson</organization>
      <address>
        <email>scott.mansfield@ericsson.com</email>
      </address>
    </author>
    <date year="2026" month="March" day="02"/>
    <area>OPS</area>
    <workgroup>NETMOD Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 35?>
<t>IETF and IEEE 802.1 have different patterns for mac addresses in their respective YANG types modules.  Therefore equivalent mac addresses may or may not match if a mac-address that uses the IETF datatype is compared to a mac-address that uses the IEEE datatype (and vise-versa).</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/samans/draft-sam-mac-address-as-string"/>.</t>
    </note>
  </front>
  <middle>
    <?line 37?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>MAC Address Formats in the IETF and IEEE YANG modules are different.</t>
    </section>
    <section anchor="problem-statement">
      <name>Problem Statement</name>
      <t>The IETF YANG module <xref target="RFC9911"/> and IEEE YANG <xref target="IEEE-802-1Qcw"/> module use a datatype of String to store MAC Addresses.  The issue is that the IETF and IEEE use different patterns and have different canonical forms, which leads to a situation where equivalent MAC Addresses will not match.</t>
      <t>This internet-draft is meant to document the issue, raise awareness, and identify potential solutions.</t>
      <t>For example, the following MAC Address is in IETF Canonical Format</t>
      <artwork><![CDATA[
   90-10-00-01-02-AA
]]></artwork>
      <t>For example, the following MAC Address is in IEEE Canonical Format</t>
      <artwork><![CDATA[
   90:10:00:01:02:aa
]]></artwork>
      <t>The MAC Address are equivalent, but will not match if used in an XPATH, or as a key, or any string comparison.</t>
      <t>There are several potential trouble spots in published IETF YANG modules.</t>
    </section>
    <section anchor="detail">
      <name>Detail</name>
      <section anchor="ietf-format">
        <name>IETF Format</name>
        <t>The IETF Format (from ietf-yang-types@2013-07-15.yang) used in the mac-address typedef is found below.</t>
        <artwork><![CDATA[
typedef mac-address {
 type string {
   pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
 }
 description
  "The mac-address type represents an IEEE 802 MAC address.
   The canonical representation uses lowercase characters.

   In the value set and its semantics, this type is equivalent
   to the MacAddress textual convention of the SMIv2.";
 reference
  "IEEE 802: IEEE Standard for Local and Metropolitan Area
             Networks: Overview and Architecture
   RFC 2579: Textual Conventions for SMIv2";
}
]]></artwork>
      </section>
      <section anchor="ieee-format">
        <name>IEEE Format</name>
        <t>The IEEE Format used in the mac-address typedef is found below.</t>
        <artwork><![CDATA[
typedef mac-address {
 type string {
   pattern "[0-9a-fA-F]{2}(-[0-9a-fA-F]{2}){5}";
 }
 description
   "The mac-address type represents a MAC address in the canonical
    format and hexadecimal format specified by IEEE Std 802. The
    hexadecimal representation uses uppercase characters.";
 reference
   "3.1, 8.1 of IEEE Std 802";
}
]]></artwork>
      </section>
    </section>
    <section anchor="options">
      <name>Options</name>
      <ul spacing="normal">
        <li>
          <t>Create a new mac-address type and deprecate the mac-address types in IETF and IEEE types files.</t>
        </li>
        <li>
          <t>Modify the mac-address patterns in both IETF and IEEE to be inclusive of everything, and fix the descriptions to warn the implementers about the issue with equivalence.</t>
        </li>
        <li>
          <t>Add something to the YANG language that will provide a way to indicate an "equivalence" pattern.</t>
        </li>
        <li>
          <t>Do what SMNP did, abandon strings and store the MAC Address as 6 octets and provide the ability to use a display hint style facility.</t>
        </li>
        <li>
          <t>Do Nothing</t>
        </li>
        <li>
          <t>Some other brilliant solution?</t>
        </li>
      </ul>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TODO Security</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="IEEE-802-1Qcw" target="https://doi.org/10.1109/IEEESTD.2023.10317806">
        <front>
          <title>IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks Amendment 36: YANG Data Models for Scheduled Traffic, Frame Preemption, and Per‐Stream Filtering and Policing</title>
          <author>
            <organization/>
          </author>
          <date year="2023" month="November" day="17"/>
        </front>
      </reference>
      <reference anchor="RFC9911">
        <front>
          <title>Common YANG Data Types</title>
          <author fullname="J. Schönwälder" initials="J." role="editor" surname="Schönwälder"/>
          <date month="December" year="2025"/>
          <abstract>
            <t>This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9911"/>
        <seriesInfo name="DOI" value="10.17487/RFC9911"/>
      </reference>
    </references>
    <?line 127?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA71X2Y7bRhZ9r6+4UB5iA02ZlOGlORgkSi+JgfQyIwHJIAiC
ElmUCiZZTFVRskboQT4h35gvyblFUi2pG5PkJYINk6y627nnLo6iSGQm1/Uy
pdYX0XshvPalSml0M72gaZ5b5RxJRzNvcWsk5GJh1bo/7z66kcikV0tjtynp
ujAiN1ktK2jJrSx85GQVVTKLZKcuki5yQTKKY6Ebm5K3rfOTOD6PJ8K1i0o7
p03ttw10fLiaXwtplUzp7n4mNsZ+XFrTNindXs1v7i7pO3yBMvqav4qPaosr
OeRqr2ytfHTJTgjhvKzzn2RpaijdKidcJa3/6efWeOVSqo1odEo/eJOdkTPW
W1U4PG0rfvhRCNn6lbGpoEgQfrqG0GxMN7J2hVZlHr52Yc8y4/3JibFLWev/
So/AUrqyOnPO1OFIVVKXKTmWGleD1JeqvzPOTCVEbWwF4bVKhWCQH9+g4cPV
1VX0Pp5Eyb+yTRqUEg2Z5EOkCtFLmxMk6VuTyZLwgW6Ut6YxpcYxTQEy3SrP
ELso+srqfKlcuNc95/tTmlaqzvHX0+u3Kf1nevs1XUov6cbkqnTByixbqbwt
ITVHBgoNXK8t8KF7q1TVMBBnQfm9sr/98ivIpGRF17pE3jif4QiuZYF4XUw5
iJbSJJ68jpIkSt4NoUq7VD6llfeNS1+9yo0eA/BXSTxOkvj8FUMwm1+OWXCc
xK+Td+/jt0KIKIpILkBGmXnBRAtGA2BAc5zQSq4V5boolOVYG+mZVF18oDT1
lAZKuia/UtoS3huVcW46WJjFjirDULgx0XwFXZBXpH5u9VqWrPhYVyW3FAxs
QUs+9NmKdEGSDsoI5qSnlu/DcCgThkeyPdKOwJoGZZOTN38giGj3gi8YgLV2
Klor6+TLccCo0nleKiE+46qyCCXj7Alx2CSuAyUHIOgYzYBEjwHBq0dMx6z1
3ppFqSpmqVfMKiHmg44DUdrtvvj39cX5eZI8PJwo3+2OigDnvQwCRfz7AE3R
ty3GxXnOw0EUQ4YAoGsDjAGspwGx1md4wecnnMlkbWrNBcdFi5ayWWmks1Qy
d11unPZt6As4Use8OHKNNrosHxkxZpA0A943utBt2edKSchCNxpxG4rUDyGd
kZWaEdkgCzXUdiWoc9zSxZYadEM8wVtnypadcrCD3JL6JKumhALWVZiyNBtG
8ZACwZkOqIt91B0vhPgfflyu53GUxOj8UZxESNZ02p38VRvIwf+zkSZxGuNP
ksaTVMreBmf2aLAdoX1Gi9afgMxlh1znbBQt8vv76fybMy5OzERJGDbdS72l
bqT1Zae5bwd7sMBWnEI9wdNHfFFHLUhPDp9CTA1etUPPfMJ7F4rkUnnMCTx9
1l0Ygt5XSveBXhTWVKQV5vlWYsiGBvTlJE5eR/G7KHkz5q8v91Ex1EfdAddz
VTDQhWnBjYVCGsY9uMPpocROBKEBgR1noK8I+vyHODqXUTGNrn/cTR5epMfv
L3dvHj7/h6AHQblymdVhLEDBaP6MW+itDV4AIFfavk+HlPb3xmycZR/Lbi/U
1VhofIhI2UyiELKV5O6PZjfuRmmHCBjRctZ8Vx4w6DCmkbnMMTt17xD+feQP
i6PoWPxGZgPHvPqE8i5BjHrNqYcL6EF8aXbzYT0ZjxA+BgI3i0xx5ENYKf2l
yd2Pwv43DGosTSDeWqtNkJrabKU9xlNr2Rahm9LkzbvzlOa9mxd7N/spzk7C
x4e+hAL74NYx+/Yf/iZajU5oFT2l1eg5Wv0JXh2yaQhkT6YAcrd8db0eHStX
ma769o7PPP01NjhEuB0ymId1gnkZFBxKPcfOtmmesvOUJzTCKnNG77GlgE+H
hg6zRXchdCciugBJPM/CGmR4AgFHk7MvvMs/m73H5r6fgt3nQocWFfHyxzPk
VHg/HSG/MH51qsSACzjLytbx1oRouFluUWX1shtPhf4UtB4kM8xODLEuQZrH
Bk86IIWNzrQHIw8dHTb3ZZopdhXViQlXqWBkqNrQckt0x1YuVTf5wzRorFlj
QgK6DVYyXNZ1rgNOqL3RgebRECubuIR/rGJ2c3uPfSBHKAsEgyR3jO62hW4F
8aeDydFbMki8724NHvA9udCo+uBHv9to15RwDKGAfn6LoVLILFzq/bg1IU4s
vDRD0IRXZWlhEZzmVWGY9V8wY2Yqay0bQCtwMGplxyAxv7u825+KsA1Ob6dP
r3F33G8eK4RSm+6mzIaFolu9FzL7yGqm2cfabPA/hSWLOLFL67ZagOn5P0eF
LJ0aPfTW5f4msvg7DLx7ob4OAAA=

-->

</rfc>
