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

Replying to myself:
On 25-May-20 09:02, Brian E Carpenter wrote:
> 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.

On another thread, James Guichard said:

> [1] RFC8200 section 4.1
> 
>       note 1: for options to be processed by the first destination that
>               appears in the IPv6 Destination Address field plus
>               subsequent destinations listed in the Routing header.
>
>       note 3: for options to be processed only by the final destination
>               of the packet.
> 
> ** note 1 is for DOH preceding routing header and note 3 is for DOH after routing header.

Fair enough, but that is a very obscure way of stating it, hidden inside the section about the ordering of headers. It should be stated in more explicit language in the discussion of the DOH itself.

   Brian

> 
> 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
>> --------------------------------------------------------------------
>>
> 