Subject: [netmod] YANG definition of MAC address

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 1 Apr 2020 10:20:10 +0000

RFC 6991 defines MAC address using colons:

     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<https://tools.ietf.org/html/rfc2579>: Textual Conventions for SMIv2";

     }

IEEE has their own definition using dashes instead of colons, i.e. the pattern is "[0-9a-fA-F]{2}(-[0-9a-fA-F]{2}){5}".

E.g. from https://github.com/YangModels/yang/blob/master/standard/ieee/draft/802/ieee802-types.yang

There has been some suggestion from folks in IEEE that they would like us to deprecate the IETF definition and migrate to the IEEE definition.  However, this would end up being an NBC change and doesn't seem to be great from an interoperability POV.

Another, possibly more pragmatic, suggestion would be the change both definitions to accept either ":" or "-".   I.e. the pattern statement would become:  "[0-9a-fA-F]{2}([-:][0-9a-fA-F]{2}){5}";

What are folk's opinions of including this change in RFC 6991bis?

Thanks,
Rob

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Apr 2020 12:52:23 +0200

On 2020-04-01, at 12:20, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
> 
> Another, possibly more pragmatic, suggestion would be the change both definitions to accept either “:” or “-“.   I.e. the pattern statement would become:  "[0-9a-fA-F]{2}([-:][0-9a-fA-F]{2}){5}"

This isn’t backwards-compatible either?
Or would that only be done for future modules?

I don’t see the gain, but I see a lot of pain.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Apr 2020 13:01:08 +0200

> What are folk's opinions of including this change in RFC 6991bis?

As of today, you can't change the definition, you can only deprecate
it and create a new one. On the technical side, we like to have
canonical formats, so the debate what is the canonical format would
still exist, even if we allow both formats as valid inputs.

Given that the colon format has been around for way more than 20 years
(see for example RFC 2579, STD 58), this exercise seems like a waste
of energy, it might take multiple decades to get changes widely
implemented and deployed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 1 Apr 2020 13:03:04 +0200

Rob,

I can see the attraction in allowing both. It has a major drawback, though. If the mac address is used as a key in lists, it could easily happen that two values that differ only in hyphen/colonization would be accepted into the same list as distinct. That might break quite a few use cases.

I don't really care which notation is used, but FWIW googling for "mac address format hyphen" and "mac address format colon" gives about 5 times more hits for the latter.

Best Regards,
/jan

> On 1 Apr 2020, at 12:20, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
> 
>          RFC 2579 <https://tools.ietf.org/html/rfc2579>: Textual Conventions for SMIv2";
>      }
>  
> E.g. from https://github.com/YangModels/yang/blob/master/standard/ieee/draft/802/ieee802-types.yang <https://github.com/YangModels/yang/blob/master/standard/ieee/draft/802/ieee802-types.yang>
>  
> There has been some suggestion from folks in IEEE that they would like us to deprecate the IETF definition and migrate to the IEEE definition.  However, this would end up being an NBC change and doesn’t seem to be great from an interoperability POV.
>  
> Another, possibly more pragmatic, suggestion would be the change both definitions to accept either “:” or “-“.   I.e. the pattern statement would become:  "[0-9a-fA-F]{2}([-:][0-9a-fA-F]{2}){5}";
>  
> What are folk’s opinions of including this change in RFC 6991bis?
>  
> Thanks,
> Rob 
> _______________________________________________
> netmod mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 1 Apr 2020 14:25:22 +0000

> -----Original Message-----
> From: Juergen Schoenwaelder <[email-masked]>
> Sent: 01 April 2020 12:01
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: NetMod WG <[email-masked]>
> Subject: Re: YANG definition of MAC address
> 
> > IEEE has their own definition using dashes instead of colons, i.e. the
> pattern is "[0-9a-fA-F]{2}(-[0-9a-fA-F]{2}){5}".
> >
> > E.g. from
> > https://github.com/YangModels/yang/blob/master/standard/ieee/draft/802
> > /ieee802-types.yang
> >
> > There has been some suggestion from folks in IEEE that they would like
> us to deprecate the IETF definition and migrate to the IEEE definition.
> However, this would end up being an NBC change and doesn't seem to be
> great from an interoperability POV.
> >
> > Another, possibly more pragmatic, suggestion would be the change both
> definitions to accept either ":" or "-".   I.e. the pattern statement
> would become:  "[0-9a-fA-F]{2}([-:][0-9a-fA-F]{2}){5}";
> >
> As of today, you can't change the definition, you can only deprecate it
> and create a new one. On the technical side, we like to have canonical
> formats, so the debate what is the canonical format would still exist,
> even if we allow both formats as valid inputs.
[RW] 
I hadn't considered the canonical format/list key issue.  I will also point this out in the IEEE discussion.

> (see for example RFC 2579, STD 58), this exercise seems like a waste of
> energy, it might take multiple decades to get changes widely implemented
> and deployed.
[RW] 

Thanks.  Yes, I have made both of those points.

Regards,
Rob