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

[Robert Raszuk <[e-mail]>]

>  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 in your view building any solution which relies on
encapsulation/tunneling for IPv6 kills its end-to-endianness dogma then
this is a very interesting individual WG member comment.

In the meantime till IETF moves Standards Track  RFC2473 to historic status
or updates it with some other spec it remains a valid document.

Cheers,
Robert.


On Sun, Dec 8, 2019 at 3:46 AM Fernando Gont <[e-mail]> wrote:

> 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).
>
> Then I will escalate the problem as required, including a formal appeal,
> if necessary.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>