Re: [ieee-ietf-coord] Augmentation of ieee802-dot1q-bridge (draft-ietf-pim-igmp-mld-snooping-yang)

ROBERT GROW <> Thu, 09 April 2020 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5994A3A0593; Thu, 9 Apr 2020 11:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EzARkLxzDW6K; Thu, 9 Apr 2020 11:16:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 887B73A0529; Thu, 9 Apr 2020 11:16:57 -0700 (PDT)
Received: from ([]) by cmsmtp with ESMTP id MYEOj0HFSEgURMbjUjLTo9; Thu, 09 Apr 2020 18:16:57 +0000
Received: from [] ([]) by cmsmtp with ESMTPSA id MbjSjoSQL5K3AMbjTjRFTE; Thu, 09 Apr 2020 18:16:56 +0000
Authentication-Results:; auth=pass (PLAIN)
X-Authority-Analysis: v=2.3 cv=bfUVr9HB c=1 sm=1 tr=0 a=muFRQQPKe3JH4BpxLpeSYA==:117 a=muFRQQPKe3JH4BpxLpeSYA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=HLvPDLHGFjgA:10 a=pGLkceISAAAA:8 a=kviXuzpPAAAA:8 a=48vgC7mUAAAA:8 a=xjz23IuolrubLDDdRkEA:9 a=R2PTdJTmboZb2ama:21 a=dQwZC35nv49FkxRF:21 a=QEXdDO2ut3YA:10 a=-RoEEKskQ1sA:10 a=JiWVJ68q7O6BJuYcrKEA:9 a=Y01fR3rTEOuvvQsD:21 a=R1JB_BKV33dfRo0F:21 a=bAzjvE32chPV5UtE:21 a=_W_S_7VecoQA:10 a=qrIFiuKZe2vaD64auk6j:22 a=w1C3t2QeGrPiZgrLijVG:22
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0EE954F3-D3FA-46FB-AC98-33E53F6F9C0F"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Thu, 9 Apr 2020 11:16:54 -0700
In-Reply-To: <>
Cc:,, "<>" <>
To: Alvaro Retana <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
X-CMAE-Envelope: MS4wfKlDQ/mucxWYoltPIrFXx2eQXP1c9xFiJHg3Ude0RQNNvBeocseHlduUl/Z3vsowuZfZ/83JwhgB+cfBXTdOqpL6+ppSZ4PL8ZgX6vRutGmgp0CXZCAf 1ssRtM8nRfyb0as3ULgGNUqhHV33AfbkgaTsKKff9ARo4YnpWICqJ3ZIVUINEFE8HNqMPPIP5Uk7gFvzfuC9ZG+oLYzcWXiQiIrIZ8vvMn/RNw6/h9T2he1r LS0RrlJ9QDHvav6d0tpOQs/Vf0BIiS5Gqyau27dayC1zE76TJQzNnua/AxIDZE9N4zpxWX5yZgmcGwccV5+q3A==
Archived-At: <>
Subject: Re: [ieee-ietf-coord] Augmentation of ieee802-dot1q-bridge (draft-ietf-pim-igmp-mld-snooping-yang)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Management-level discussions between IEEE and IETF on topics of interest to both SDOs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Apr 2020 18:16:59 -0000


I haven’t looked at your draft so was responding in general, not in specifics for snooping.  Both IEEE and IETF folk need to be comfortable with maintaining unique YANG management arcs.

For YANG and SNMP, we received an IEEE root assignment.  Within IEEE, extending one of those arcs is a self administered registry, the rules for which are specified in IEEE Std 802.  The YANG rules are in IEEE Std 802d-2017.  A snippet from 802c:

For example, in IEEE Std 802.1Q, a URN value for use in a YANG model would take the following form: urn:ieee:std:802.1Q:yang:{resourceIdentifier}
Or in IEEE Std 802.11, a URN value for use in a YANG model would take the following form: urn:ieee:std:802.11:yang:{resourceIdentifier} 

This allows each IEEE standard to define management arcs within their standard.  This relies on IEEE standards being given a unique number, but those numbers are obviously only unique with IEEE, not necessarily globally unique.  When a different standard uses the root arc (like the 802.1Q example quoted and assigns its own resourceIdentifier, the possibility of non unique strings being defined in two different standards gets significantly worse than it is for the one standard.  

We simply need to make sure we maintain unique names, and how to document it if there are common roots.  Then decide if that approach needs to be documented in IEEE Std 802.


> On Apr 9, 2020, at 8:52 AM, Alvaro Retana <> wrote:
> Bob:
> I’m adding the authors (and the chairs of the pim WG) who would have a much better clue about what you’re pointing out than me.
> As far as I can see, this is the relevant text:
>   import ieee802-dot1q-bridge {
>     prefix "dot1q";
>   }
> …
>   augment "/dot1q:bridges/dot1q:bridge" {
> …
>   augment "/dot1q:bridges/dot1q:bridge"+
>     "/dot1q:component/dot1q:bridge-vlan/dot1q:vlan" {
> I may of course be completely misunderstanding your point.
> Thanks!
> Alvaro.
> On April 8, 2020 at 7:25:03 PM, ROBERT GROW ( <>) wrote:
>> Alvaro:
>> The management arcs to be used certainly has to be understood.  If the urn arcs use the ieee root we definitely need additional coordination both with any IEEE subgroups included in the urn and I expect the RAC will be interested also.
>> —Bob Grow
>>> On Apr 8, 2020, at 3:33 PM, Alvaro Retana < <>> wrote:
>>> Mostly FYI…
>>> The pim WG has been working on a YANG model to configure and manage IGMP/MLD snooping devices [1].  The draft has passed WGLC and has been sent to the IESG for publication — I am the responsible AD and we’re waiting for the authors to address my comments before moving into IESG Evaluation.
>>> The new module (ietf-igmp-mld-snooping) augments ieee802-dot1q-bridge to enable snooping on a bridge, or a specific VLAN.
>>> This is the first YANG module that I process which augments an IEEE module, so I’m sending this note just in case there’s some type of additional coordination needed.  Please let me know.
>>> Thanks!!
>>> Alvaro.
>>> [1] <> 
>>> _______________________________________________
>>> ieee-ietf-coord mailing list
>>> <>
>>> <>
> _______________________________________________
> ieee-ietf-coord mailing list
> <>
> <>