Re: [Last-Call] 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, 

On 11/24/20, 4:34 AM, "tom petch" <[e-mail]> 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!

Yes - I see the typo now that you pointed out which one. 

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

As long as the URLs work, I don't see a problem with either. 


    > </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
Like you said, this would be the third time for link-msd(s). I'll see what my co-authors think. 


    In passing, must link-msd be >= node-msd?
Yes - this is clear in the associated MSD protocol drafts. 

    > </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!

Since we have standardized on a maximum length for identifiers or even policy identifiers, I'm not going to pick one specific to this draft. It goes without saying that implementations will have a limit. 

Thanks,
Acee

    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