In my experience, if there is a requirement for collaborating with
another working group on a topic, it is both helpful and important to
spell that out and have it agreed as part of the adoption process. If
it is not dealt with then, it is MUCH harder to deal with later.
Yours,
Joel
On 3/20/19 6:39 PM, Darren Dukes (ddukes) wrote:
Hi Ron, the authors are suggesting this document for working group
adoption, not for last call.
When the working group adopts it, the working group starts to work on it.
If the working group decides to address header insertion and address
that with 6man then the working group can take on that work, but it does
not need to block this document being adopted.
Darren
*From: *spring <spring-boun...@ietf.org> on behalf of Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org>
*Date: *Sunday, March 17, 2019 at 4:53 PM
*To: *"bruno.decra...@orange.com" <bruno.decra...@orange.com>, SPRING WG
<spring@ietf.org>
*Cc: *"draft-filsfils-spring-srv6-network-programm...@ietf.org"
<draft-filsfils-spring-srv6-network-programm...@ietf.org>
*Subject: *Re: [spring] IPR Poll for
draft-filsfils-spring-srv6-network-programming
Bruno,
While I like many things about this draft, I don’t think that it is
ready for adoption. Reasons follow:
* Section 4.1 appears to contradict Section 4.3.1 of
draft-ietf-6man-segment-routing-header. In particular, consider the
behavior when Segments Left equals 0.
* Sections 4.13, 4.14. 4.21.1 and 4.21.2 appear to be in conflict with
RFC 8200 [1] [2].
* The intent of section 4.19 is unclear.
* As Adrian points out, the draft extends the semantics of the IPv6
address. Such a decision may have wide-reaching impact, and should
be socialized with a wider community (6man, INTAREA WG, V6OPS)
* The draft appears to be in conflict with
draft-ietf-6man-segment-routing-header regarding how extension
headers after the SRH are processed. According to
draft-ietf-6man-segment-routing-header, subsequent extension headers
are processed out of order, potentially in conflict with RFC 8200.
According to this draft, subsequent extension headers are ignored.
[1] According to RFC 8200, “Each extension header should occur at most
once, except for the Destination Options header, which should occur at
most twice (once before a Routing header and once before the upper-layer
header).”
[2] According to RFC 8200, “extension headers must be processed strictly
in the order they appear in the packet” . Sections 4.13 and 4.14
violate this rule by prepending an SRH before the SRH that is currently
being processed.
Ron
*From:* spring <spring-boun...@ietf.org> *On Behalf Of
*bruno.decra...@orange.com
*Sent:* Wednesday, March 13, 2019 2:50 PM
*To:* SPRING WG <spring@ietf.org>
*Cc:* draft-filsfils-spring-srv6-network-programm...@ietf.org
*Subject:* [spring] IPR Poll for
draft-filsfils-spring-srv6-network-programming
Hi authors, SPRING WG,
In parallel to the call for adoption for
draft-filsfils-spring-srv6-network-programming (1), we would like to poll for
IPR.
If you are aware of IPR that applies to
draft-filsfils-spring-srv6-network-programming please respond to this email.
If you are aware of IPR, please indicate whether it has been disclosed in
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more
details).
If you are an *author or contributor* please respond to this email regardless
of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if you
are aware of IPR that has not yet been disclosed.
This document will not advance into the working group until IPR confirmations
have been received from all authors and contributors.
Thank you,
(1)https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dsrv6-2Dnetwork-2Dprogramming-2D07&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=g5euhKG6OY3m1hMFewvX_AhsPNPcaeHrTSLS3oY3KoM&s=5KlDTs7QncIP0FnevaMhAHEIjoQLlCw9xVVUrR40dqY&e=>
--Bruno & Rob.
_________________________________________________________________________________________________________________________
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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
