Re: [spring] Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard

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

Hi Tom 
Please see the -27 version. I believe it addresses your concerns as well as changing "http:" to "https:". 
Thanks,
Acee

On 11/26/20, 5:43 AM, "tom petch" <[e-mail]> wrote:

    I have looked at -26 and it looks good apart from BGP.

    BGP gets a mention in passing but does not get the same treatment as the 
    protocols of the LSR WG.  I am unclear whether or not this I-D is 
    intended to include networks using BGP or not with e.g. signalling of 
    MSD and would value a clarification in the I-D.

    I wonder about the final D in
    Maximum SID Depth (MSD)D
    in the YANG; I suspect that it is spurious.

    Tom Petch

    On 24/11/2020 09:34, tom petch wrote:
    > On 23/11/2020 17:27, Acee Lindem (acee) wrote:
    >> Hi Tom,
    >>
    >> See a couple responses inline enclosed in <acee> and </acee>. We are
    >> addressing the rest of your comments.
    >>
    >> On 11/18/20, 7:39 AM, "tom petch" <[e-mail]> wrote:
    >>
    >>      IANA Considerations does not register the module names used in
    >> the modules
    >>
    >> <acee>
    >> This is in the IANA considerations...
    >
    > <tp>
    > Indeed; I do not see a registration of ietf-segment-routing-mpls!
    >
    >>     This document registers a YANG module in the YANG Module Names
    >>     registry [RFC6020].
    >>
    >>        name: ietf-segment-routing-common
    >>        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common
    >>        prefix: sr-cmn
    >>        reference: RFC XXXX
    >>
    >>        name: ietf-segment-routing
    >>        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing
    >>        prefix: sr
    >>        reference: RFC XXXX
    >>
    >>        name: ietf-segment-routing
    >>        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
    >>        prefix: sr-mpls
    >>        reference: RFC XXXX
    >> </acee>
    >>
    >>      Examples are IPv4 only, IPv6 would be good
    >>
    >>      BGP is included when it comes to defining a router-id but is ignored
    >>      everywhere else, such as signalling MSD, protocol extensions etc
    >>
    >>      reference "RFC XXXX" would be improved by including the title in all
    >>      cases not just some
    >>
    >>      the scheme http: appears in many places.  It would be lovely if this
    >>      really was the scheme but I fear that it is not
    >> <acee>
    >> This is directly from the RFC 8407 template in Appendix B. What would
    >> you suggest?
    >
    > <tp>
    > Many I-D do now specify https: since that is now the only option
    > supported by the IETF; I have seen this called for by an AD.
    >
    >
    >> </acee>
    >>
    >>      module srcmn
    >>        the upper bound must be larger
    >>        the value must be greater
    >>      consistency is good - I think greater is better
    >>
    >>      8.3
    >>      operation states
    >>      usually operational
    >>
    >>      two imports lack references
    >>
    >>      typedef router-id
    >>      this is a well known type from RFC8394; it seems likely to
    >> confuse to
    >>      redefine it with a related but different meaning
    >>
    >>      leaf enabled
    >>      enables protocol extensions
    >>      which protocols?
    >>
    >>      leaf protected
    >>      it is used to protect
    >>      how does it do that:-)
    >>
    >>      enum dual
    >>      ... In this case will be advertised with backup flag set
    >>      What is the backup flag?  It does not feature in RFC8660.  Needs an
    >>      explanation and reference
    >>
    >>      container link-msd
    >>        list link-msds
    >>          leaf msd
    >>      The usual YANG convention is for a list to be plural and the leaf
    >>      singular.  You have the plural list but not the leaf.
    >> <acee>
    >> So you are asking for a change from "leaf msd" to "leaf link-msd"?
    >
    > <tp>
    > Yes I would especially given node-msd.  I wish that YANG Guidelines said
    > more about container names.  I think that having the same identifier for
    > container, for list, for leaf (which I have seen in another I-D)
    > will lead to mistakes so having a convention for list and leaf will
    > reduce mistakes but having another for container would be even better.
    > That said, I have yet to think of a good convention
    > In passing, must link-msd be >= node-msd?
    >
    >> </acee>
    >>
    >>
    >>   And who needs the
    >>      container?  This is mpls not a common module that might be
    >> augmented so
    >>      what does the container give apart from complexity?
    >>
    >>      list policy
    >>        leaf string
    >>      YANG string caters for very large items of very complex character
    >> sets.
    >>        Is that desirable?
    >> <acee>
    >> IETF models normally do not limit identifiers. An individual
    >> implementation could do this with a deviation.
    >
    > <tp>
    > I know - I did see an AD challenge that, I think in IESG review, not
    > long ago.  SMI was better at this!
    >
    > Tom Petch
    >
    >> </acee>
    >>
    >> Thanks,
    >> Acee
    >>
    >>      leaf used
    >>      will used plus free equal size?
    >>
    >>      Indicates if the binding is /instal/installed/
    >>
    >>      notification-segment-routing-global-srgb-collision
    >>      a mix of conflict and collision;  consistency is good and I
    >> prefer the
    >>      latter which is the name of the notification
    >>
    >>      containing /s/a/ mapping
    >>
    >>      ... sid collision
    >>      again consistency good, prefer collision to conflicting
    >>
    >>      s.9
    >>      I would have thought the srgb worthy of mention under sensitive
    >> nodes
    >>
    >>      Tom Petch
    >>
    >>
    >>      On 16/11/2020 19:32, The IESG wrote:
    >>      >
    >>      > The IESG has received a request from the Source Packet Routing
    >> in Networking