Subject: Re: [Teas] Status update on draft-ietf-teas-yang-sr-te-topo

From: tom petch <[email-masked]>
Date: Tue, 3 Aug 2021 10:30:39 +0000

From: Teas <[email-masked]> on behalf of Xufeng Liu <[email-masked]>
Sent: 24 July 2021 01:08

Current Status:

  *  Received further valuable comments from Tom Petch.
  *  Received valuable comments from Kenichi Ogaki
  *  Posted updated version -10, to address Tom's comments above.

Open Issues:

  *  Authors are continuously working on addressing Kenichi's comments.

Next Steps:

  *  Follow-up to resolve comments.
  *  Welcome further reviews and suggestions.
  *  Working Group Last Call after completing the above.

<tp>

I note that you have the same spelling mistakes as draft-qu-mpls-mpls-msd-yang which usually indicates plagiarism, not that there is anything wrong with that in the IETF! I note that while the two I-D have the same name listed, the e-mail addresses are slightly different.  I have included one of those as cc:.

I say this because both I-D puzzle me in the same way.  What is node-msd that it is a list keyed on msd-type?  And what is msd-type for that matter, same in both I-D?

I understand a node having an MSD, the lowest of those on a link but how can that be a list and why key it on msd-type which appears to be the signalling protocol in use?  I do not understand.

I note that in -08 node-msd was not a list and that f made more sense to me.

If a list is needed, then I think that you need to say why, how it is used - or reference another SR I-D/RFC where it is explained - and why it is keyed on what it is keyed on.

Equally fundamentally, what has node-msd got to do with te or topo or MPLS or ...  I see it as a property of a node which would ideally be part of a base definition of a node even if SR was not in use or part of a base SR augmentation as opposed to what we seem to be getting of  multiple I-D creating their own definitions.

I will post some editorial comments separately.

Tom Petch

Thanks,
- Xufeng

---

From: tom petch <[email-masked]>
Date: Tue, 3 Aug 2021 10:41:49 +0000

From: Teas <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 03 August 2021 11:30

Current Status:

Open Issues:

Next Steps:

<tp>

Some more editorial comments on -10

spring-sr-yang is now RFC9020; needs changing in lots of places

s.2.6 
'SR SMPL'

YANG module
'singling MSD'

'Adjacentcy'

s.6

missing solidus on the first path statement

Appendix B

Diagram might be better if a router-id could be squeezed in somewhere.

Tom Petch

Thanks,
- Xufeng

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas