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

[tom petch <[e-mail]>]

On 27/11/2020 14:35, Acee Lindem (acee) wrote:
> Hi Tom
> Please see the -27 version. I believe it addresses your concerns as well as changing "http:" to "https:".

Acee
I was too slow to see -27 but have looked at -28:-)  Yes I like the 
references to BGP.  I do sense a reluctance to reference I-D from other 
WG with the potential delays that can cause so that e.g. 'weight' could 
reference an IDR I-D alongside the LSR ones but I am not too fussed 
about that.  I do see a 'deptt' that might be 'depth' in a BGP reference 
to RFC 8814.
I think that s.3 needs updating.  I have done my homework and see the 
split in the YANG modules that came in with -15.  I think that s.3 
describes the old segment-routing when it had some data in it which it 
no longer has.  The description clause in segment-routing also probably 
overstates the case for what it now is, just an anchor waiting to be 
augmented.
I note that Table 1 omits the prefix defined in this I-D which I can 
live with.

Tom Petch


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