Hi Joel, The way I would handle it is to proceed with the current document in SPRING and use it as indicator of benefits while in the same time issue a new draft in 6man updating RFC8200 not by duplicating this draft, but using it as justification for the update.
Going now to 6man with individual submission not really related to IPv6 is IMHO not the best strategy. Btw this thread is about IPR pool ... I think Ron may have mixed the threads :) Best, R. On Mon, Mar 18, 2019 at 8:44 AM Joel M. Halpern <[email protected]> wrote: > 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 > > <[email protected] > > <mailto:[email protected]>> 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.____ > > > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
