Re: [pim] [yang-doctors] Optional key support?

[Ladislav Lhotka <[e-mail]>]

On Wed, 2018-10-24 at 18:18 +0000, Acee Lindem (acee) wrote:
> Lada, Andy,
>  
> I guess I’m missing something in this discussion. Why is a key leaf with a
> defaulted value any more complex to deal with than a leaf with an explicitly
> specified value? I just don’t get it…

Neither do I. FWIW, I think I was in favor of implementing Y09-02 in YANG 1.1. 

Lada

>  
> Thanks,
> Acee
>  
> From: Andy Bierman <[e-mail]>
> Date: Wednesday, October 24, 2018 at 1:31 PM
> To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[e-mail]>
> Cc: Acee Lindem <[e-mail]>, Martin Bjorklund <[e-mail]>, Xufeng
> Liu <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, YANG Doctors <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [yang-doctors] Optional key support?
>  
>  
>  
> On Wed, Oct 24, 2018 at 8:56 AM, Robert Wilton <[e-mail]> wrote:
> > It looks like the final reason that it was not accepted was because the
> > change was regarded as being too big for YANG 1.1.  As such, it seems
> > reasonable for this issue to be on Yang.next and considered again.
> > 
> 
>  
> My objection to it was that it had a huge impact on the protocols and the
> implementations.
> The added complexity is not worth it.
>  
> It is not that hard to define a value that indicates "not really used".
> That is not the same as "use the default".  Doing this in an elegant way
> instead of ad-hoc requires coordinated solutions in YANG, protocols, and
> servers.
>  
> There are probably lots of complex YANG text changes because the concept of an
> instance (and an instance-identifier) is so different. Also augment, leafref,
> and other cross-model dependencies are impacted.
>  
>  
> > Thanks,
> > Rob
> 
>  
>  
>  
> Andy
>  
> > On 24/10/2018 15:53, Acee Lindem (acee) wrote:
> > > Read through the discussion and it is a shame we can't converge on a
> > > solution. Is YANG 1.0 compatibility the major issue?
> > > Thanks,
> > > Acee
> > > 
> > > On 10/24/18, 1:48 AM, "yang-doctors on behalf of Martin Bjorklund" <
> > > [e-mail] on behalf of [e-mail]> wrote:
> > > 
> > >      Andy Bierman <[e-mail]> wrote:
> > >      > Hi,
> > >      >
> > >      > It has been discussed before.
> > >      > It is already allowed for config=false nodes so the change would be
> > > to
> > >      > allow config=true nodes
> > >      > to have no keys.
> > >      >
> > >      > Each time it comes up, somebody mentions that
> > >      > (a) NETCONF/RESTCONF has no mechanism to delete all list entries
> > >      > (b) The client cannot create more than 1 entry. How does the server
> > > know
> > >      >      the next entry is a different instance or replacing the first
> > > instance?
> > >           I don't think these were the reasons.  See the proposal that was
> > > on
> > >      the table for 1.1:
> > >           
> > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10
> > >           and the discussion:
> > >           
> > > https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1&index=bwacmVipuJMakMFjDXXCZMXCTAA
> > >                     /martin
> > >                > What is the use-case for a config list without keys?
> > >      >
> > >      >
> > >      > Andy
> > >      >
> > >      >
> > >      > On Tue, Oct 23, 2018 at 2:16 PM, Reshad Rahman (rrahman) <
> > > [e-mail]>
> > >      > wrote:
> > >      >
> > >      > > <Changed subject>
> > >      > >
> > >      > >
> > >      > >
> > >      > > Hi Xufeng,
> > >      > >
> > >      > >
> > >      > >
> > >      > > I don’t know if this has been discussed for yang-next but it
> > > doesn’t seem
> > >      > > to be in the yang-next list. I believe optional keys were
> > > discussed for
> > >      > > YANG1.1, maybe others on the YD list remember…
> > >      > >
> > >      > > https://github.com/netmod-wg/yang-next/issues
> > >      > >
> > >      > >
> > >      > >
> > >      > > In this case, I believe it would have been useful to have that
> > >      > > functionality.
> > >      > >
> > >      > >
> > >      > >
> > >      > > Regards,
> > >      > >
> > >      > > Reshad.
> > >      > >
> > >      > >
> > >      > >
> > >      > > *From: *Xufeng Liu <[e-mail]>
> > >      > > *Date: *Tuesday, October 23, 2018 at 4:39 PM
> > >      > > *To: *"Reshad Rahman (rrahman)" <[e-mail]>
> > >      > > *Cc: *"[e-mail]" <[e-mail]>, Mahesh Sivakumar <
> > >      > > [e-mail]>, Stig Venaas <[e-mail]>,
> > > Guofeng <
> > >      > > [e-mail]>, Anish Peter <[e-mail]>, "
> > >      > > [e-mail]" <[e-mail]>, Liuyisong <
> > >      > > [e-mail]>, Pete McAllister <
> > > [e-mail]>, "
> > >      > > [e-mail]" <[e-mail]>
> > >      > > *Subject: *Re: [yang-doctors] [pim] Yangdoctors last call review
> > > of
> > >      > > draft-ietf-pim-igmp-mld-yang-07
> > >      > >
> > >      > >
> > >      > >
> > >      > > Hi Reshad and All,
> > >      > >
> > >      > >
> > >      > >
> > >      > > Do you think that it would be useful to eventually extend YANG
> > > spec to
> > >      > > allow an optional key with a default value? That would allow the
> > > user not
> > >      > > to enter the extra empty string, and make the model more user
> > > friendly.
> > >      > >
> > >      > >
> > >      > >
> > >      > > Thanks,
> > >      > >
> > >      > > - Xufeng
> > >      > >
> > >      > >
> > >      > >
> > >      > > On Fri, Oct 19, 2018 at 11:02 AM Reshad Rahman (rrahman) <
> > >      > > [e-mail]> wrote:
> > >      > >
> > >      > > Hi Xufeng,
> > >      > >
> > >      > >
> > >      > >
> > >      > > I think we should go with the solution proposed by Chris
> > > (attached) when
> > >      > > we last discussed this. I realize it’s not ideal but IMO it’s
> > > better than
> > >      > > other proposals.
> > >      > >
> > >      > >
> > >      > >
> > >      > > Regards,
> > >      > >
> > >      > > Reshad.
> > >      > >
> > >      > >
> > >      > >
> > >      > > *From: *yang-doctors <[e-mail]> on behalf of
> > > Xufeng
> > >      > > Liu <[e-mail]>
> > >      > > *Date: *Friday, October 19, 2018 at 9:21 AM
> > >      > > *To: *"[e-mail]" <[e-mail]>
> > >      > > *Cc: *Mahesh Sivakumar <[e-mail]>, Stig Venaas
> > > <
> > >      > > [e-mail]>, Guofeng <[e-mail]>, Anish Peter <
> > >      > > [e-mail]>, "[e-mail]" <
> > > [e-mail]>,
> > >      > > Liuyisong <[e-mail]>, Pete McAllister <
> > >      > > [e-mail]>, "[e-mail]" <[e-mail]>
> > >      > > *Subject: *Re: [yang-doctors] [pim] Yangdoctors last call review
> > > of
> > >      > > draft-ietf-pim-igmp-mld-yang-07
> > >      > >
> > >      > >
> > >      > >
> > >      > > Hi Jan,
> > >      > >
> > >      > >
> > >      > >
> > >      > > Thanks for reviewing.
> > >      > >
> > >      > > For #1, as discussed, there is no other better solution at the
> > > moment.
> > >      > > What would you suggest?
> > >      > >
> > >      > > Thanks.
> > >      > >
> > >      > > - Xufeng
> > >      > >
> > >      > >
> > >      > >
> > >      > > On Fri, Oct 19, 2018 at 4:25 AM Jan Lindblad <[e-mail]>
> > > wrote:
> > >      > >
> > >      > > Feng,
> > >      > >
> > >      > >
> > >      > >
> > >      > > Hi Jan,
> > >      > >
> > >      > >
> > >      > >
> > >      > > We updated  draft-ietf-pim-igmp-mld-yang according to the
> > > comments #2 ~
> > >      > > #7, while Xufeng and you had discussed about comment #1.
> > >      > >
> > >      > > Please review the draft, thanks a lot.
> > >      > >
> > >      > > https://www.ietf.org/id/draft-ietf-pim-igmp-mld-yang-08.txt
> > >      > >
> > >      > >
> > >      > >
> > >      > > Good. I looked through the points #2-#7 and find that the work
> > > group have
> > >      > > understood and fixed those issues. #1 still remains to be
> > > resolved. I can
> > >      > > do a full re-review of the module once that one has been resolved
> > > as well..
> > >      > > Are there any outstanding questions on how to fix #1?
> > >      > >
> > >      > >
> > >      > >
> > >      > > Best Regards,
> > >      > >
> > >      > > /jan
> > >      > >
> > >      > > --
> > >      > >
> > >      > > *Jan Lindblad*, [e-mail], [phone]
> > >      > >
> > >      > > Solutions Architect, Business Development, Tail-f
> > >      > >
> > >      > > Tail-f is now a part of Cisco
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > > Feng
> > >      > >
> > >      > >
> > >      > >
> > >      > > -----Original Message-----
> > >      > >
> > >      > > From: Jan Lindblad [mailto:[e-mail] <[e-mail]>]
> > >      > >
> > >      > > Sent: Monday, August 13, 2018 10:35 PM
> > >      > >
> > >      > > To: [e-mail]
> > >      > >
> > >      > > Cc: [e-mail]; [e-mail]; 
> > > [e-mail]
> > >      > >
> > >      > > Subject: Yangdoctors last call review of draft-ietf-pim-igmp-mld-
> > > yang-07
> > >      > >
> > >      > >
> > >      > >
> > >      > > Reviewer: Jan Lindblad
> > >      > >
> > >      > > Review result: On the Right Track
> > >      > >
> > >      > >
> > >      > >
> > >      > > This is my YANG-doctor review of draft-ietf-pim-igmp-mld-yang-07. 
> > > In the
> > >      > > spring, I did an early review of the -02 version.
> > >      > >
> > >      > >
> > >      > >
> > >      > > Most of the comments from the earlier review are still valid. In
> > > some ways
> > >      > > the document has progressed since -02, in many it has not, and in
> > > a few it
> > >      > > has deteriorated. In my judgement, the document is not ready for
> > > last call.
> > >      > > Many fundamentally important questions are still unresolved. Here
> > > are my
> > >      > > review comments in rough falling order of importance.
> > >      > >
> > >      > >
> > >      > >
> > >      > > #1 Improper augment of /rt:routing/rt:control-plane-protocols
> > >      > >
> > >      > >
> > >      > >
> > >      > > Quoted from section 3.1:
> > >      > >
> > >      > >    This model augments the core routing data model "ietf-routing"
> > >      > >
> > >      > >    specified in [RFC8349].  The IGMP model augments "/rt:routing/
> > >      > >
> > >      > >    rt:control-plane-protocols" as opposed to augmenting
> > > "/rt:routing/
> > >      > >
> > >      > >    rt:control-plane-protocols/rt:control-plane-protocol", as the
> > > latter
> > >      > >
> > >      > >    would allow multiple protocol instances, while the IGMP
> > > protocol is
> > >      > >
> > >      > >    designed to be enabled or disabled as a single protocol
> > > instance on
> > >      > >
> > >      > >    a network instance or a logical network element.
> > >      > >
> > >      > >
> > >      > >
> > >      > > The description above, and the actual augment statements in the
> > > YANG
> > >      > > module violate the principles described in RFC 8349, the ietf-
> > > routing.yang
> > >      > > module it augments. In RFC 8349, section 5.3.  Control-Plane
> > > Protocol, the
> > >      > > proper way of augmenting the routing module is described. The
> > > fact that
> > >      > > this is a singleton protocol instance doesn't change this.
> > > Section 5.3
> > >      > > describes singleton cases as well.
> > >      > >
> > >      > >
> > >      > >
> > >      > > Guofeng: Xufeng has discussed with Jan about the comment, and it
> > > is closed.
> > >      > >
> > >      > >
> > >      > >
> > >      > > #2 Incorrect vendor refinement model
> > >      > >
> > >      > >
> > >      > >
> > >      > > Quoted from section 2.2:
> > >      > >
> > >      > >    For the same reason, wide constant ranges (for example, timer
> > >      > >
> > >      > >    maximum and minimum) will be used in the model.  It is
> > > expected that
> > >      > >
> > >      > >    vendors will augment the model with any specific restrictions
> > > that
> > >      > >
> > >      > >    might be required. Vendors may also extend the features list
> > > with
> > >      > >
> > >      > >    proprietary extensions.
> > >      > >
> > >      > >
> > >      > >
> > >      > > This is not acceptable. The principle suggested does not foster
> > >      > > interoperability and useful standards. It is also not possible to
> > > do what
> > >      > > the paragraph suggests in YANG. This was pointed out in the -02
> > > review, and
> > >      > > a suggestion was given there on how to address the problem.
> > >      > >
> > >      > >
> > >      > >
> > >      > > Guofeng: We removed the paragraph above, and put the values
> > > discussed by
> > >      > > Mcast Design Team.
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > > #3 Top level structures not optional
> > >      > >
> > >      > >
> > >      > >
> > >      > > Quoted from section 2.3:
> > >      > >
> > >      > >    The current document contains IGMP and MLD as separate schema
> > >      > >
> > >      > >    branches in the structure. The reason for this is to make it
> > > easier
> > >      > >
> > >      > >    for implementations which may optionally choose to support
> > > specific
> > >      > >
> > >      > >    address families. And the names of objects may be different
> > > between
> > >      > >
> > >      > >    the IPv4 (IGMP) and IPv6 (MLD) address families.
> > >      > >
> > >      > >
> > >      > >
> > >      > > This problem was also pointed out in the -02 review. The author
> > > suggests
> > >      > > that implementing igmp and/or mld is optional. This is not
> > > reflected in the
> > >      > > YANG module, however. As currently modeled, both are currently
> > > mandatory to
> > >      > > implement. If-feature is used liberally in the module, and could
> > > be used
> > >      > > here as well.
> > >      > >
> > >      > >
> > >      > >
> > >      > > #4 Unclear meaning of optional leaves
> > >      > >
> > >      > >
> > >      > >
> > >      > > Quoted from section 3.1:
> > >      > >
> > >      > >    Where fields are not genuinely essential to protocol
> > > operation, they
> > >      > >
> > >      > >    are marked as optional. Some fields will be essential but have
> > > a
> > >      > >
> > >      > >    default specified, so that they need not be configured
> > > explicitly.
> > >      > >
> > >      > >
> > >      > >
> > >      > > In fact, in the current version of the module, every leaf is
> > > optional
> > >      > > (except keys, which cannot be optional). It is good to see the
> > > addition of
> > >      > > defaults in many cases, but many unclear cases remain. E.g. leaf
> > >      > > /igmp/global/enable is of type boolean. I understand what true
> > > and false
> > >      > > implies for this leaf. But what does it mean if it is not set at
> > > all?
> > >      > > Either add a default or describe the meaning in the description.
> > > Similarly,
> > >      > > if the leaf version is not set on an igmp or mld interface, or on
> > > the
> > >      > > interface-global level, what does that mean?
> > >      > >
> > >      > > Add default. require-router-alert? explicit-tracking? exclude-
> > > lite? Many
> > >      > > of these are used in NP-containers inheriting all the from the
> > > root, which
> > >      > > makes the use of mandatory highly discouraged in the current
> > > form. If the
> > >      > > RFC 8349 augmentation principles are followed, the concern around
> > > mandatory
> > >      > > falls, and some leafs with no sensible default could be marked
> > > mandatory
> > >      > > instead.
> > >      > >
> > >      > >
> > >      > >
> > >      > > #5 All optional state
> > >      > >
> > >      > >
> > >      > >
> > >      > > All state data is optional, which means a conforming server could
> > > very
> > >      > > well decide not to implement it. E.g. discontinuity-time is
> > > optional.
> > >      > > Should a manager count on this being available? A situation where
> > > every
> > >      > > leaf is optional is as nice and flexible for server implementors
> > > as it is
> > >      > > frustrating and complicated for manager implementors to consume.
> > > A YANG
> > >      > > model is an API contract and should consider the needs of both
> > > sides. The
> > >      > > way this has been designed reveals that no representation for the
> > > consumer
> > >      > > side of this model has been involved in the design. I would
> > > suggest
> > >      > > thinking through what is the most essential state data for a
> > > manager, and
> > >      > > make some leafs mandatory.
> > >      > >
> > >      > >
> > >      > >
> > >      > > #6 Abundant copy-paste
> > >      > >
> > >      > >
> > >      > >
> > >      > > There is abundant repetition in the YANG module. leaf version is
> > > defined 2
> > >      > > times for igmp with identical definitions, and two more for mld
> > > with
> > >      > > identical definitions. leaf enable is defined once for the
> > > interface
> > >      > > global-level, and with identical definition on the interface
> > > local level.
> > >      > > leaf last-member-query-interval, query-interval and half a dozen
> > > other
> > >      > > leaves are defined twice with identical definitions.
> > >      > >
> > >      > >
> > >      > >
> > >      > > #7 Leaf interface in the rpc clear*groups on line 1124, 1094 has
> > > type
> > >      > > string.
> > >      > >
> > >      > > Should be a leafref? Describe what values are valid. #8 Leaf
> > > group-policy,
> > >      > > source-policy on line 486, 527, 624, 689: type string. Should be
> > > leafref?
> > >      > >
> > >      > > Describe what values are valid. #9 Leaf group on line 705, 1101,
> > > 1131: Is
> > >      > > any
> > >      > >
> > >      > > ipv4/6 address ok, or only a multicast address? Model
> > > accordingly.
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > > *From:* pim [mailto:[e-mail] <[e-mail]>]
> > > *On
> > >      > > Behalf Of *Jan Lindblad
> > >      > > *Sent:* Tuesday, September 11, 2018 9:52 PM
> > >      > > *To:* Xufeng Liu <[e-mail]>
> > >      > > *Cc:* [e-mail]; ietf <[e-mail]>; [e-mail];
> > >      > > [e-mail]
> > >      > > *Subject:* Re: [pim] Yangdoctors last call review of
> > >      > > draft-ietf-pim-igmp-mld-yang-07
> > >      > >
> > >      > >
> > >      > >
> > >      > > Xufeng,
> > >      > >
> > >      > >
> > >      > >
> > >      > > Thanks for the review and valuable comments.
> > >      > >
> > >      > >
> > >      > >
> > >      > > In regard to item #1, there was a discussion thread among the
> > > Yang
> > >      > > Doctors, authors of RFC 8349, and Routing Area Yang Architecture
> > > Design
> > >      > > Team, as attached below.  The discussion occurred during the
> > > review of a
> > >      > > draft with the same issue as this one.
> > >      > >
> > >      > >
> > >      > >
> > >      > > I see, didn't know. Good. If this has been discussed to
> > > conclusion, then
> > >      > > you should of course go with that decision.
> > >      > >
> > >      > >
> > >      > >
> > >      > > As mentioned earlier, there are a few other singleton protocols
> > > mapped
> > >      > > into this structure, e.g. static. I think it would make sense to
> > > treat this
> > >      > > the same. Principle of least astonishment.
> > >      > >
> > >      > >
> > >      > >
> > >      > > Best Regards,
> > >      > >
> > >      > > /jan
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >      > > ================================
> > >      > >
> > >      > > 原始邮件
> > >      > > 发件人：XufengLiu <[e-mail]>
> > >      > > 收件人：Acee Lindem (acee) <[e-mail]>Christian Hopps <
> > > [e-mail]>Martin
> > >      > > Bjorklund <[e-mail]>
> > >      > > 抄送人：张征00007940;[e-mail] <[e-mail]>
> > >      > > 日 期 ：2018年02月20日 22:30
> > >      > > 主 题 ：RE: [yang-doctors] How to restrict to have
> > >      > > singlecontrol-plane-protocol instance
> > >      > > Using "" as the name is better, but I am not sure that it is good
> > > enough.
> > >      > > When we use ConfD to translate the model to a command line, if
> > > the option
> > >      > > "tailf:cli-expose-key-name" is not used, we will have:
> > >      > >
> > >      > > edit routing control-plane-protocols control-plane-protocol type
> > > msdp name
> > >      > > ''"
> > >      > >
> > >      > > If the option "tailf:cli-expose-key-name" is used, we will have:
> > >      > >
> > >      > > edit routing control-plane-protocols control-plane-protocol msdp
> > > ''"
> > >      > >
> > >      > > I am pretty sure that we would get a bug report on this, asking
> > > what is
> > >      > > the purpose to have: name ''", and requesting a suppression on
> > > the term,
> > >      > > but we do not have a good way to achieve.
> > >      > >
> > >      > > As a comparison, the option #3 will give:
> > >      > >
> > >      > > edit routing control-plane-protocols msdp
> > >      > >
> > >      > > This is the only acceptable solution so far. When a model is not
> > > usable by
> > >      > > the end-user, other considerations (such as augmentation
> > > convenience) will
> > >      > > not matter.
> > >      > >
> > >      > > Thanks,
> > >      > > - Xufeng
> > >      > >
> > >      > > > -----Original Message-----
> > >      > > > From: Acee Lindem (acee) [mailto:[e-mail]]
> > >      > > > Sent: Monday, February 19, 2018 1:35 PM
> > >      > > > To: Christian Hopps <[e-mail]>; Martin Bjorklund <
> > >      > > [e-mail]>
> > >      > > > Cc: Xufeng Liu <[e-mail]>; [e-mail];
> > > yang-
> > >      > > > [e-mail]
> > >      > > > Subject: Re: [yang-doctors] How to restrict to have single
> > > control-plane-
> > >      > > > protocol instance
> > >      > > >
> > >      > > >
> > >      > > >
> > >      > > > On 2/19/18, 5:02 AM, "Christian Hopps" <[e-mail]>
> > > wrote:
> > >      > > >
> > >      > > >
> > >      > > >     Martin Bjorklund <[e-mail]> writes:
> > >      > > >
> > >      > > >     > Hi,
> > >      > > >     >
> > >      > > >     > "Acee Lindem (acee)" <[e-mail]> wrote:
> > >      > > >     >> All,
> > >      > > >     >>
> > >      > > >     >> As seems to be the modus operandi for YANG issues, we
> > > have 3
> > >      > > separate
> > >      > > > opinions as to how a protocol only supporting a single instance
> > > should be
> > >      > > > realized.
> > >      > > >     >>
> > >      > > >     >>   1. Augment the existing control plane protocols list
> > > (RFC
> > >      > > 8022BIS)
> > >      > > >     >>   and specify in the description text that only a single
> > > instance
> > >      > > is
> > >      > > >     >>   supported.
> > >      > > >     >>   2. Augment the existing control plane protocols list
> > > (RFC
> > >      > > 8022BIS)
> > >      > > >     >>   and use a YANG 1.1 must() restriction as discussed by
> > > Martin and
> > >      > > >     >>   Lada.
> > >      > > >     >>   3. Augment the container one level up from the list
> > > for
> > >      > > singleton
> > >      > > >     >>   protocols (suggested by Xufeng).
> > >      > > >
> > >      > > >     > But I think there was also a proposal to require the
> > > single
> > >      > > instance
> > >      > > >     > to have a well-known name - but maybe this proposal is no
> > > longer on
> > >      > > >     > the table.
> > >      > > >
> > >      > > >     I actually liked this solution; however, instead of picking
> > > an
> > >      > > arbitrary "well-
> > >      > > > known" value for name, I would specify the 0 length string
> > > instead. I
> > >      > > think that
> > >      > > > reinforces the idea that this isn't actually a named instance.
> > > :)
> > >      > > >
> > >      > > >        augment "/rt:routing/rt:control-plane-protocols/"
> > >      > > >              + "rt:control-plane-protocol" {
> > >      > > >           when "derived-from-or-self(rt:type, 'msdp:msdp') and
> > > rt:name =
> > >      > > ''"  {
> > >      > > >           container msdp {
> > >      > > >
> > >      > > > One benefit of this solution is that it solves Xufeng's issue
> > > of what
> > >      > > the client uses
> > >      > > > as the instance name.
> > >      > > >
> > >      > > >
> > >      > > >     Thanks,
> > >      > > >     Chris.
> > >      > > >
> > >      > > >     >
> > >      > > >     >
> > >      > > >     > /martin
> > >      > > >     >
> > >      > > >     >
> > >      > > >     >> and #3. For #3, one determent would be that the control
> > > plane
> > >      > > protocols
> > >      > > > are in a location other than where they were originally
> > > envisioned and I
> > >      > > don't
> > >      > > > relish pulling RFC8022BIS off the RFC queue to document.
> > >      > > >     >>
> > >      > > >     >> Thanks,
> > >      > > >     >> Acee
> > >      > > >     >>
> > >      > > >     >> On 2/15/18, 8:39 AM, "Reshad Rahman (rrahman)" <
> > > [e-mail]
> > >      > > >
> > >      > > > wrote:
> > >      > > >     >>
> > >      > > >     >>     Hi Xufeng,
> > >      > > >     >>
> > >      > > >     >>     I think the intent of 8022bis was to have all
> > > protocols under
> > >      > > > /rt:routing/rt:control-plane-protocols/rt:control-plane-
> > > protocol. I
> > >      > > agree that
> > >      > > > forcing a name for a single-instance is cumbersome, but I think
> > > it is
> > >      > > too late to
> > >      > > > change tree hierachy organization at this point.
> > >      > > >     >>
> > >      > > >     >>     I will defer to other YDs and 8022bis authors on
> > > this.
> > >      > > >     >>
> > >      > > >     >>     Regards,
> > >      > > >     >>     Reshad.
> > >      > > >     >>
> > >      > > >     >>     On 2018-02-08, 9:48 AM, "Xufeng Liu" <
> > > [e-mail]>
> > >      > > wrote:
> > >      > > >     >>
> > >      > > >     >>         Hi All,
> > >      > > >     >>
> > >      > > >     >>         I feel that such a solution is still not clean
> > > enough to
> > >      > > outweigh the
> > >      > > > simple augmentation to "/rt:routing/rt:control-plane-
> > > protocols/".
> > >      > > >     >>
> > >      > > >     >>         Some considerations are:
> > >      > > >     >>
> > >      > > >     >>         - Name management: Neither the operator nor the
> > >      > > implementation
> > >      > > > wants to deal with the artificial name, whether it is
> > > hardcoded,
> > >      > > user-configured,
> > >      > > > or system-generated. When we implement such singleton protocol,
> > > we don't
> > >      > > > save a name anywhere.
> > >      > > >     >>         - The complexity of validation: The "when"
> > > statement is an
> > >      > > > unnecessary expense to the user and to the implementation,
> > > especially if
> > >      > > we
> > >      > > > need to check all instances.
> > >      > > >     >>         - Data tree query: If the singleton "MSDP" is
> > > mixed with
> > >      > > other protocol
> > >      > > > instances, it is less obvious or harder to search for.
> > > Depending on the
> > >      > > > implementation, it would be worse if the entire list needs to
> > > be
> > >      > > iterated.
> > >      > > >     >>         - Tree hierarchy  organization: I don't see too
> > > big a
> > >      > > problem with "all
> > >      > > > single-instance protocols under /rt:routing/rt:control-plane-
> > > protocols
> > >      > > and all
> > >      > > > the multi-instance ones under /rt:routing/rt:control-plane-
> > >      > > protocols/rt:control-
> > >      > > > plane-protocol". If necessary, some of the names can be
> > > adjusted.
> > >      > > >     >>
> > >      > > >     >>         Thanks,
> > >      > > >     >>         - Xufeng
> > >      > > >     >>
> > >      > > >     >>
> > >      > > >     >>         > -----Original Message-----
> > >      > > >     >>         > From: Reshad Rahman (rrahman) [mailto:
> > > [e-mail]
> > >      > > ]
> > >      > > >     >>         > Sent: Thursday, February 8, 2018 9:41 AM
> > >      > > >     >>         > To: Ladislav Lhotka <[e-mail]>; Martin
> > > Bjorklund
> > >      > > <mbj@tail-
> > >      > > > f.com>;
> > >      > > >     >>         > Acee Lindem (acee) <[e-mail]>
> > >      > > >     >>         > Cc: [e-mail]; 
> > > [e-mail];
> > >      > > Xufeng Liu
> > >      > > >     >>         > <[e-mail]>
> > >      > > >     >>         > Subject: Re: [yang-doctors] How to restrict to
> > > have
> > >      > > single control-
> > >      > > > plane-
> > >      > > >     >>         > protocol instance
> > >      > > >     >>         >
> > >      > > >     >>         > Thanks for the suggestions. I agree that hard-
> > > coding
> > >      > > the name is a
> > >      > > > bad idea,
> > >      > > >     >>         > glad that a cleaner way of doing this is
> > > possible.
> > >      > > >     >>         > - We can move the must statement up to
> > > restrict max of
> > >      > > 1 control-
> > >      > > > plane-
> > >      > > >     >>         > protocol instance of type msdp?
> > >      > > >     >>         > - Acee/Lada, should a note be added to section
> > > 5.3 of
> > >      > > 8022bis
> > >      > > > regarding how
> > >      > > >     >>         > to enforce single instance? How much of a
> > > concern is the
> > >      > > > performance
> > >      > > >     >>         > impact in this specific case?
> > >      > > >     >>         >
> > >      > > >     >>         > Regards,
> > >      > > >     >>         > Reshad.
> > >      > > >     >>         >
> > >      > > >     >>         > On 2018-02-08, 7:02 AM, "Ladislav Lhotka" <
> > >      > > [e-mail]> wrote:
> > >      > > >     >>         >
> > >      > > >     >>         >     On Thu, 2018-02-08 at 12:39 +0100, Martin
> > > Bjorklund
> > >      > > wrote:
> > >      > > >     >>         >     > "Acee Lindem (acee)" <[e-mail]>
> > > wrote:
> > >      > > >     >>         >     > > Hi Lada,
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > > On 2/8/18, 4:42 AM, "yang-doctors on
> > > behalf of
> > >      > > Ladislav
> > >      > > > Lhotka"
> > >      > > >     >>         > <yang-docto
> > >      > > >     >>         >     > [e-mail] on behalf of 
> > > [e-mail]>
> > >      > > wrote:
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     On Thu, 2018-02-08 at 09:20 +0100,
> > > Martin
> > >      > > Bjorklund wrote:
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > Hi,
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > "Reshad Rahman (rrahman)" <
> > >      > > [e-mail]> wrote:
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Hi YDs,
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > MSDP YANG authors want to
> > > enforce
> > >      > > single-instance of
> > >      > > > MSDP
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > control-plane protocol. The
> > > when
> > >      > > “rt:type =
> > >      > > > ‘msdp’“ allows
> > >      > > >     >>         > multiple
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > control-pane-protocol
> > > instances as long
> > >      > > as they have
> > >      > > > different
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > rt:name. The only workaround I
> > > thought
> > >      > > of is to have a
> > >      > > > when
> > >      > > >     >>         >     > statement
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > on the name in the top level
> > > container..
> > >      > > This would still
> > >      > > > multiple
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > control-plane-protocol
> > > instance of type
> > >      > > msdp but
> > >      > > > restricts the
> > >      > > >     >>         > name
> > >      > > >     >>         >     > to
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > a fixed name (msdp-protocol in
> > > this
> > >      > > case) for the top level
> > >      > > > msdp
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > container to exist. Any
> > > suggestions on
> > >      > > how to do this
> > >      > > > better?
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > Hard-coding a name like this is
> > > IMO a bad
> > >      > > idea.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > Better would be to simply state
> > > in text
> > >      > > that there MUST
> > >      > > > only be one
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > instance of this type.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > But you can also add a must
> > > statement
> > >      > > that enforces this:
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >    augment
> > > "/rt:routing/rt:control-plane-
> > >      > > protocols/"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >          + "rt:control-plane-
> > > protocol" {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >       when 'derived-from-or-
> > > self(rt:type,
> > >      > > "msdp:msdp"'  {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >      container msdp {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >        must
> > > 'count(/rt:routing/rt:control-
> > >      > > plane-protocols/'
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >           + '
> > >      > > rt:control-plane-protocol['
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >           + '
> > >      > > derived-from-or-sel(../rt:type, "msdp:msdp")])
> > >      > > > <=
> > >      > > >     >>         >     > 1'";
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > In general, you should be
> > > careful with
> > >      > > the usage of "count",
> > >      > > > since it
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > will loop through *all*
> > > instances in the
> > >      > > list every time.  If
> > >      > > > the list
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > is big, this can have a
> > > performance
> > >      > > impact.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     Instead of count(), it is possible
> > > to use
> > >      > > the so-called
> > >      > > > Muenchian
> > >      > > >     >>         >     > method:
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >         container msdp {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >           must "not(../preceding-
> > > sibling::rt:
> > >      > > control-plane-
> > >      > > > protocol["
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >              + "derived-from-or-
> > > self(rt:type,
> > >      > > 'msdp:msdp')])";
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >           ..
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >         }
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     It basically states that the
> > >      > > control-plane-protocol containing
> > >      > > > the
> > >      > > >     >>         >     > "msdp"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     container must not be preceded
> > > with a
> > >      > > control-plane-
> > >      > > > protocol entry
> > >      > > >     >>         > of
> > >      > > >     >>         >     > the
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     msdp:msdp type (or derived).
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > > This looks like an elegant solution.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > "elegant" as in "less obvious" ;)  It
> > > has the
> > >      > > same time complexity
> > >      > > > as
> > >      > > >     >>         >     > the count() solution.
> > >      > > >     >>         >
> > >      > > >     >>         >     It should be faster on the average - it
> > > has to scan
> > >      > > only preceding
> > >      > > > siblings of
> > >      > > >     >>         >     the MSDP protocol instance whereas count()
> > > always
> > >      > > has to check
> > >      > > > *all*
> > >      > > >     >>         > protocol
> > >      > > >     >>         >     instances.
> > >      > > >     >>         >
> > >      > > >     >>         >     It is true though that in XSLT this
> > > technique can
> > >      > > be made
> > >      > > > considerably
> > >      > > >     >>         > more
> > >      > > >     >>         >     efficient by using indexed keys.
> > >      > > >     >>         >
> > >      > > >     >>         >     Lada
> > >      > > >     >>         >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > However, since the key for the
> > >      > > control-plane-protocol  list is
> > >      > > > "type
> > >      > > >     >>         >     > name", won't it only work if the
> > > previous sibling
> > >      > > has a  "name"
> > >      > > > that
> > >      > > >     >>         >     > is precedes the one being added?
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > For each list entry that has this
> > > container, the
> > >      > > expression is
> > >      > > >     >>         >     > evaluated.  It will scan all preceding
> > > entries
> > >      > > and ensure that there
> > >      > > >     >>         >     > are none with this type.  So the order
> > > of the
> > >      > > entries doesn't
> > >      > > > matter;
> > >      > > >     >>         >     > if there are two with the same type, one
> > > of them
> > >      > > has to be
> > >      > > > before the
> > >      > > >     >>         >     > other.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > /martin
> > >      > > >     >>         >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > > Thanks,
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > > Acee
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     Lada
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > Also note that I use derived-
> > > from-or-self
> > >      > > instead of equality
> > >      > > > for the
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > identity.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > /martin
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Regards,
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Reshad.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >   augment
> > > "/rt:routing/rt:control-plane-
> > >      > > protocols/"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >         + "rt:control-plane-
> > > protocol" {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >      when "rt:type = ‘msdp’" 
> > > {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >       description
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >         "….”;
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >     }
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >     description "….";
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >     container msdp {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >       when "../rt:name =
> > >      > > ‘msdp-protocol’"  {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >         description
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >           "….";
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >       }
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >       description "MSDP top
> > > level
> > >      > > container.";
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > From: "Reshad Rahman
> > > (rrahman)" <
> > >      > > [e-mail]>
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Date: Monday, February 5, 2018
> > > at 6:25
> > >      > > PM
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > To: Xufeng Liu <
> > > [e-mail]>,
> > >      > > >     >>         > "[e-mail]"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > <[e-mail]>
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Cc: "[e-mail]" <
> > >      > > [e-mail]>,
> > >      > > > "Mahesh
> > >      > > >     >>         > Sivakumar
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > (masivaku)" <
> > > [e-mail]>,
> > >      > > > "[e-mail]"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > <[e-mail]>,
> > >      > > > "[e-mail]"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > <
> > > [e-mail]>,
> > >      > > > "[e-mail]"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > <[e-mail]>, "
> > >      > > [e-mail]"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > <[e-mail]>,
> > >      > > "tanmoy.kundu@alcatel-
> > >      > > >     >>         > lucent.com"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > <
> > > [e-mail]>,
> > >      > > >     >>         > "[e-mail]"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > <[e-mail]>,
> > > "Acee
> > >      > > Lindem (acee)"
> > >      > > >     >>         > <[e-mail]>
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Subject: Re: Hi all, about the
> > >      > > modification of MSDP YANG
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Hi Sandy and Xufeng,
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > I understand that you want
> > > only 1 MSDP
> > >      > > instance but I
> > >      > > > don’t think
> > >      > > >     >>         >     > that
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > justifies
> > > /rt:routing/rt:control-plane-protocols.
> > >      > > If we do
> > >      > > > that we
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > will end up with all single-
> > > instance
> > >      > > protocols under
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > /rt:routing/rt:control-plane-
> > > protocols
> > >      > > and all the multi-
> > >      > > > instance
> > >      > > >     >>         >     > ones
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > under
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > /rt:routing/rt:control-plane-
> > >      > > protocols/rt:control-plane-
> > >      > > > protocol.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > I am not sure what’s the best
> > > way to
> > >      > > enforce single-
> > >      > > > instance, I can
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > check with the other YDs on
> > > this topic..
> > >      > > One way it can be
> > >      > > > done is
> > >      > > >     >>         > as
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > follows (I’ve added the when
> > > statement
> > >      > > in bold to
> > >      > > > existing BFD
> > >      > > >     >>         >     > model),
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > it enforces that the protocol
> > > name is
> > >      > > ‘bfdv1’. So multiple
> > >      > > >     >>         > instances
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > with rt:type=bfd-types:bfdv1
> > > could be
> > >      > > created, but only
> > >      > > > one of
> > >      > > >     >>         > these
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > instances can have the bfd
> > > container.
> > >      > > This is probably not
> > >      > > > the
> > >      > > >     >>         > best
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > way but the point is that IMO
> > > protocols
> > >      > > have to go under
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > /rt:routing/rt:control-plane-
> > >      > > protocols/rt:control-plane-
> > >      > > > protocol.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Regards,
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Reshad.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >   augment
> > > "/rt:routing/rt:control-plane-
> > >      > > protocols/"
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >         + "rt:control-plane-
> > > protocol" {
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >      when "rt:type =
> 
>  
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67