Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[神明達哉 <[e-mail]>]

At Fri, 28 Feb 2020 07:54:28 +0000,
"Xiejingrong (Jingrong)" <[e-mail]> wrote:

> The design of PSP for the benefits of deployment is based on the understanding
> that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
> modified in the future, the PSP may also need to change accordingly.

No, it violates Section 4 of RFC8200.  It's a pity that we have to
discuss it at this level due to the poor editorial work then (I was
also responsible for that as one of those reviewing the bis draft),
but anyone who involved the discussion should know the intent of this
text intended to say (borrowing from Ron's text) "Extension headers
cannot be added to a packet after it has left the its source node and
extension headers cannot be removed from a packet until it has arrived
at its ultimate destination".  It might look "an attempt of blocking
an innovation by a small group of vocal fundamentalists", but if you
see the responses without a bias, you'd notice that even some of those
who seem neutral about the underlying SRv6 matter interpret the text
that way.

I'd also note that simply because PSP violates RFC8200 doesn't
immediately mean it (PSP) "needs to change".  It can update RFC8200 with
explaining why it's necessary and justified.  That's what I
requested as you summarized:

> Jinmei: it should say it updates this part of RFC8200 and explain why it's justified.

And, since PSP at least wouldn't break PMTUD, I guess the update
proposal will have much more chance to be accepted than a proposal
including EH insertion.  On the other hand, pretending there's no
violation will certainly trigger many appeals and objections at the
IETF last call (I'll certainly object to it).  In the end, it can
easily take much longer, or even fail, than formally claiming an
update to RFC8200.

--
JINMEI, Tatuya