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

[tom petch <[e-mail]>]

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