Subject: [yang-doctors] Optional key support?

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 23 Oct 2018 21:16:27 +0000

<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 <[email-masked]>
Date: Tuesday, October 23, 2018 at 4:39 PM
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Mahesh Sivakumar <[email-masked]>, Stig Venaas <[email-masked]>, Guofeng <[email-masked]>, Anish Peter <[email-masked]>, "[email-masked]" <[email-masked]>, Liuyisong <[email-masked]>, Pete McAllister <[email-masked]>, "[email-masked]" <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> on behalf of Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 19, 2018 at 9:21 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Mahesh Sivakumar <[email-masked]<mailto:[email-masked]>>, Stig Venaas <[email-masked]<mailto:[email-masked]>>, Guofeng <[email-masked]<mailto:[email-masked]>>, Anish Peter <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Liuyisong <[email-masked]<mailto:[email-masked]>>, Pete McAllister <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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, [email-masked]<mailto:[email-masked]>, +46 702855728
Solutions Architect, Business Development, Tail-f
Tail-f is now a part of Cisco

Feng

-----Original Message-----
From: Jan Lindblad [mailto:[email-masked]]
Sent: Monday, August 13, 2018 10:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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:[email-masked]] On Behalf Of Jan Lindblad
Sent: Tuesday, September 11, 2018 9:52 PM
To: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; ietf <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>
收件人：Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>Christian Hopps <[email-masked]<mailto:[email-masked]>>Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
抄送人：张征00007940;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
日 期 ：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:[email-masked]<mailto:[email-masked]>]
> Sent: Monday, February 19, 2018 1:35 PM
> To: Christian Hopps <[email-masked]<mailto:[email-masked]>>; Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
> Cc: Xufeng Liu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; yang-
> [email-masked]<mailto:[email-masked]>
> Subject: Re: [yang-doctors] How to restrict to have single control-plane-
> protocol instance
>
>
>
> On 2/19/18, 5:02 AM, "Christian Hopps" <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>     Martin Bjorklund <[email-masked]<mailto:[email-masked]>> writes:
>
>     > Hi,
>     >
>     > "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> 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)" <[email-masked]<mailto:[email-masked]>>
> 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" <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
>     >>         > Sent: Thursday, February 8, 2018 9:41 AM
>     >>         > To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>; Martin Bjorklund <mbj@tail-
> f.com<http://f.com/>>;
>     >>         > Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
>     >>         > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Xufeng Liu
>     >>         > <[email-masked]<mailto:[email-masked]>>
>     >>         > 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" <[email-masked]<mailto:[email-masked]>> wrote:
>     >>         >
>     >>         >     On Thu, 2018-02-08 at 12:39 +0100, Martin Bjorklund wrote:
>     >>         >     > "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> wrote:
>     >>         >     > > Hi Lada,
>     >>         >     >
>     >>         >     > >
>     >>         >     >
>     >>         >     > > On 2/8/18, 4:42 AM, "yang-doctors on behalf of Ladislav
> Lhotka"
>     >>         > <yang-docto
>     >>         >     > [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>     >>         >     >
>     >>         >     > >
>     >>         >     >
>     >>         >     > >     On Thu, 2018-02-08 at 09:20 +0100, Martin Bjorklund wrote:
>     >>         >     >
>     >>         >     > >     > Hi,
>     >>         >     >
>     >>         >     > >     >
>     >>         >     >
>     >>         >     > >     > "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>> 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)" <[email-masked]<mailto:[email-masked]>>
>     >>         >     >
>     >>         >     > >     > > Date: Monday, February 5, 2018 at 6:25 PM
>     >>         >     >
>     >>         >     > >     > > To: Xufeng Liu <[email-masked]<mailto:[email-masked]>>,
>     >>         > "[email-masked]<mailto:[email-masked]>"
>     >>         >     >
>     >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>
>     >>         >     >
>     >>         >     > >     > > Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
> "Mahesh
>     >>         > Sivakumar
>     >>         >     >
>     >>         >     > >     > > (masivaku)" <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
>     >>         >     >
>     >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
>     >>         >     >
>     >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
>     >>         >     >
>     >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>     >>         >     >
>     >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "tanmoy.kundu@alcatel-
>     >>         > lucent.com<http://lucent.com/>"
>     >>         >     >
>     >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
>     >>         > "[email-masked]<mailto:[email-masked]>"
>     >>         >     >
>     >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "Acee Lindem (acee)"
>     >>         > <[email-masked]<mailto:[email-masked]>>
>     >>         >     >
>     >>         >     > >     > > 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 = 'bfd-types:bfdv1'"  {
>     >>         >     >
>     >>         >     > >     > >       description
>     >>         >     >
>     >>         >     > >     > >         "This augmentation is only valid for a control-plane
>     >>         >     > protocol
>     >>         >     >
>     >>         >     > >     > >          instance of BFD (type 'bfdv1').";
>     >>         >     >
>     >>         >     > >     > >     }
>     >>         >     >
>     >>         >     > >     > >     description "BFD augmentation.";
>     >>         >     >
>     >>         >     > >     > >
>     >>         >     >
>     >>         >     > >     > >     container bfd {
>     >>         >     >
>     >>         >     > >     > >       when "../rt:name = 'bfdv1'"  {
>     >>         >     >
>     >>         >     > >     > >         description
>     >>         >     >
>     >>         >     > >     > >           "This augmentation is only valid for a control-plane
>     >>         >     > protocol
>     >>         >     >
>

---------- Forwarded message ----------
From: Christian Hopps <[email-masked]<mailto:[email-masked]>>
To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Bcc:
Date: Mon, 19 Feb 2018 05:01:55 -0500
Subject: Re: [yang-doctors] How to restrict to have single control-plane-protocol instance
Martin Bjorklund <[email-masked]<mailto:[email-masked]>> writes:

> Hi,
>
> "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> 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 {

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)" <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
>>         > Sent: Thursday, February 8, 2018 9:41 AM
>>         > To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>; Martin Bjorklund <[email-masked]<mailto:[email-masked]>>;
>>         > Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
>>         > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Xufeng Liu
>>         > <[email-masked]<mailto:[email-masked]>>
>>         > 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" <[email-masked]<mailto:[email-masked]>> wrote:
>>         >
>>         >     On Thu, 2018-02-08 at 12:39 +0100, Martin Bjorklund wrote:
>>         >     > "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> wrote:
>>         >     > > Hi Lada,
>>         >     >
>>         >     > >
>>         >     >
>>         >     > > On 2/8/18, 4:42 AM, "yang-doctors on behalf of Ladislav Lhotka"
>>         > <yang-docto
>>         >     > [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>>         >     >
>>         >     > >
>>         >     >
>>         >     > >     On Thu, 2018-02-08 at 09:20 +0100, Martin Bjorklund wrote:
>>         >     >
>>         >     > >     > Hi,
>>         >     >
>>         >     > >     >
>>         >     >
>>         >     > >     > "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>> 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)" <[email-masked]<mailto:[email-masked]>>
>>         >     >
>>         >     > >     > > Date: Monday, February 5, 2018 at 6:25 PM
>>         >     >
>>         >     > >     > > To: Xufeng Liu <[email-masked]<mailto:[email-masked]>>,
>>         > "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>
>>         >     >
>>         >     > >     > > Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Mahesh
>>         > Sivakumar
>>         >     >
>>         >     > >     > > (masivaku)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "tanmoy.kundu@alcatel-
>>         > lucent.com<http://lucent.com>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
>>         > "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "Acee Lindem (acee)"
>>         > <[email-masked]<mailto:[email-masked]>>
>>         >     >
>>         >     > >     > > 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 = 'bfd-types:bfdv1'"  {
>>         >     >
>>         >     > >     > >       description
>>         >     >
>>         >     > >     > >         "This augmentation is only valid for a control-plane
>>         >     > protocol
>>         >     >
>>         >     > >     > >          instance of BFD (type 'bfdv1').";
>>         >     >
>>         >     > >     > >     }
>>         >     >
>>         >     > >     > >     description "BFD augmentation.";
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >     container bfd {
>>         >     >
>>         >     > >     > >       when "../rt:name = 'bfdv1'"  {
>>         >     >
>>         >     > >     > >         description
>>         >     >
>>         >     > >     > >           "This augmentation is only valid for a control-plane
>>         >     > protocol
>>         >     >
>>         >     > >     > >            instance of BFD (type 'bfdv1').";
>>         >     >
>>         >     > >     > >       }
>>         >     >
>>         >     > >     > >       description "BFD top level container.";
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > From: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
>>         >     >
>>         >     > >     > > Date: Monday, February 5, 2018 at 9:38 AM
>>         >     >
>>         >     > >     > > To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>>         >     >
>>         >     > >     > > Cc: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>,
>>         >     >
>>         >     > >     > > "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Mahesh
>>         > Sivakumar
>>         >     >
>>         >     > >     > > (masivaku)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "tanmoy.kundu@alcatel-
>>         > lucent.com<http://lucent.com>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
>>         > "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>
>>         >     >
>>         >     > >     > > Subject: RE: Hi all, about the modification of MSDP YANG
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Hi Sandy,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Thanks for the updates.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > In RFC8022bis, the rt:type is defined under
>>         >     >
>>         >     > >     > > /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol.
>>         > If
>>         >     >
>>         >     > >     > > we augment /rt:routing/rt:control-plane-protocols, the “when”
>>         >     >
>>         >     > >     > > statement will not be valid, because it cannot find the rt:type. I
>>         >     >
>>         >     > >     > > don’t think that we need the “when” statement. The container
>>         > with
>>         >     >
>>         >     > >     > > “presence” will serve the purpose of the identity. We can simply
>>         >     > take
>>         >     >
>>         >     > >     > > out the “when” statement and the definition of the MSDP identity.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Thanks,
>>         >     >
>>         >     > >     > > - Xufeng
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>>         >     >
>>         >     > >     > > Sent: Monday, February 5, 2018 3:36 AM
>>         >     >
>>         >     > >     > > To: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
>>         >     >
>>         >     > >     > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>         > [email-masked]<mailto:[email-masked]>;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>         >     >
>>         >     > >     > > Subject: RE: Hi all, about the modification of MSDP YANG
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Hi Xufeng and Reshad,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > I am sorry for forgetting the point. I updated the YANG model.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > If no one has comments on it I'd like to submit the new version. :-)
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Thanks,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Sandy
>>         >     >
>>         >     > >     > > 原始邮件
>>         >     >
>>         >     > >     > > 发件人：
>>         > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > 收件人： <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         > 张征00007940;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > >
>>         > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>         >     > m>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;徐本
>>         > 崇10065053;
>>         >     >
>>         >     > >     > > <tanmoy.kundu@alcatel-
>>         > lucent.com<http://lucent.com><mailto:tanmoy.kundu@alcatel-lucent<mailto:tanmoy.kundu@alcatel-lucent>.
>>         >     > com>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > 日 期 ：2018年02月03日 01:21
>>         >     >
>>         >     > >     > > 主 题 ：RE: Hi all, about the modification of MSDP YANG
>>         >     >
>>         >     > >     > > Hi Sandy and Reshad,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > The reason that we used to augment
>>         >     >
>>         >     > >     > > /rt:routing/rt:control-plane-protocols, instead of
>>         >     >
>>         >     > >     > > /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol,
>>         > is
>>         >     >
>>         >     > >     > > that we do not allow multiple instances of MSDP.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Thanks,
>>         >     >
>>         >     > >     > > - Xufeng
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > From: Reshad Rahman (rrahman) [mailto:[email-masked]<mailto:[email-masked]>]
>>         >     >
>>         >     > >     > > Sent: Friday, February 2, 2018 12:08 PM
>>         >     >
>>         >     > >     > > To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>;
>>         > Xufeng
>>         >     > Liu
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Mahesh
>>         > Sivakumar
>>         >     >
>>         >     > >     > > (masivaku)
>>         > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > >
>>         > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>         >     > >;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > > tanmoy.kundu@alcatel-
>>         > lucent.com<http://lucent.com><mailto:[email-masked]<mailto:[email-masked]>
>>         >     > om>;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>>         >     >
>>         >     > >     > > Subject: Re: Hi all, about the modification of MSDP YANG
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Hi Sandy,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > I don’t know what warning you are getting now but from a quick
>>         > look
>>         >     > at
>>         >     >
>>         >     > >     > > the revision you sent I see couple of issues.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >      identity msdp {
>>         >     >
>>         >     > >     > >        base "rt:routing-protocol";  <== should be rt:control-plane-
>>         >     > protocol
>>         >     >
>>         >     > >     > >        description "MSDP";
>>         >     >
>>         >     > >     > >      }
>>         >     >
>>         >     > >     > > <snip>
>>         >     >
>>         >     > >     > >      /*
>>         >     >
>>         >     > >     > >       * Data nodes
>>         >     >
>>         >     > >     > >       */
>>         >     >
>>         >     > >     > >      augment
>>         >     >
>>         >     > >     > >      "/rt:routing/rt:control-plane-protocols/rt:control-plane-
>>         >     > protocol" {
>>         >     >
>>         >     > >     > >         when "rt:type = 'MSDP'" { <== should be "rt:type =
>>         >     > 'msdp:msdp'"
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > HTH,
>>         >     >
>>         >     > >     > > Reshad.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > From:
>>         > "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>>         >     >
>>         >     > >     > > Date: Friday, February 2, 2018 at 4:37 AM
>>         >     >
>>         >     > >     > > To: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
>>         >     >
>>         >     > >     > > "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "Mahesh
>>         >     > Sivakumar
>>         >     >
>>         >     > >     > > (masivaku)"
>>         > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
>>         >     >
>>         >     > >     > > "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
>>         >     >
>>         >     > >     > >
>>         > "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>         >     > m>"
>>         >     >
>>         >     > >     > >
>>         > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>         >     > m>>,
>>         >     >
>>         >     > >     > > "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
>>         >     >
>>         >     > >     > > "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
>>         >     >
>>         >     > >     > > "tanmoy.kundu@alcatel-
>>         > lucent.com<http://lucent.com><mailto:tanmoy.kundu@alcatel-lucent<mailto:tanmoy.kundu@alcatel-lucent>.
>>         >     > com>"
>>         >     >
>>         >     > >     > > <tanmoy.kundu@alcatel-
>>         > lucent.com<http://lucent.com><mailto:tanmoy.kundu@alcatel-lucent<mailto:tanmoy.kundu@alcatel-lucent>.
>>         >     > com>>,
>>         >     >
>>         >     > >     > > "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>>         >     >
>>         >     > >     > > Cc: "Reshad Rahman (rrahman)"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>>         >     >
>>         >     > >     > > Subject: FW: Hi all, about the modification of MSDP YANG
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Hi all,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > I deleted some groupings and make the model more clear.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > And I updated the decription of (peer-as, up-time, expire).  Please
>>         >     >
>>         >     > >     > > review it.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > A warning is still existing about rt:type:
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > 5, - augment of control-plane-protocols is incorrect. There should
>>         >     > be
>>         >     >
>>         >     > >     > > an identity msdp with
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > base "rt:routing-protocol" and then augment
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol"
>>         >     >
>>         >     > >     > > with a when
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > statement. Take a look at OSPF YANG for an example.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added the identity and modify the augmentation, but it
>>         >     > seems
>>         >     >
>>         >     > >     > > like there is no MSDP register in rt:type.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > How can we register it?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Thanks,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Sandy
>>         >     >
>>         >     > >     > > 原始邮件
>>         >     >
>>         >     > >     > > 发件人：张征00007940
>>         >     >
>>         >     > >     > > 收件人： <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > >
>>         > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>         >     > m>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;徐本
>>         > 崇10065053;
>>         >     >
>>         >     > >     > > <tanmoy.kundu@alcatel-
>>         > lucent.com<http://lucent.com><mailto:tanmoy.kundu@alcatel-lucent<mailto:tanmoy.kundu@alcatel-lucent>.
>>         >     > com>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > 抄送人： <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
>>         >     >
>>         >     > >     > > 日 期 ：2018年01月29日  17:04
>>         >     >
>>         >     > >     > > 主 题 ：Hi all, about the modification of MSDP YANG
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Hi all,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > YANG doctor Reshad had finished the early review about MSDP
>>         > YANG.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > I finished the preliminary modification version, please review it.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > I think some advices from Reshad should be discussed:
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > 1, - Not sure why peer-as is needed. Don't see it in RFC3618.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > 2, - leaf up-time, what's meant by "up time" in the description? Is
>>         >     > it
>>         >     >
>>         >     > >     > > time it's
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > been created?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > 3, - description for leaf expire seems wrong.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: These items (peer-as, up-time, expire) doesn't existed in
>>         >     >
>>         >     > >     > > RFC3618, are these unnecessary? Please write down your
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > description if you insist on it. If nobody insist on it, should we
>>         >     >
>>         >     > >     > > delete them?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > 4, - Groupings are used for data which is used only once. Is this
>>         >     > done
>>         >     >
>>         >     > >     > > on purpose or
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > was the intention to use those groupings more than once?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: These eight groupings are used only once, should we
>>         > change
>>         >     >
>>         >     > >     > > them to container?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > authentication-container;
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > global-config-attributes;
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > peer-config-attributes;
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > peer-state-attributes;
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > sa-cache-state-attributes;
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > statistics-container
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > statistics-error
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > statistics-queue
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > 5, - augment of control-plane-protocols is incorrect. There should
>>         >     > be
>>         >     >
>>         >     > >     > > an identity msdp with
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > base "rt:routing-protocol" and then augment
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol"
>>         >     >
>>         >     > >     > > with a when
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > statement. Take a look at OSPF YANG for an example.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added the identity and modify the augmentation, but it
>>         >     > seems
>>         >     >
>>         >     > >     > > like there is no MSDP register in rt:type.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > How can we register it?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Most of the suggestion is adopted. The modification detail pls see
>>         >     >
>>         >     > >     > > below:
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Too many features (17)! Every piece of config has an if-feature
>>         >     >
>>         >     > >     > > - statement.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Some of the configs (timers?) should be part of most/basic
>>         >     >
>>         >     > >     > > implementations, for
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > other config (e.g. authentication) I can see why a feature would
>>         > be
>>         >     >
>>         >     > >     > > used.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Modified the three timers (connect-retry, hold, keepalive)
>>         >     > to
>>         >     >
>>         >     > >     > > fixed format.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > -“import ietf-yang-types” should have a reference to RFC6991
>>         > (see
>>         >     >
>>         >     > >     > > -section 4.7 of
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > rfc6087bis-15)
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - “import ietf-inet-types” should have a reference to RFC6991
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - “import ietf-routing” should have a reference to RFC8022
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - “import ietf-interfaces” should have a reference to RFC7223
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - "import ietf-ip" should have a reference to RFC7277
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - "import ietf-key-chain" should have a reference to RFC8177
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added all the references above.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - organization s/"...PIM( Protocols for IP Multicast ) Working
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Group"/"...PIM (Protocols for IP Multicast) Working Group"?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Remove WG Chairs from contact information as per Appendix C
>>         > of
>>         >     >
>>         >     > >     > > - rfc6087bis-15
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - No copyright in the module description, see Appendix of
>>         > 6087bis-15
>>         >     > for
>>         >     >
>>         >     > >     > > - a module description
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > example
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Module description must contain reference to RFC, see
>>         > Appendix C
>>         >     > of
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > rfc6087bis-15
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Removed WG chairs and add copyright from Appendix of
>>         >     >
>>         >     > >     > > rfc6087bis. Added reference to RFC3618.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - grouping authentication-container. key-chain and password
>>         > both
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > use if-feature peer-key-chain.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Removed the if-feature peer-key-chain from password.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - grouping connect-source. The name is not very
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > descriptive. Should this be something along the lines of
>>         >     >
>>         >     > >     > > tcp-connection-source?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Changed the name "connect-source" to "tcp-connection-
>>         >     > source".
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - grouping global-state-attributes has nothing
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Deleted the grouping.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Some of the descriptions are
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > pretty terse. e.g. for rpf-peer it says "RPF peer.". In a case like
>>         >     >
>>         >     > >     > > this
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > consider adding more descriptive text or a reference to the
>>         > proper
>>         >     >
>>         >     > >     > > section in
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > RFC3618
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added more description.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - peer-as (Autonomous System Number) is defined as type string,
>>         >     > should
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > be of type as-number in ietf-inet-types?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Modified to inet types.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - keepalive-interval depends on holdtime-interval.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > There should be "if-feature peer-timer-holdtime" under leaf
>>         >     >
>>         >     > >     > > keepalive-interval
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > or change the must statement to (assuming we keep the 2
>>         > features):
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >   must "(not ../holdtime-interval) or (. > 1 and . <
>>         >     >
>>         >     > >     > >   ../holdtime-interval)".
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Modified the features to fixed format.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - leaf up-time: s/sa cache/SA cache/
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - leaf peer-learned-from, change description from "The address
>>         > of
>>         >     > peer
>>         >     >
>>         >     > >     > > - that we learned
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > this SA from ." to "The address of the peer that we learned this SA
>>         >     >
>>         >     > >     > > from."
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Modified.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - RPC leaf group, I thought we had a type for IP multicast address?
>>         >     > If
>>         >     >
>>         >     > >     > > - not, it should be done?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Yes. Added the rt-type reference to RFC8294.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - s/msdp/MSDP/
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - In rpc msdp-clear-peer, s/Clears the session to the peer./Clears
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > the TCP connection to the peer./
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - In rpc msdp-clear-sa-cache, why have the enum '*' for
>>         >     >
>>         >     > >     > > - source-addr. Can't the same technique as for peer-address be
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > used?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - msdp prefix not needed in rpc names
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Done.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - MSDP peers are configured in a mesh-group, did the authors
>>         >     > consider
>>         >     >
>>         >     > >     > > - adding state per mesh-group, e.g. all the
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > peers in a particular mesh-group?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: IMO it is unnecessary because the states of peers is not
>>         >     >
>>         >     > >     > > unified in a mesh-group.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > General:
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Per Appendix B of rfc6087bis-15: "that all YANG modules
>>         > containing
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > imported items are cited as normative reference". So RFCs 6991,
>>         >     > 7223,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > 7277, 8022 and 8177 should be included in the normative
>>         > reference
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > section.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Section 3 "the irrelevant information", add a
>>         >     > reference/explanation
>>         >     >
>>         >     > >     > > - for what
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > the irrelevant information is. s/the irrelevant
>>         >     > information/irrelevant
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > information/?
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Changed the description.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Section 5 should give a brief description of what the RPCs do.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added some description.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Section 6 any plans for notifications? If not, just say so.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Done.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Need Security
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Considerations, see sections 3.7 and 6 of rfc6087bis-15
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added security consideration section.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Need IANA Considerations, see section 3.8 of rfc6087bis-15
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added IANA considerations.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > - Need license in YANG module,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > see appendix B of rfc6087bis-15
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > [Sandy]: Added the YANG module description.
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Thanks,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > Sandy
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     >
>>         >     >
>>         >     > >     > _______________________________________________
>>         >     >
>>         >     > >     > yang-doctors mailing list
>>         >     >
>>         >     > >     > [email-masked]<mailto:[email-masked]>
>>         >     >
>>         >     > >     > https://www.ietf.org/mailman/listinfo/yang-doctors
>>         >     >
>>         >     > >     --
>>         >     >
>>         >     > >     Ladislav Lhotka
>>         >     >
>>         >     > >     Head, CZ.NIC Labs
>>         >     >
>>         >     > >     PGP Key ID: 0xB8F92B08A9F76C67
>>         >     >
>>         >     > >
>>         >     >
>>         >     > >     _______________________________________________
>>         >     >
>>         >     > >     yang-doctors mailing list
>>         >     >
>>         >     > >     [email-masked]<mailto:[email-masked]>
>>         >     >
>>         >     > >     https://www.ietf.org/mailman/listinfo/yang-doctors
>>         >     >
>>         >     > >
>>         >     >
>>         >     > >
>>         >     >
>>         >     --
>>         >     Ladislav Lhotka
>>         >     Head, CZ.NIC Labs
>>         >     PGP Key ID: 0xB8F92B08A9F76C67
>>         >
>>
>>
>>
>>
>>
> _______________________________________________
> yang-doctors mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/yang-doctors

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Oct 2018 14:36:04 -0700

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?

What is the use-case for a config list without keys?

Andy

On Tue, Oct 23, 2018 at 2:16 PM, Reshad Rahman (rrahman) <[email-masked]>
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…
>
> *From: *Xufeng Liu <[email-masked]>
> *Date: *Tuesday, October 23, 2018 at 4:39 PM
> *To: *"Reshad Rahman (rrahman)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Mahesh Sivakumar <
> [email-masked]>, Stig Venaas <[email-masked]>, Guofeng <
> [email-masked]>, Anish Peter <[email-masked]>, "
> [email-masked]" <[email-masked]>, Liuyisong <
> [email-masked]>, Pete McAllister <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *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) <
> [email-masked]> 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 <[email-masked]> on behalf of Xufeng
> Liu <[email-masked]>
> *Date: *Friday, October 19, 2018 at 9:21 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *Mahesh Sivakumar <[email-masked]>, Stig Venaas <
> [email-masked]>, Guofeng <[email-masked]>, Anish Peter <
> [email-masked]>, "[email-masked]" <[email-masked]>,
> Liuyisong <[email-masked]>, Pete McAllister <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [yang-doctors] [pim] Yangdoctors last call review of
> draft-ietf-pim-igmp-mld-yang-07
>
>
>
> Hi Jan,
>
>
>
> Thanks for reviewing.
>
> On Fri, Oct 19, 2018 at 4:25 AM Jan Lindblad <[email-masked]> 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.
>
> 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*, [email-masked], +46 702855728
>
> From: Jan Lindblad [mailto:[email-masked] <[email-masked]>]
>
> To: [email-masked]
>
> Cc: [email-masked]; [email-masked]; [email-masked]
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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?
>
> *From:* pim [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Jan Lindblad
> *Sent:* Tuesday, September 11, 2018 9:52 PM
> *To:* Xufeng Liu <[email-masked]>
> *Cc:* [email-masked]; ietf <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [pim] Yangdoctors last call review of
> draft-ietf-pim-igmp-mld-yang-07
>
>
>
> Xufeng,
>
>
>
> 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 <[email-masked]>
> 收件人：Acee Lindem (acee) <[email-masked]>Christian Hopps <[email-masked]>Martin
> Bjorklund <[email-masked]>
> 抄送人：张征00007940;[email-masked] <[email-masked]>
> 日 期 ：2018年02月20日 22:30
> 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:
>
> 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.
>
> 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
>
> > From: Acee Lindem (acee) [mailto:[email-masked]]
> > To: Christian Hopps <[email-masked]>; Martin Bjorklund <
> [email-masked]>
> > Cc: Xufeng Liu <[email-masked]>; [email-masked]; yang-
> > [email-masked]
> > On 2/19/18, 5:02 AM, "Christian Hopps" <[email-masked]> wrote:
> >
> >
> >     Martin Bjorklund <[email-masked]> writes:
> >
> >     > Hi,
> >     >
> >     > "Acee Lindem (acee)" <[email-masked]> wrote:
> >     >> All,
> >     >>
> >     >> On 2/15/18, 8:39 AM, "Reshad Rahman (rrahman)" <[email-masked]
> >
> > wrote:
> >     >>
> >     >>     Hi Xufeng,
> >     >>
> >     >>     On 2018-02-08, 9:48 AM, "Xufeng Liu" <[email-masked]>
> wrote:
> >     >>
> >     >>         Hi All,
> >     >>
> >     >>         > From: Reshad Rahman (rrahman) [mailto:[email-masked]
> ]
> >     >>         > To: Ladislav Lhotka <[email-masked]>; Martin Bjorklund
> <mbj@tail-
> > f.com>;
> >     >>         > Acee Lindem (acee) <[email-masked]>
> >     >>         > Cc: [email-masked]; [email-masked];
> Xufeng Liu
> >     >>         > <[email-masked]>
> >     >>         > On 2018-02-08, 7:02 AM, "Ladislav Lhotka" <
> [email-masked]> wrote:
> >     >>         >
> >     >>         >     > "Acee Lindem (acee)" <[email-masked]> wrote:
> >     >>         >     > > Hi Lada,
> >     >>         >     >
> >     >>         >     > >
> >     >>         >     >
> >     >>         >     > [email-masked] on behalf of [email-masked]>
> wrote:
> >     >>         >     >
> >     >>         >     > >
> >     >>         >     >
> >     >>         >     > >     > "Reshad Rahman (rrahman)" <
> [email-masked]> wrote:
> >     >>         >     >
> >     >>         >     > >     > > Hi YDs,
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     >           + '
> derived-from-or-sel(../rt:type, "msdp:msdp")])
> > <=
> >     >>         >     > 1'";
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     > > From: "Reshad Rahman (rrahman)" <
> [email-masked]>
> >     >>         >     >
> >     >>         >     > >     > > To: Xufeng Liu <[email-masked]>,
> >     >>         > "[email-masked]"
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>
> >     >>         >     >
> >     >>         >     > >     > > Cc: "[email-masked]" <
> [email-masked]>,
> > "Mahesh
> >     >>         > Sivakumar
> >     >>         >     >
> >     >>         >     > >     > > (masivaku)" <[email-masked]>,
> > "[email-masked]"
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>,
> > "[email-masked]"
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>,
> > "[email-masked]"
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>, "
> [email-masked]"
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>,
> "tanmoy.kundu@alcatel-
> >     >>         > lucent.com"
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>,
> >     >>         > "[email-masked]"
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>, "Acee
> Lindem (acee)"
> >     >>         > <[email-masked]>
> >     >>         >     >
> From: Christian Hopps <[email-masked]>
> To: Martin Bjorklund <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, <
> [email-masked]>
> Bcc:
> Martin Bjorklund <[email-masked]> writes:
>
> > Hi,
> >
> > "Acee Lindem (acee)" <[email-masked]> wrote:
> >> All,
> >>
> 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. :)
>
> 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)" <[email-masked]>
> wrote:
> >>
> >>     Hi Xufeng,
> >>
> /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.
> >>
> >>     On 2018-02-08, 9:48 AM, "Xufeng Liu" <[email-masked]> 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:
> >>
> 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.
> >>         - 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
> >>
> >>
> >>         > From: Reshad Rahman (rrahman) [mailto:[email-masked]]
> >>         > To: Ladislav Lhotka <[email-masked]>; Martin Bjorklund <
> [email-masked]>;
> >>         > Acee Lindem (acee) <[email-masked]>
> >>         > Cc: [email-masked]; [email-masked]; Xufeng Liu
> >>         > <[email-masked]>
> >>         > On 2018-02-08, 7:02 AM, "Ladislav Lhotka" <[email-masked]>
> wrote:
> >>         >
> >>         >     > "Acee Lindem (acee)" <[email-masked]> wrote:
> >>         >     > > Hi Lada,
> >>         >     >
> >>         >     > >
> >>         >     >
> >>         >     > [email-masked] on behalf of [email-masked]> wrote:
> >>         >     >
> >>         >     > >
> >>         >     >
> >>         >     > >     > "Reshad Rahman (rrahman)" <[email-masked]>
> wrote:
> >>         >     >
> >>         >     > >     > > Hi YDs,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > From: "Reshad Rahman (rrahman)" <
> [email-masked]>
> >>         >     >
> >>         >     > >     > > To: Xufeng Liu <[email-masked]>,
> >>         > "[email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>
> >>         >     >
> >>         >     > >     > > Cc: "[email-masked]" <
> [email-masked]>, "Mahesh
> >>         > Sivakumar
> >>         >     >
> >>         >     > >     > > (masivaku)" <[email-masked]>, "
> [email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>, "
> [email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>, "
> [email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>, "
> [email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>,
> "tanmoy.kundu@alcatel-
> >>         > lucent.com"
> >>         >     >
> >>         >     > >     > > <[email-masked]>,
> >>         > "[email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>, "Acee Lindem
> (acee)"
> >>         > <[email-masked]>
> >>         >     >
> >>         >     > >     > > From: Xufeng Liu <[email-masked]>
> >>         >     >
> >>         >     > >     > > To: "[email-masked]" <
> [email-masked]>
> >>         >     >
> >>         >     > >     > > Cc: "Reshad Rahman (rrahman)" <
> [email-masked]>,
> >>         >     >
> >>         >     > >     > > "[email-masked]" <[email-masked]>,
> "Mahesh
> >>         > Sivakumar
> >>         >     >
> >>         >     > >     > > (masivaku)" <[email-masked]>, "
> [email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>, "
> [email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>, "
> [email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>, "
> [email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>,
> "tanmoy.kundu@alcatel-
> >>         > lucent.com"
> >>         >     >
> >>         >     > >     > > <[email-masked]>,
> >>         > "[email-masked]"
> >>         >     >
> >>         >     > >     > > <[email-masked]>
> >>         >     >
> >>         >     > >     > > From: [email-masked] [mailto:
> [email-masked]]
> >>         >     >
> >>         >     > >     > > To: Xufeng Liu <[email-masked]>
> >>         >     >
> >>         >     > >     > > Cc: [email-masked]; [email-masked];
> >>         > [email-masked];
> >>         >     >
> >>         >     > >     > > [email-masked];
> [email-masked];
> >>         >     >
> >>         >     > >     > > [email-masked]; [email-masked];
> >>         >     >
> >>         >     > >     > > [email-masked];
> [email-masked]
> >>         >     >
> >>         > <[email-masked]<mailto:[email-masked]>>;
> >>         >     >
> >>         >     > >     > > 收件人： <[email-masked]<mailto:rrah
> [email-masked]>>;
> >>         > 张征00007940;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:a
> [email-masked]>>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:[email-masked]
> >>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:[email-masked]
> >>;
> >>         >     >
> >>         >     > >     > >
> >>         > <[email-masked]<mailto:pete.mcallister@
> metaswitch.co
> >>         >     > m>>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:l
> [email-masked]>>;徐本
> >>         > 崇10065053;
> >>         >     >
> >>         >     > >     > > <tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
> >>         >     > com>>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:
> [email-masked]>>;
> >>         >     >
> >>         >     > >     > > 日 期 ：2018年02月03日 01:21
> >>         >     >
> >>         >     > >     > > From: Reshad Rahman (rrahman) [mailto:
> [email-masked]]
> >>         >     >
> >>         >     > >     > > To: [email-masked]<mailto:
> [email-masked]>;
> >>         > Xufeng
> >>         >     > Liu
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:X
> [email-masked]>>;
> >>         >     >
> >>         >     > >     > > [email-masked]<mailto:an
> [email-masked]>; Mahesh
> >>         > Sivakumar
> >>         >     >
> >>         >     > >     > > (masivaku)
> >>         > <[email-masked]<mailto:[email-masked]>>;
> >>         >     >
> >>         >     > >     > > [email-masked]<mailto:[email-masked]
> >;
> >>         >     >
> >>         >     > >     > >
> >>         > [email-masked]<mailto:pete.mcallister@
> metaswitch.com
> >>         >     > >;
> >>         >     >
> >>         >     > >     > > [email-masked]<mailto:li
> [email-masked]>;
> >>         >     >
> >>         >     > >     > > [email-masked]<mailto:
> [email-masked]>;
> >>         >     >
> >>         >     > >     > > tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:[email-masked]
> >>         >     > om>;
> >>         >     >
> >>         >     > >     > > [email-masked]<mailto:
> [email-masked]>
> >>         >     >
> >>         >     > >     > > To: "[email-masked]<mailto:x
> [email-masked]>"
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:x
> [email-masked]>>,
> >>         >     >
> >>         >     > >     > > "[email-masked]<mailto:a
> [email-masked]>"
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:a
> [email-masked]>>, "Mahesh
> >>         >     > Sivakumar
> >>         >     >
> >>         >     > >     > > (masivaku)"
> >>         > <[email-masked]<mailto:[email-masked]>>,
> >>         >     >
> >>         >     > >     > > "[email-masked]<mailto:[email-masked]
> >"
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:[email-masked]
> >>,
> >>         >     >
> >>         >     > >     > >
> >>         > "[email-masked]<mailto:pete.mcallister@
> metaswitch.co
> >>         >     > m>"
> >>         >     >
> >>         >     > >     > >
> >>         > <[email-masked]<mailto:pete.mcallister@
> metaswitch.co
> >>         >     > m>>,
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:l
> [email-masked]>>,
> >>         >     >
> >>         >     > >     > > "[email-masked]<mailto:
> [email-masked]>"
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:
> [email-masked]>>,
> >>         >     >
> >>         >     > >     > > "tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
> >>         >     > com>"
> >>         >     >
> >>         >     > >     > > <tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
> >>         >     > com>>,
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>
> >>         >     >
> >>         >     > >     > > 收件人： <[email-masked]<mailto:x
> [email-masked]>>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:a
> [email-masked]>>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:[email-masked]
> >>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:[email-masked]
> >>;
> >>         >     >
> >>         >     > >     > >
> >>         > <[email-masked]<mailto:pete.mcallister@
> metaswitch.co
> >>         >     > m>>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:l
> [email-masked]>>;徐本
> >>         > 崇10065053;
> >>         >     >
> >>         >     > >     > > <tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
> >>         >     > com>>;
> >>         >     >
> >>         >     > >     > > <[email-masked]<mailto:
> [email-masked]>>;
> >>         >     >
> >>         >     > >     > > 抄送人： <[email-masked]<mailto:rrah
> [email-masked]>>;
> >>         >     >
> >>         >     > >     > > 日 期 ：2018年01月29日  17:04
> >>         >     >
> >>         >     > >     > [email-masked]
> >>         >     > >     [email-masked]
> > [email-masked]
> [email-masked]
> [email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 24 Oct 2018 02:39:36 +0000

Hi,

The list control-plane-protocol in RFC8349 is keyed on type + name, this works fine for protocols which support multiple instances. In the MLD case (and others) we only have 1 instance of the protocol and we don’t want to enforce the end user to specify a name. With the recommended option (attached), we still have to provide an empty name.

Regards,
Reshad.

From: 'Andy Bierman' <[email-masked]>
Date: Tuesday, October 23, 2018 at 5:36 PM
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: Xufeng Liu <[email-masked]>, Mahesh Sivakumar <[email-masked]>, Stig Venaas <[email-masked]>, Guofeng <[email-masked]>, Anish Peter <[email-masked]>, "[email-masked]" <[email-masked]>, Liuyisong <[email-masked]>, Pete McAllister <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [yang-doctors] Optional key support?

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.

Andy

On Tue, Oct 23, 2018 at 2:16 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
<Changed subject>

Hi Xufeng,

Regards,
Reshad.

From: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 23, 2018 at 4:39 PM
To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mahesh Sivakumar <[email-masked]<mailto:[email-masked]>>, Stig Venaas <[email-masked]<mailto:[email-masked]>>, Guofeng <[email-masked]<mailto:[email-masked]>>, Anish Peter <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Liuyisong <[email-masked]<mailto:[email-masked]>>, Pete McAllister <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [yang-doctors] [pim] Yangdoctors last call review of draft-ietf-pim-igmp-mld-yang-07

Hi Reshad and All,

Thanks,
- Xufeng

Regards,
Reshad.

Hi Jan,

Thanks for reviewing.

Hi Jan,

Best Regards,
/jan

Feng

-----Original Message-----
From: Jan Lindblad [mailto:[email-masked]]
Sent: Monday, August 13, 2018 10:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Yangdoctors last call review of draft-ietf-pim-igmp-mld-yang-07

Reviewer: Jan Lindblad

Quoted from section 3.1:

Quoted from section 2.2:

Quoted from section 2.3:

Quoted from section 3.1:

#5 All optional state

#6 Abundant copy-paste

Xufeng,

Best Regards,
/jan

Thanks,
- Xufeng

---------- Forwarded message ----------
From: Christian Hopps <[email-masked]<mailto:[email-masked]>>
To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Bcc:
Date: Mon, 19 Feb 2018 05:01:55 -0500
Subject: Re: [yang-doctors] How to restrict to have single control-plane-protocol instance

Thanks,
Chris.

Subject: Re: [yang-doctors] How to restrict to have single control-plane-protocol instance
From: Christian Hopps <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 19 Feb 2018 05:01:55 -0500
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>

Thanks,
Chris.

>> On 2/15/18, 8:39 AM, "Reshad Rahman (rrahman)" <[email-masked]> wrote:
>>
>>     Hi Xufeng,
>>
>>         > To: Ladislav Lhotka <[email-masked]>; Martin Bjorklund <[email-masked]>;
>>         > On 2018-02-08, 7:02 AM, "Ladislav Lhotka" <[email-masked]> wrote:
>>         >
>>         >     > >     > "Reshad Rahman (rrahman)" <[email-masked]> wrote:
>>         >     >
>>         >     > >     > > Hi YDs,
>>         >     >
>>         >     > >     > >
>>         >     >
>>         >     > >     > > From: "Reshad Rahman (rrahman)" <[email-masked]>
>>         >     >
>>         >     > >     > > Cc: "[email-masked]" <[email-masked]>, "Mahesh
>>         > Sivakumar
>>         >     >
>>         >     > >     > > (masivaku)" <[email-masked]>, "[email-masked]"
>>         >     >
>>         >     > >     > > <[email-masked]>, "[email-masked]"
>>         >     >
>>         >     > >     > > <[email-masked]>, "[email-masked]"
>>         >     >
>>         >     > >     > > <[email-masked]>, "[email-masked]"
>>         >     >
>>         >     > >     > > <[email-masked]>, "tanmoy.kundu@alcatel-
>>         > lucent.com"
>>         >     >
>>         >     > >     > > <[email-masked]>, "Acee Lindem (acee)"
>>         > <[email-masked]>
>>         >     >
>>         >     > >     > > To: "[email-masked]" <[email-masked]>
>>         >     >
>>         >     > >     > > Cc: "Reshad Rahman (rrahman)" <[email-masked]>,
>>         >     >
>>         >     > >     > > "[email-masked]" <[email-masked]>, "Mahesh
>>         > Sivakumar
>>         >     >
>>         >     > >     > > (masivaku)" <[email-masked]>, "[email-masked]"
>>         >     >
>>         >     > >     > > <[email-masked]>, "[email-masked]"
>>         >     >
>>         >     > >     > > <[email-masked]>, "[email-masked]"
>>         >     >
>>         >     > >     > > <[email-masked]>, "[email-masked]"
>>         >     >
>>         >     > >     > > <[email-masked]>, "tanmoy.kundu@alcatel-
>>         > lucent.com"
>>         >     >
>>         >     > >     > > From: [email-masked] [mailto:[email-masked]]
>>         >     >
>>         >     > >     > > [email-masked]; [email-masked];
>>         >     >
>>         >     > >     > > [email-masked]; [email-masked]
>>         >     >
>>         >     > >     > > 收件人： <[email-masked]<mailto:[email-masked]>>;
>>         > 张征00007940;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > >
>>         > <[email-masked]<mailto:[email-masked]
>>         >     > m>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>;徐本
>>         > 崇10065053;
>>         >     >
>>         >     > >     > > <tanmoy.kundu@alcatel-
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > > 日 期 ：2018年02月03日 01:21
>>         >     >
>>         >     > >     > > To: [email-masked]<mailto:[email-masked]>;
>>         > Xufeng
>>         >     > Liu
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]>; Mahesh
>>         > Sivakumar
>>         >     >
>>         >     > >     > > (masivaku)
>>         >     > >     > > [email-masked]<mailto:[email-masked]>;
>>         >     >
>>         >     > >     > >
>>         > [email-masked]<mailto:[email-masked]
>>         >     > >;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]>;
>>         >     >
>>         >     > >     > > [email-masked]<mailto:[email-masked]>;
>>         >     >
>>         >     > >     > > tanmoy.kundu@alcatel-
>>         >     > >     > > [email-masked]<mailto:[email-masked]>
>>         >     >
>>         >     > >     > > To: "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
>>         >     >
>>         >     > >     > > "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "Mahesh
>>         >     > Sivakumar
>>         >     >
>>         >     > >     > > (masivaku)"
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
>>         >     >
>>         >     > >     > > "[email-masked]<mailto:[email-masked]>"
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
>>         >     >
>>         >     > >     > > "tanmoy.kundu@alcatel-
>>         >     > >     > > 收件人： <[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > >
>>         > <[email-masked]<mailto:[email-masked]
>>         >     > m>>;
>>         >     >
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>;徐本
>>         > 崇10065053;
>>         >     >
>>         >     > >     > > <tanmoy.kundu@alcatel-
>>         >     > >     > > <[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > > 抄送人： <[email-masked]<mailto:[email-masked]>>;
>>         >     >
>>         >     > >     > > 日 期 ：2018年01月29日  17:04
>>         >     >

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Oct 2018 07:47:44 +0200 (CEST)

>      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

> > do a full re-review of the module once that one has been resolved as well..
> > don't
> > outweigh the
> > user-configured,
> > >     >>         >     > >     > > on the name in the top level container..
> > This would still
> > > multiple
> > >     >>         >     >
> > rt:control-plane-protocol['
> > >     >>         >     >
> > >     >>         >     > >     >           + '
> > >     >>         >     > >     > > check with the other YDs on this topic..
> > One way it can be
> > > done is
> > >     >>         > as
> > >     >>         >     >
> > >>         >     > >     > Hard-coding a name like this is IMO a bad idea..
> > >>         >     >
> > >>         >     > >     >
> > >>         >     >
> > >>         >     > >     > > the revision you sent I see couple of issues..
> > >>         >     >
> > >>         >     > >     > >
> > >>         >     >
> > >>         >     > >     > >      identity msdp {
> > >>         >     >
> > [email-masked]>>
> > >>         >     >
> > >>         >     > >     > > 3, - description for leaf expire seems wrong..
> > >>         >     >
> > >>         >     > >     > >
> > >>         >     >

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 Oct 2018 14:53:54 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    and the discussion:

    
    /martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Oct 2018 17:55:09 +0200

Hi Acee,

On Wed, 2018-10-24 at 14:53 +0000, 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?

I believe that the major issue is the NETCONF <edit-config> operation that
cannot really work without list keys. That's also why a list key cannot be
changed in place with NETCONF - you have to delete the entire entry and create
it again with the new key.

Lada

> Thanks,
> Acee
> 
> On 10/24/18, 1:48 AM, "yang-doctors on behalf of Martin Bjorklund" <
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     > > [email-masked]>, Pete McAllister <[email-masked]
> >, "
>     > > Cc: [email-masked]; [email-masked]; 
>     > > Guofeng: We removed the paragraph above, and put the values discussed
> by
>     > > Mcast Design Team.
>     > >
>     > >
>     > >
>     > >
>     > >
>     > > Describe what values are valid. #9 Leaf group on line 705, 1101, 1131:
> Is
>     > > any
>     > >
>     > > edit routing control-plane-protocols control-plane-protocol type msdp
> name
>     > > ''"
>     > >
>     > > >     >>   and specify in the description text that only a single
> instance
>     > > is
>     > > >     >>   supported.
>     > > > known" value for name, I would specify the 0 length string instead.
> I
>     > > think that
>     > > >           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
>     > > >     >
>     > > >     >
>     > > > forcing a name for a single-instance is cumbersome, but I think it
> is
>     > > too late to
>     > > > unnecessary expense to the user and to the implementation,
> especially if
>     > > we
>     > > >     >>         - Data tree query: If the singleton "MSDP" is mixed
> with
>     > > other protocol
>     > > > single-instance protocols under /rt:routing/rt:control-plane-
> protocols
>     > > and all
> [email-masked]
>     > > >     >>         > Thanks for the suggestions. I agree that hard-
> coding
>     > > the name is a
>     > > > bad idea,
>     > > >     >>         > - We can move the must statement up to restrict max
> of
>     > > 1 control-
>     > > > plane-
>     > > >     >>         > - Acee/Lada, should a note be added to section 5.3
> of
>     > > 8022bis
>     > > > regarding how
>     > > >     >>         >     On Thu, 2018-02-08 at 12:39 +0100, Martin
> Bjorklund
>     > > wrote:
>     > > >     >>         >     > > On 2/8/18, 4:42 AM, "yang-doctors on behalf
> of
>     > > Ladislav
>     > > > Lhotka"
>     > > >     >>         > <yang-docto
>     > > >     >>         >     > >     On Thu, 2018-02-08 at 09:20 +0100,
> Martin
>     > > Bjorklund wrote:
>     > > >     >>         >     >
>     > > >     >>         >     > >     > Hi,
>     > > >     >>         >     >
>     > > >     >>         >     > >     >
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > control-pane-protocol instances as
> long
>     > > as they have
>     > > > different
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > rt:name. The only workaround I
> thought
>     > > of is to have a
>     > > > when
>     > > >     >>         >     > statement
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > control-plane-protocol instance of
> type
>     > > msdp but
>     > > > restricts the
>     > > >     >>         > name
>     > > >     >>         >     > to
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > 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.
>     > > >     >>         >     >
>     > > >     >>         >     > >     >
>     > > >     >>         >     >
>     > > >     >>         >     > >     >    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/'
>     > > >     >>         >     >
>     > > >     >>         >     > >     >           + '
>     > > >     >>         >     > >     > 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
>     > > >     >>         >     >
>     > > >     >>         >     > >     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 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
>     > > >     >>         >     > name", won't it only work if the previous
> sibling
>     > > has a  "name"
>     > > > that
>     > > >     >>         >     > For each list entry that has this container,
> the
>     > > expression is
>     > > >     >>         >     > evaluated.  It will scan all preceding
> entries
>     > > and ensure that there
>     > > >     >>         >     > 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" {
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > Date: Monday, February 5, 2018 at
> 6:25
>     > > PM
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > To: Xufeng Liu <
> [email-masked]>,
>     > > >     >>         > "[email-masked]"
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > <[email-masked]>
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > 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
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > I am not sure what’s the best way
> to
>     > > enforce single-
>     > > > instance, I can
>     > > >     >>         >     >
>     > > >     >>         >     > >     > > 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
>     > > >     >>         >     >
>     > > >     >>         >     > >     > >   augment "/rt:routing/rt:control-
> plane-
>     > > protocols/"
>     > > >     >>         >     >
>     > > >     >>         >     > >     > >         + "rt:control-plane-
> protocol" {
>     > > >     >>         >     >
>     > > >     >>         >     > >     > >      when "rt:type =
>     > > 'bfd-types:bfdv1'"  {
>     > > >     >>         >     >
>     > > >     >>         >     > >     > >       description
>     > > >     >>         >     >
>     > > >     >>         >     > >     > >           "This augmentation is
> only
>     > > valid for a control-plane
>     > > >     >>         >     > protocol
>     > > >     >>         >     >
>     > > >
>     > >
>     > >
>     > >
>     > >
>     > > >>         > 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,
>     > > >>         >     > >     > > 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?
>     > > >>         >     >
>     > > >>         >     > >     >
>     > > >>         >     >
>     > > >>         >     > >     > Better would be to simply state in text
> that
>     > > there MUST only be one
>     > > >>         >     >
>     > > >>         >     > >     > instance of this type.
>     > > >>         >     >
>     > > >>         >     > >     >
>     > > >>         >     >
>     > > >>         >     > >     >           + '        derived-from-or-
> sel(../rt:type,
>     > > "msdp:msdp")]) <=
>     > > >>         >     > >     > will loop through *all* instances in the
> list
>     > > every time.  If the list
>     > > >>         >     >
>     > > >>         >     > "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.
>     > > >>         >
>     > > >>         >     > 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
>     > > >>         >     > 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
>     > > >>         >     >
>     > > >>         >     > >
>     > > >>         >     >
>     > > >>         >     > >     >
>     > > >>         >     >
>     > > >>         >     > >     > > Subject: Re: Hi all, about the
> modification
>     > > of MSDP YANG
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Hi Sandy and Xufeng,
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > justifies /rt:routing/rt:control-plane-
> protocols.
>     > > If we do that we
>     > > >>         >     >
>     > > >>         >     > >     > > /rt:routing/rt:control-plane-protocols
> and
>     > > all the multi-instance
>     > > >>         >     > ones
>     > > >>         >     >
>     > > >>         >     > >     > > under
>     > > >>         >     >
>     > > >>         >     > >     > > 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
>     > > >>         >     >
>     > > >>         >     > >     > > instances can have the bfd container.
> This is
>     > > probably not the
>     > > >>         > best
>     > > >>         >     >
>     > > >>         >     > >     > > way but the point is that IMO protocols
> have
>     > > to go under
>     > > >>         >     >
>     > > >>         >     > >     > >         "This augmentation is only valid
> for
>     > > a control-plane
>     > > >>         >     > protocol
>     > > >>         >     >
>     > > >>         >     > >     > >          instance of BFD (type
> 'bfdv1').";
>     > > >>         >     >
>     > > >>         >     > >     > >     }
>     > > >>         >     >
>     > > >>         >     > >     > >           "This augmentation is only
> valid
>     > > for a control-plane
>     > > >>         >     > protocol
>     > > >>         >     >
>     > > >>         >     > >     > >            instance of BFD (type
> 'bfdv1').";
>     > > >>         >     >
>     > > >>         >     > >     > >       }
>     > > >>         >     >
>     > > >>         >     > >     > > Subject: RE: Hi all, about the
> modification
>     > > of MSDP YANG
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Hi Sandy,
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Thanks for the updates.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > we augment /rt:routing/rt:control-plane-
> protocols,
>     > > the “when”
>     > > >>         >     >
>     > > >>         >     > >     > > out the “when” statement and the
> definition
>     > > of the MSDP identity.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Thanks,
>     > > >>         >     >
>     > > >>         >     > >     > > - Xufeng
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Subject: RE: Hi all, about the
> modification
>     > > of MSDP YANG
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Hi Xufeng and Reshad,
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > 主 题 ：RE: Hi all, about the modification
> of
>     > > MSDP YANG
>     > > >>         >     >
>     > > >>         >     > >     > > Hi Sandy and Reshad,
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > that we do not allow multiple instances
> of
>     > > MSDP.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Thanks,
>     > > >>         >     >
>     > > >>         >     > >     > > - Xufeng
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Subject: Re: Hi all, about the
> modification
>     > > of MSDP YANG
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Hi Sandy,
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > I don’t know what warning you are getting
> now
>     > > but from a quick
>     > > >>         > look
>     > > >>         >     > at
>     > > >>         >     >
>     > > >>         >     > >     > >         when "rt:type = 'MSDP'" { <==
> should
>     > > be "rt:type =
>     > > >>         >     > 'msdp:msdp'"
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > HTH,
>     > > >>         >     >
>     > > >>         >     > >     > > Reshad.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > From:
>     > > >>         >     > >     > > Subject: FW: Hi all, about the
> modification
>     > > of MSDP YANG
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Hi all,
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > I deleted some groupings and make the
> model
>     > > more clear.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > 5, - augment of control-plane-protocols
> is
>     > > incorrect. There should
>     > > >>         >     > be
>     > > >>         >     >
>     > > >>         >     > >     > > an identity msdp with
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > statement. Take a look at OSPF YANG for
> an
>     > > example.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: Added the identity and modify
> the
>     > > augmentation, but it
>     > > >>         >     > seems
>     > > >>         >     >
>     > > >>         >     > >     > > 主 题 ：Hi all, about the modification of
> MSDP
>     > > YANG
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Hi all,
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > I think some advices from Reshad should
> be
>     > > discussed:
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > 1, - Not sure why peer-as is needed.
> Don't
>     > > see it in RFC3618.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > 2, - leaf up-time, what's meant by "up
> time"
>     > > in the description? Is
>     > > >>         >     > it
>     > > >>         >     >
>     > > >>         >     > >     > > time it's
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > been created?
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > RFC3618, are these unnecessary? Please
> write
>     > > down your
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > description if you insist on it. If
> nobody
>     > > insist on it, should we
>     > > >>         >     >
>     > > >>         >     > >     > > delete them?
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > was the intention to use those groupings
> more
>     > > than once?
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: These eight groupings are used
> only
>     > > once, should we
>     > > >>         > change
>     > > >>         >     >
>     > > >>         >     > >     > > them to container?
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > 5, - augment of control-plane-protocols
> is
>     > > incorrect. There should
>     > > >>         >     > be
>     > > >>         >     >
>     > > >>         >     > >     > > an identity msdp with
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > statement. Take a look at OSPF YANG for
> an
>     > > example.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: Added the identity and modify
> the
>     > > augmentation, but it
>     > > >>         >     > seems
>     > > >>         >     >
>     > > >>         >     > >     > > Some of the configs (timers?) should be
> part
>     > > of most/basic
>     > > >>         >     >
>     > > >>         >     > >     > > implementations, for
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > other config (e.g. authentication) I can
> see
>     > > why a feature would
>     > > >>         > be
>     > > >>         >     >
>     > > >>         >     > >     > > used.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - "import ietf-ip" should have a
> reference to
>     > > RFC7277
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - organization s/"...PIM( Protocols for
> IP
>     > > Multicast ) Working
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > Group"/"...PIM (Protocols for IP
> Multicast)
>     > > Working Group"?
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - Remove WG Chairs from contact
> information
>     > > as per Appendix C
>     > > >>         > of
>     > > >>         >     >
>     > > >>         >     > >     > > - rfc6087bis-15
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - No copyright in the module description,
> see
>     > > Appendix of
>     > > >>         > 6087bis-15
>     > > >>         >     > for
>     > > >>         >     >
>     > > >>         >     > >     > > - a module description
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > example
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - Module description must contain
> reference
>     > > to RFC, see
>     > > >>         > Appendix C
>     > > >>         >     > of
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > rfc6087bis-15
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: Removed WG chairs and add
> copyright
>     > > from Appendix of
>     > > >>         >     >
>     > > >>         >     > >     > > - grouping connect-source. The name is
> not
>     > > very
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > descriptive. Should this be something
> along
>     > > the lines of
>     > > >>         >     >
>     > > >>         >     > >     > > tcp-connection-source?
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: Changed the name "connect-
> source" to
>     > > "tcp-connection-
>     > > >>         >     > source".
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > pretty terse. e.g. for rpf-peer it says
> "RPF
>     > > peer.". In a case like
>     > > >>         >     >
>     > > >>         >     > >     > > this
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > consider adding more descriptive text or
> a
>     > > reference to the
>     > > >>         > proper
>     > > >>         >     >
>     > > >>         >     > >     > > section in
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > RFC3618
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > or change the must statement to (assuming
> we
>     > > keep the 2
>     > > >>         > features):
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >   must "(not ../holdtime-interval) or (.
> > 1
>     > > and . <
>     > > >>         >     >
>     > > >>         >     > >     > >   ../holdtime-interval)".
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - leaf peer-learned-from, change
> description
>     > > from "The address
>     > > >>         > of
>     > > >>         >     > peer
>     > > >>         >     >
>     > > >>         >     > >     > > - that we learned
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > this SA from ." to "The address of the
> peer
>     > > that we learned this SA
>     > > >>         >     >
>     > > >>         >     > >     > > from."
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: Modified.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - RPC leaf group, I thought we had a type
> for
>     > > IP multicast address?
>     > > >>         >     > If
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: Yes. Added the rt-type reference
> to
>     > > RFC8294.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - s/msdp/MSDP/
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - In rpc msdp-clear-sa-cache, why have
> the
>     > > enum '*' for
>     > > >>         >     >
>     > > >>         >     > >     > > - source-addr. Can't the same technique
> as
>     > > for peer-address be
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > used?
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - MSDP peers are configured in a mesh-
> group,
>     > > did the authors
>     > > >>         >     > consider
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: IMO it is unnecessary because
> the
>     > > states of peers is not
>     > > >>         >     >
>     > > >>         >     > >     > > unified in a mesh-group.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > General:
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - Per Appendix B of rfc6087bis-15: "that
> all
>     > > YANG modules
>     > > >>         > containing
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > 7277, 8022 and 8177 should be included in
> the
>     > > normative
>     > > >>         > reference
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > section.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: Added.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - Section 3 "the irrelevant information",
> add
>     > > a
>     > > >>         >     > reference/explanation
>     > > >>         >     >
>     > > >>         >     > >     > > - for what
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - Section 5 should give a brief
> description
>     > > of what the RPCs do.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - Section 6 any plans for notifications?
> If
>     > > not, just say so.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > [Sandy]: Done.
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - Need Security
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >
>     > > >>         >     > >     > > - Need IANA Considerations, see section
> 3.8
>     > > of rfc6087bis-15
>     > > >>         >     >
>     > > >>         >     > >     > >
>     > > >>         >     >

---

From: Robert Wilton <[email-masked]>
Date: Wed, 24 Oct 2018 16:56:25 +0100

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.

Thanks,
Rob

On 24/10/2018 15:53, Acee Lindem (acee) wrote:
>      > > single control-
>      > > entries doesn't
>      > > modification of MSDP YANG
>      > > >     >>         >     >
>      > > >     >>         >     > >     > >
>      > > >     >>         >     >
>      > > >     >>         >     > >     > > Hi Sandy and Xufeng,
>      > > >     >>         >     >
>      > > >     >>         >     > >     > >
>      > > >     >>         >     >
>      > > protocols/rt:control-plane-
>      > > > protocol.
>      > > >     >>         >     >
>      > > >     >>         >     > >     > >
>      > > >     >>         >     >
>      > > protocols/rt:control-plane-
>      > > > protocol.
>      > > >     >>         >     >
>      > > >     >>         >     > >     > >
>      > > >     >>         >     >
>      > > >     >>         >     > >     > > Regards,
>      > > >     >>         >     >
>      > > >     >>         >     > >     > > Reshad.
>      > > >     >>         >     >
>      > > >     >>         >     > >     > >
>      > > >     >>         >     >
>      > > protocols/rt:control-plane-protocol.
>      > > >>         >     >
>      > > >>         >     > >     > >
>      > > >>         >     >
>      > > protocols/rt:control-plane-protocol.
>      > > >>         >     >
>      > > >>         >     > >     > >
>      > > >>         >     >
>      > > >>         >     > >     > > Regards,
>      > > >>         >     >
>      > > >>         >     > >     > > Reshad.
>      > > >>         >     >
>      > > >>         >     > >     > >
>      > > >>         >     >
>      > > protocols/rt:control-plane-protocol.
>      > > >>         > If
>      > > >>         >     >
>      > > protocols/rt:control-plane-protocol,
>      > > >>         > is
>      > > >>         >     >

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 Oct 2018 16:25:11 +0000

Hi Lada, 

On 10/24/18, 11:55 AM, "yang-doctors on behalf of Ladislav Lhotka" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Acee,

At the risk of retreading old ground, one of the solutions was to allow a default for a key leaf. That seemed reasonable to me.

Thanks,
Acee 
    
    Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Oct 2018 18:59:13 +0200

"Acee Lindem (acee)" <[email-masked]> writes:

> At the risk of retreading old ground, one of the solutions was to
> allow a default for a key leaf. That seemed reasonable to me.

It depends on what "optional key" means:

A. A key may or may not be defined for a "config true" list (as in
"config false" case).

B. A key has to be defined but the key *value* can be omitted for some
   list entries in instance data.

Lada

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 24 Oct 2018 17:25:38 +0000

In the case we're discussing for MLD, it's case B below.

Regards,
Reshad.

On 2018-10-24, 12:59 PM, "yang-doctors on behalf of Ladislav Lhotka" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Oct 2018 10:30:47 -0700

> 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,

Andy

>> 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
>>
>>      > > For #1, as discussed, there is no other better solution at the
>> moment.
>>      > > What would you suggest?
>>      > >
>>      > > Thanks.
>>      > >
>>      > > - Xufeng
>>      > >
>>      > >
>>      > >
>>      > > Guofeng: We removed the paragraph above, and put the values
>> discussed by
>>      > > Mcast Design Team.
>>      > >
>>      > >
>>      > >
>>      > >
>>      > >
>>      > > #7 Leaf interface in the rpc clear*groups on line 1124, 1094 has
>> type
>>      > > string.
>>      > >
>>      > > Describe what values are valid. #9 Leaf group on line 705, 1101,
>> 1131: Is
>>      > > any
>>      > >
>>      > > edit routing control-plane-protocols control-plane-protocol type
>> msdp name
>>      > > ''"
>>      > >
>>      > > >     >> As seems to be the modus operandi for YANG issues, we
>> have 3
>>      > > separate
>>      > > >     >>   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)
>>      > > >     >>   3. Augment the container one level up from the list
>> for
>>      > > singleton
>>      > > >     > But I think there was also a proposal to require the
>> single
>>      > > instance
>>      > > >     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
>>      > > > 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
>>      > > agree that
>>      > > > forcing a name for a single-instance is cumbersome, but I
>> think it is
>>      > > too late to
>>      > > >     >>         - Data tree query: If the singleton "MSDP" is
>> mixed with
>>      > > other protocol
>>      > > > 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-p
>> rotocols
>>      > > and all
>>      > > >     >>         > Thanks for the suggestions. I agree that
>> hard-coding
>>      > > the name is a
>>      > > > bad idea,
>>      > > >     >>         > - We can move the must statement up to
>> restrict max of
>>      > > 1 control-
>>      > > > plane-
>>      > > >     >>         > - Acee/Lada, should a note be added to
>> section 5.3 of
>>      > > 8022bis
>>      > > > regarding how
>>      > > >     >>         >     > > On 2/8/18, 4:42 AM, "yang-doctors on
>> behalf of
>>      > > Ladislav
>>      > > > Lhotka"
>>      > > >     >>         > <yang-docto
>>      > > >     >>         >     > >     On Thu, 2018-02-08 at 09:20
>> +0100, Martin
>>      > > Bjorklund wrote:
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > Hi,
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     >
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > > 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
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > > 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.
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     >
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > But you can also add a must
>> statement
>>      > > that enforces this:
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     >
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     >    augment
>> "/rt:routing/rt:control-plane-
>>      > > protocols/"
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     >          +
>> 'derived-from-or-self(rt:type,
>>      > > "msdp:msdp"'  {
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     >      container msdp {
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     >        must
>>      > > >     >>         >     > >     > 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')])";
>>      > > >     >>         >     >
>>      > > >     >>         >     > >           ..
>>      > > >     >>         >     >
>>      > > >     >>         >     > >         }
>>      > > >     >>         >     >
>>      > > >     >>         >     > >
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     container must not be preceded
>> with a
>>      > > control-plane-
>>      > > > protocol entry
>>      > > >     >>         > of
>>      > > >     >>         >     > the
>>      > > >     >>         >     >
>>      > > >     >>         >     > "elegant" as in "less obvious" ;)  It
>> has the
>>      > > same time complexity
>>      > > > as
>>      > > >     >>         >     > the count() solution.
>>      > > >     >>         >
>>      > > >     >>         >     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
>>      > > >     >>         >     > For each list entry that has this
>> container, the
>>      > > expression is
>>      > > >     >>         >     > >     > Also note that I use
>> derived-from-or-self
>> "/rt:routing/rt:control-plane-
>>      > > protocols/"
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > >         +
>>      > > >     >>         >     > >     > >      when "rt:type = ‘msdp’"
>> {
>>      > > >     >>         >     > >     > >       description "MSDP top
>> level
>>      > > container.";
>>      > > >     >>         >     > >     > > Date: Monday, February 5,
>> 2018 at 6:25
>>      > > PM
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > > To: Xufeng Liu <
>> [email-masked]>,
>>      > > >     >>         > "[email-masked]"
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > > <[email-masked]>
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > > 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
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > > 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
>>      > > >     >>         >     >
>> "/rt:routing/rt:control-plane-
>>      > > protocols/"
>>      > > >     >>         >     >
>>      > > >     >>         >     > >     > >         +
>>      > > >     >>         >     > >     > >      when "rt:type =

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 Oct 2018 18:18:29 +0000

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…

Thanks,
Acee

From: Andy Bierman <[email-masked]>
Date: Wednesday, October 24, 2018 at 1:31 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
Cc: Acee Lindem <[email-masked]>, Martin Bjorklund <[email-masked]>, Xufeng Liu <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, YANG Doctors <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [yang-doctors] Optional key support?

On Wed, Oct 24, 2018 at 8:56 AM, Robert Wilton <[email-masked]<mailto:[email-masked]>> 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 10/24/18, 1:48 AM, "yang-doctors on behalf of Martin Bjorklund" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

     > > *From: *Xufeng Liu <[email-masked]<mailto:[email-masked]>>
     > > *To: *"Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
     > > *Cc: *"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mahesh Sivakumar <
     > > [email-masked]<mailto:[email-masked]>>, Stig Venaas <[email-masked]<mailto:[email-masked]>>, Guofeng <
     > > [email-masked]<mailto:[email-masked]>>, Anish Peter <[email-masked]<mailto:[email-masked]>>, "
     > > [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Liuyisong <
     > > [email-masked]<mailto:[email-masked]>>, Pete McAllister <[email-masked]<mailto:[email-masked]>>, "
     > > [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
     > > [email-masked]<mailto:[email-masked]>> wrote:
     > >
     > > Hi Xufeng,
     > >
     > >
     > >
     > > *From: *yang-doctors <[email-masked]<mailto:[email-masked]>> on behalf of Xufeng
     > > Liu <[email-masked]<mailto:[email-masked]>>
     > > *To: *"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
     > > *Cc: *Mahesh Sivakumar <[email-masked]<mailto:[email-masked]>>, Stig Venaas <
     > > [email-masked]<mailto:[email-masked]>>, Guofeng <[email-masked]<mailto:[email-masked]>>, Anish Peter <
     > > [email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
     > > Liuyisong <[email-masked]<mailto:[email-masked]>>, Pete McAllister <
     > > [email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
     > > *Jan Lindblad*, [email-masked]<mailto:[email-masked]>, +46 702855728
     > >
     > > From: Jan Lindblad [mailto:[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>]
     > >
     > > *From:* pim [mailto:[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>] *On
     > > Behalf Of *Jan Lindblad
     > > *To:* Xufeng Liu <[email-masked]<mailto:[email-masked]>>
     > > *Cc:* [email-masked]<mailto:[email-masked]>; ietf <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
     > > [email-masked]<mailto:[email-masked]>
     > > 收件人：Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>Christian Hopps <[email-masked]<mailto:[email-masked]>>Martin
     > > Bjorklund <[email-masked]<mailto:[email-masked]>>
     > > >     >> On 2/15/18, 8:39 AM, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>
     > > >
     > > > wrote:
     > > >     >>
     > > >     >>     Hi Xufeng,
     > > >     >>
     > > > f.com<http://f.com>>;
     > > [email-masked]<mailto:[email-masked]>> wrote:
     > > >     >>         >
     > > [email-masked]<mailto:[email-masked]>> wrote:
     > > >     >>         >     >
     > > >     >>         >     > >     > > Hi YDs,
     > > >     >>         >     >
     > > >     >>         >     > >     > >
     > > >     >>         >     >
     > > [email-masked]<mailto:[email-masked]>>
     > > >     >>         >     >
     > > >     >>         >     > >     > > Cc: "[email-masked]<mailto:[email-masked]>" <
     > > [email-masked]<mailto:[email-masked]>>,
     > > > "Mahesh
     > > >     >>         > Sivakumar
     > > >     >>         >     >
     > > >     >>         >     > >     > > <[email-masked]<mailto:[email-masked]>>, "
     > > [email-masked]<mailto:[email-masked]>"
     > > >     >>         >     >

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Oct 2018 11:29:14 -0700

On Wed, Oct 24, 2018 at 11:18 AM, Acee Lindem (acee) <[email-masked]> 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…
>
>
>

If YANG-next ever turns into YANG 1.2 we can discuss the complexities of
list instantiation and protocol interactions at that time.
A YANG default is the value that is implemented if no value is provided by
the client.
It means the server MUST fully implement the leaf value semantics as if the
client provided the default value.
IMO this is not the same thing at all as a missing key that is supposed to
mean "key not applicable".

Andy

>
>
> *From: *Andy Bierman <[email-masked]>
> *Date: *Wednesday, October 24, 2018 at 1:31 PM
> *To: *"Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <
> [email-masked]>
> *Cc: *Acee Lindem <[email-masked]>, Martin Bjorklund <[email-masked]>,
> Xufeng Liu <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, YANG Doctors <[email-masked]>, "
> [email-masked]" <[email-masked]>, "pete.mcallister@metaswitch.
> com" <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [yang-doctors] Optional key support?
>
>
>
>
>
>
>
>      > > >     I actually liked this solution; however, instead of picking
> an
>      > > arbitrary "well-
>      > > > forcing a name for a single-instance is cumbersome, but I think
> it is
>      > > too late to
>      > > >     >>         > - Acee/Lada, should a note be added to section
> 5.3 of
>      > > 8022bis
>      > > > regarding how
>      > > >     >>         >     > >     > > a fixed name (msdp-protocol in
> this
>      > > case) for the top level
>      > > > msdp
>      > > >     >>         >     >
>      > > >     >>         >     > >     > > container to exist. Any
> suggestions on
>      > > how to do this
>      > > > better?
>      > > >     >>         >     >
>      > > >     >>         >     > >     >
>      > > >     >>         >     >
> "rt:control-plane-protocol" {
>      > > >     >>         >     >
>      > > >     >>         >     > >     >       when
>      > > >     >>         >     > >     Instead of count(), it is possible
> to use
>      > > the so-called
>      > > > Muenchian
>      > > >     >>         >     > method:
>      > > >     >>         >     >
>      > > >     >>         >     > >
>      > > >     >>         >     >
>      > > >     >>         >     > >         container msdp {
>      > > >     >>         >     >
>      > > >     >>         >     > >           must
> "rt:control-plane-protocol" {
>      > > >     >>         >     >
>      > > >     >>         >     > >     > > Date: Monday, February 5, 2018
> at 6:25
>      > > PM
>      > > >     >>         >     >
>      > > >     >>         >     > >     > > To: Xufeng Liu <
> [email-masked]>,
>      > > >     >>         > "[email-masked]"
>      > > >     >>         >     >
>      > > >     >>         >     > >     > > <[email-masked]>
>      > > >     >>         >     >
> "rt:control-plane-protocol" {
>      > > >     >>         >     >
>      > > >     >>         >     > >     > >      when "rt:type =
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 Oct 2018 18:35:23 +0000

From: Andy Bierman <[email-masked]>
Date: Wednesday, October 24, 2018 at 2:29 PM
To: Acee Lindem <[email-masked]>
Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>, Martin Bjorklund <[email-masked]>, Xufeng Liu <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, YANG Doctors <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [yang-doctors] Optional key support?

On Wed, Oct 24, 2018 at 11:18 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Lada, Andy,

If YANG-next ever turns into YANG 1.2 we can discuss the complexities of list instantiation and protocol interactions at that time.
A YANG default is the value that is implemented if no value is provided by the client.
It means the server MUST fully implement the leaf value semantics as if the client provided the default value.
IMO this is not the same thing at all as a missing key that is supposed to mean "key not applicable".

And I believe the default value for a key leaf would satisfy the requirement… Hopefully w/o the complexities of an N/A key.

Thanks,
Acee

Thanks,
Acee

Andy

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 24, 2018 at 1:31 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Martin Bjorklund <[email-masked]<mailto:[email-masked]>>, Xufeng Liu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, YANG Doctors <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [yang-doctors] Optional key support?

Thanks,
Rob

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Oct 2018 20:37:35 +0200

On Wed, 2018-10-24 at 18:18 +0000, Acee Lindem (acee) wrote:
> 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

> Cc: Acee Lindem <[email-masked]>, Martin Bjorklund <[email-masked]>, Xufeng
> Liu <[email-masked]>, "[email-masked]" <
> [email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> > > protocol. I
> > >      > > >     >>         >     > >     > Also note that I use derived-
> > > from-or-self
> > >      > > instead of equality
> > >      > > > for the
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > identity.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > /martin
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Regards,
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > > Reshad.
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >
> > >      > > >     >>         >     >
> > >      > > >     >>         >     > >     > >   augment

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Oct 2018 11:43:36 -0700

On Wed, Oct 24, 2018 at 11:35 AM, Acee Lindem (acee) <[email-masked]> wrote:

> *Date: *Wednesday, October 24, 2018 at 2:29 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <
> [email-masked]>, Martin Bjorklund <[email-masked]>, Xufeng Liu <
> [email-masked]>, "[email-masked]" <
> And I believe the default value for a key leaf would satisfy the
> requirement… Hopefully w/o the complexities of an N/A key.
>
>
>

So the problem to be solved is that it is too much of a burden on the
client to provide
the default key leaf value?  It is not as if it can be ignored.  Retrieval
of the list
entry will include all the keys.

Edits on the candidate datastore become more complex.
Is that missing key going to be provided in a subsequent edit before the
commit?

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 28 Oct 2018 11:51:14 +0000

Hi Andy,

Date: Wednesday, October 24, 2018 at 2:44 PM

On Wed, Oct 24, 2018 at 11:35 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 24, 2018 at 2:29 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]<mailto:[email-masked]>>, Martin Bjorklund <[email-masked]<mailto:[email-masked]>>, Xufeng Liu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, YANG Doctors <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [yang-doctors] Optional key support?

So the problem to be solved is that it is too much of a burden on the client to provide
the default key leaf value?  It is not as if it can be ignored.  Retrieval of the list
entry will include all the keys.

In some cases (like the case of protocols), the key isn’t applicable. So, semantically it is confusing for the client. We could restrict the key default to keys subsequent to the first.

Edits on the candidate datastore become more complex.
Is that missing key going to be provided in a subsequent edit before the commit?

I can see your point here. We’d need to define the behavior and I’d say “no”, if a default key is changed, it is a separate list entry.

Thanks,
Acee

Thanks,
Acee

Andy

Thanks,
Acee

Andy

Thanks,
Rob

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 28 Oct 2018 07:46:18 -0700

On Sun, Oct 28, 2018 at 4:51 AM, Acee Lindem (acee) <[email-masked]> wrote:

> *Date: *Wednesday, October 24, 2018 at 2:44 PM
> In some cases (like the case of protocols), the key isn’t applicable. So,
> semantically it is confusing for the client. We could restrict the key
> default to keys subsequent to the first.
>
>
>
> I can see your point here. We’d need to define the behavior and I’d say
> “no”, if a default key is changed, it is a separate list entry.
>
>
>

I agree default for a key leaf is fine if it works this way.
The list instance is set when it is created.
The protocol should have an explicit "rename" operation in order to change
a key leaf.

Andy