Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

[<[e-mail]>]

Fernando,

> From: Fernando Gont [mailto:[e-mail]] 
> Sent: Wednesday, December 11, 2019 12:25 AM
> 
> On 10/12/19 08:16, [e-mail] wrote:
> > Fernando,
> > 
> >> From: spring [mailto:[e-mail]] On Behalf Of Fernando Gont
> >> Sent: Sunday, December 8, 2019 1:55 AM
> >>
> >> On 7/12/19 15:40, Robert Raszuk wrote:
> >>> Hi Fernando,
> >>>  
> >>>
> >>>     The online possible instantiation of "Destination Address" as in RFC8200
> >>>     is the final destination of the packet.
> >>>
> >>>
> >>> No. That is incorrect. 
> >>>
> >>> Hint: Please read carefully RFC2473. 
> >>
> >> If you think a document on tunnels rules how IPv6 operates, and its
> >> end-to-endianness, then you have a huge problem reading specs.
> >>
> >> So I will not enter that game, because it would be accepting to be
> >> mocked at.
> >>
> >> I'll wait for a few days for our INT AD's response (Suresh), a response
> >> from the spring chairs (if any), and a response from the RTG AD(s).
> > 
> > I'm not sure what response to what question you expect from spring chairs.
> 
> A number og wg participants are letting the chairs and ADs aware that a
> wg document contains an outright violation of an Internet Standard

That point is noted.
But given that a number of wg participants are saying the opposite, we need to go a bit deeper in the discussion. That's what I've tried to initiate and I believe that we have made progress.

My understanding is that you are saying that
PSP and USP, as defined in [1] and more specifically "Pop the SRH"  contradict with [2] and more specifically 
"   Extension headers [...]  are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node [...] identified in the Destination Address field
   of the IPv6 header."


More specifically, your point is that " the Destination Address field of the IPv6 header" is to be understood as " final destination node"
https://mailarchive.ietf.org/arch/msg/ipv6/Ku-kKBE-vG5QGdT2DvqLxMQpRik


[2] https://tools.ietf.org/html/rfc8200#section-4
[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.1




Is there another technical point relating to your " outright violation of an Internet Standard" or is this the only one?


> that
> spring is not in a position of changing.

6man consensus is written in RFC 8200. I can read it as any other one. Actually you are the one trying to modify that text.
But to your point, believe me, I'll be more than happy to give that ball to someone else. E.g. to my AD then IESG and flagging that point in the shepherd report.
I'll also monitor your above errata, to see if it's been accepted or rejected. That will typically be a strong input in the balance. 

> I deem that as a major issue, and I'm curious how you might possible
> ignore it, declare consensus, and ship and request publication of this
> document.

Noted.
I'm not ignoring it. Quite the contrary I'm the one engaging the discussion with you in order to understand the real technical point that you want to make.
The exercise is not to 'declare consensus' but "rough consensus". Possibly, any position, including yours may be in the rough.
'Request publication' is not publishing the RFC. It's to give the ball to the AD, then IETF last call, then IESG to review beyond the WG. That's typically a way to handle points which are beyond the original WG. 

--Bruno
 
> > 
> >>> From: spring [mailto:[e-mail]] On Behalf Of Fernando Gont
> >>> Sent: Saturday, December 7, 2019 6:43 PM
> >>>  The online possible instantiation of "Destination Address" as in RFC8200 is the final destination of the packet.
> > 
> > It appears to me that, at minimum, multiple opinions have been expressed on this point, including from Suresh. So, assuming that by "online" you meant "only", the statement "only possible" seems excessive to me.
> 
> I ask again: please read RFC8200, and in the context of RFC8200, please
> tell me what can be in the Destination Address other than the ultimate
> destination of the packet.
> 
> 
> Then, if you cannot come up with a good answer, then you might need to
> accept that "Destination Address", in the context of RFC8200, is the
> ultimate destination of a packet.
> 
> And, since we are at it, please let me know if IPv6 is and end to end
> protocol. And, if it is, how does that e2e-ness work with inserting and
> removing EHs on the path to the ultimate destination of a packet.
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.