Re: [netmod] YANG definition of MAC address

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=40cisco.com@dmarc.ietf.org> wrote:
> 
> 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 <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
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>