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

Hi Jinrong,
On 25-May-20 16:56, Xiejingrong (Jingrong) wrote:
> Hi Brian,
> 
> Maybe the more you assume "Destination node" as "final/ultimate destination node", the more you will be confusing.
> To me, "Destination node" is very simple to mean "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field".

That's exactly why the text in RFC8200 has been interpreted in two different ways, because some people have assumed the other meaning (i.e. the final destination, if there is a routing header). When we have such an ambiguity in a standard, it's necessary to fix the standard, in my opinion.

Regards
   Brian

> Just think of the "destination node" as a node who is "listening" to an address, either a unicast address, or a multicast address.
> If a packet with the destination address being an address the "destination node" listening to, the "destination node" will <catch> it, and processing it either way, for example:
> (1) it could just simply forward it according to further (not very deep) information in any EH.
> (2) it could further dispatch it to the APP according to some (fairly deep) information.
> (3) it could discard the packet when it doesn't even be able to know how deep the information is.
> 
> This way, the many text about EH (including the 4.6 DOH mentioned below) in RFC8200/2460/1883 is clear IMO.
> 
> If there is need to describes "final/ultimate destination node", the further qualifying text will be added to the "Destination address". 
> There *ARE* many examples in the RFC8200/2460/1883, and one could find those text "final/ultimate" in those RFCs.
> 
> Thanks
> Jingrong
> 
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: Monday, May 25, 2020 5:02 AM
> To: 6MAN <6man@ietf.org>
> Subject: 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
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 