Re: [netmod] YANG definition of MAC address

Jan Lindblad <janl@tail-f.com> Wed, 01 April 2020 11:03 UTC

Return-Path: <janl@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3943A0837 for <netmod@ietfa.amsl.com>; Wed, 1 Apr 2020 04:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh4lzMOwdQr6 for <netmod@ietfa.amsl.com>; Wed, 1 Apr 2020 04:03:06 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DFBE93A08AB for <netmod@ietf.org>; Wed, 1 Apr 2020 04:03:05 -0700 (PDT)
Received: from [192.168.1.121] (213-67-237-150-no99.tbcn.telia.com [213.67.237.150]) by mail.tail-f.com (Postfix) with ESMTPSA id B3DA41AE0309; Wed, 1 Apr 2020 13:03:04 +0200 (CEST)
From: Jan Lindblad <janl@tail-f.com>
Message-Id: <AB8357CE-FFA4-4115-9453-10C0C02A1EE3@tail-f.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F6268073-316D-47A7-ABD8-25179B20D638"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 1 Apr 2020 13:03:04 +0200
In-Reply-To: <MN2PR11MB4366ABF427070927849E4A03B5C90@MN2PR11MB4366.namprd11.prod.outlook.com>
Cc: NetMod WG <netmod@ietf.org>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
References: <MN2PR11MB4366ABF427070927849E4A03B5C90@MN2PR11MB4366.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Fz6_ytPN2je5SIODwIi14-TI-84>
Subject: Re: [netmod] YANG definition of MAC address
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 11:03:08 -0000

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>