At Thu, 16 Mar 2017 05:16:55 +1300,
Brian E Carpenter <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
In the mean time, I think it is way too premature to come to conclusion on
what text should be used for RFC2460bis and I recommend that the current
text is left unchanged until we figured out what to do with EH insertion.
I believe that we have figured it out: extension header insertion is harmful
to Internet interoperability.
I fully agree with Suresh's understanding of the rough consensus.
I also support Suresh's proposal.
BTW,
At Wed, 15 Mar 2017 15:55:00 +0000,
"Stefano Previdi (sprevidi)" <sprevidi(_at_)cisco(_dot_)com> wrote:
Originally RFC2460 stated that only the source of the packet is
entitled to add an EH. Now we’re going to propose that the source
“domain” of the packet is allowed to insert EHs. [...]
In order to have a more productive discussion, we are writing a
draft on header insertion that will be submitted as soon as the
windows re-open (during ietf week).
IMHO this plan explains exactly why we rather need to make it more
explicit in rfc2460bis that this version of spec does not assume EH to
be inserted or deleted except at the source node (not "domain"). I'm
totally open to the discussion of possible extensions with the concept
of "source domain". But it should be fair to say it will take time,
at least for months, and quite likely more than a year. If we keep
the rfc2460bis text "ambiguous" in the meantime, we'll leave the risk
that it's interpreted more loosely and someone develops an
implementation that violates the assumption more casually. To me,
it's more responsible to be more explicit in the current specification
to prevent further accidental misunderstanding unless and until we
have the possible revised conditions.
--
JINMEI, Tatuya