Hi Tom,
On 11/24/20, 4:34 AM, "tom petch" <[email protected]> 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" <[email protected]> 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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
