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" <daedulus@xxxxxxxxxxxxx> 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" <daedulus@xxxxxxxxxxxxx> 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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
