Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Hi Bruno,

Many thanks for your comments.
Please see inline.

Thanks,
Pablo.

From: spring <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Thursday, 5 December 2019 at 18:50
To: 'SPRING WG List' <[e-mail]>, draft-ietf-spring-srv6-network-programming <[e-mail]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi authors,

As an individual contributor, please find below some comments.



Ø    S03.      Send an ICMP Parameter Problem message to the Source Address
               Code TBD-SRH (SR Upper-layer Header Error),

If TBD-SRH is defined in another document, please reference it in this text and add a normative reference.
PC: The related IANA allocation has been done in the SRH Proposed Standard. TBD-SRH has been replaced by the allocated value (4).

Otherwise, please add this in the IANA consideration section of this document.
--
As a general comment, I find that there is a lack of normative keywords. Please check for “should”, “cannot”, “can”, “can’t”, shouldn’t”, “should not”… and please consider using normative keyworks.
PC: I agree. This has been suggested by Adrian as well. I have done all these replacements and others.

e.g.,
“an End SID cannot be the last SID of a SID list and cannot be the DA of a packet without an SRH”
What about using “MUST NOT”?


“Hence the Upper-layer header should never be processed.”
What about using “MUST NOT”?


“any function can be attached to a local SID:”

MAY?


“The End.DX6 SID must be the last segment in a SR Policy”

MUST?


“the following must be done.”

MUST?


“Any SID instance of the End.DX2V behavior must be associated with an L2 Table T. »

MUST?

….

---
§IANA consideration section


-          Do we need such large pools for both experimental and private use?

-          Do we need both an experimental and private pool?

-          Given that the range of code point is large and that we probably want to foster innovation use without requiring heavy IETF process, I would suggest having a FCFS range https://tools.ietf.org/html/rfc8126#section-4.4

-

   When code points are set aside for Experimental Use, it's important
   to make clear any expected restrictions on experimental scope.  For
   example, say whether it's acceptable to run experiments using those
  code points over the open Internet or whether such experiments should
   be confined to more closed environments.  See [RFC6994<https://tools.ietf.org/html/rfc6994>] for an
   example of such considerations.

https://tools.ietf.org/html/rfc8126#section-4.2

PC: I agree with your comments that experimental and private use are way too large. This has also been raised by Adrian Farrel.
I also agree with the FCFS range. I have proposed:
-Remove the experimental and private use pools
-Change the Specification Required pool to FCFS
-Create one new pool (in the old space of experimental and private) that is Reserved and for future use of IETF.

---
§IANA consideration section


“documents should clearly identify the registry into which each value is to be registered.”
https://tools.ietf.org/html/rfc8126#section-3

PC: I guess you refer in the Ethernet part. Fixed.
---


Nits:
“Push a the MPLS label stack”
:s/a the/the

PC: Fixed. Thank you.


Thank you,
Regards,
--Bruno



From: ipv6 [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, December 5, 2019 6:15 PM
To: 'SPRING WG List'
Cc: [e-mail]; draft-ietf-spring-srv6-network-programming
Subject: WGLC - draft-ietf-spring-srv6-network-programming


Hello SPRING,



This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].



Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.



You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.



If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)



Thank you,

Bruno



[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05




_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.