Robert, your description of the conflict situation does not match my
understanding.
A new rFC can always update existing RFCs. However, it can't do so
silently. If this document wants to make a change to 8200's rules, it
needs to say so. And explain the benefit. And have the proposal
discussed in 6man.
The current document that has requested working group adoption does not
address these needs.
Yours,
Joel
On 3/17/19 10:17 PM, Robert Raszuk wrote:
Dear Ron,
While authors may address your other questions allow me to express an
opinion regarding your observation:
"conflict with RFC 8200 [1] [2]"
As written today RFC 8200 provides rules for insertion and handling of
those extension headers which are enumerated in said RFC and are listed
in IANA IPv6 Extension Header Types registry. SRH is not part of either
of those lists.
It also has been communicated very clearly by 6man chairs and ADs when
RFC8200 was proceeding that any future document can update it when it
defines new types of extension headers therefor I find your reasoning of
"conflict" quite bizarre.
Kind regards,
R.
On Sun, Mar 17, 2019 at 9:52 PM Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org
<mailto:40juniper....@dmarc.ietf.org>> wrote:
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
<mailto:spring-boun...@ietf.org>> *On Behalf Of
*bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
*Sent:* Wednesday, March 13, 2019 2:50 PM
*To:* SPRING WG <spring@ietf.org <mailto:spring@ietf.org>>
*Cc:* draft-filsfils-spring-srv6-network-programm...@ietf.org
<mailto: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 <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
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
