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
