Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

I believe there is one point that this draft still leaves unclear.

RFC8200 says:
"4.6.  Destination Options Header

   The Destination Options header is used to carry optional information
   that need be examined only by a packet's destination node(s)."

I believe we need to clarify whether this means the current destination node(s), or the final destination node(s), if a Routing Header is present.

Regards
   Brian Carpenter

On 06-May-20 13:12, 神明達哉 wrote:
> I'd like to clarify a few things about
> draft-bonica-6man-ext-hdr-update-03 based on the comments made in
> today's interim meeting.  I speak only for myself as a coauthor of the
> draft, of course, but I believe I'm generally on the same page as Ron
> for these points.
> 
> First off, the purpose of this draft is NOT to prevent future
> "innovations" on using extension headers (especially in terms
> of insertions and deletions) forever.  Protocols evolve over time, and
> RFCs have been and will be continuously updated or obsoleted with new
> requirements, changes in assumptions, or "innovations".  Even if this
> draft intended to prevent such changes it wouldn't be impossible in
> practice.  I thought that's too obvious to mention, but if we really
> worry about this draft to act as an "innovation blocker", we could add
> the obvious note.
> 
> Secondly, in a sense this draft indeed clarifies an "obvious" point:
> "the node identified in the Destination Address field of the IPv6
> header" in Section 4 of RFC8200 means the ultimate destination, not an
> intermediate node specified in a routing header, regarding "not [...]
> inserted, or deleted by any node".  It was actually obvious to me and
> so it's unfortunate that we have to clarify such a point.  But the
> recent discussion on draft-ietf-spring-srv6-network-programming proves
> that it's not obvious for some others and can even be used as a reason
> to pass a WGLC (and, in fact, I surprisingly realized that the RFC text
> could literally read in a different way).  So I believe we need an
> explicit clarification.
> 
> Third, several people suggested we should rather focus on conditions
> where we can loosen the restrictions.  That effort is certainly highly
> appreciated and I'll support that, but I'd say that's a different
> topic than this draft, nor can it substitute for this draft.  RFC 8200
> specified the most generic principle and behavior of the IPv6
> protocol.  If we leave the ambiguity (I'd rather say a "bug") in the
> general protocol, we'll also leave it open for future protocols to
> casually violate the intent without giving considerations on the
> conditions that allow the exception.  So IMO we need both: fixing the
> "bug" of the general case, and work on detailing the conditions to
> allow exceptions.
> 
> I don't expect everyone agrees on all of my points, but at least I
> hope it helps understand the motivation of the draft more accurately.
> 
> --
> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 