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

["Acee Lindem (acee)" <[e-mail]>]

Read through the discussion and it is a shame we can't converge on a solution. Is YANG 1.0 compatibility the major issue? 
Thanks,
Acee

On 10/24/18, 1:48 AM, "yang-doctors on behalf of Martin Bjorklund" <[e-mail] on behalf of [e-mail]> wrote:

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