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

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> Hi,
> 
> It has been discussed before.
> It is already allowed for config=false nodes so the change would be to
> allow config=true nodes
> to have no keys.
> 
> Each time it comes up, somebody mentions that
> (a) NETCONF/RESTCONF has no mechanism to delete all list entries
> (b) The client cannot create more than 1 entry. How does the server know
>      the next entry is a different instance or replacing the first instance?

I don't think these were the reasons.  See the proposal that was on
the table for 1.1:

http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10

and the discussion:

https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1&index=bwacmVipuJMakMFjDXXCZMXCTAA



/martin


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