Hi Fernando, I am amazed to read that you believe that you have the sole power to retroactively re-interpret the wording of existing RFCs and make changes to said wording to give documents that have existed for many years (RFC2460 more than 20 years) a new meaning.
Interesting. Where can I obtain such superpowers? Best, Dirk On Wed, Feb 26, 2020 at 4:36 PM Fernando Gont <ferna...@gont.com.ar> wrote: > On 26/2/20 11:01, Pablo Camarillo (pcamaril) wrote: > > Hi Mark, > > > > Thank you for your feedback. Please see inline [PC1]. > > > > Cheers, Pablo. > > > > -----Original Message----- From: Mark Smith > > <markzzzsm...@gmail.com> Date: Wednesday, 26 February 2020 at 01:31 > > To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com> Cc: Ron Bonica > > <rbon...@juniper.net>, "Joel M. Halpern" <j...@joelhalpern.com>, > > "spring@ietf.org" <spring@ietf.org> Subject: Re: [spring] Is srv6 PSP > > a good idea > > > > Hi Pablo, > > > > On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril) > > <pcama...@cisco.com> wrote: > >> > >> Hi Ron, > >> > >> I guess we are making some progress here but going in some circles. > >> So far we have moved from “this violates RFC8200” to “there are no > >> use-cases or benefits” to “this is complex for an ASIC” to “what is > >> the benefit again” and now back to “this is complex for an ASIC”. > >> > > > > As far as I know, the next header field in both the IPv6 fixed > > header and in extension headers is immutable while the packet is > > travelling within the network, as is the payload length field in the > > IPv6 base fixed header. > > > > [PC1]: Did you just make this up? ;-) RFC8200 does not talk about > > mutability. > > > > Nothing in RFC 8200 modifies those fields while the packet is in > > flight between the packet's original source and final destination, > > nor is there anything in RFC 8200 that specifies how to do those > > modifications and any other discussion about the consequences and > > considerations when doing so. > > > > [PC1]: I disagree with you. As a matter of fact RFC8200 allows the > > deletion of an extension header at a node identified in the > > destination address of the packet (page 8 paragraph 2). > > Unfortunately, the amount of creativity that has been applied during the > last few years when it comes how to read RFC2460 and RFC8200 has meant > that we have had to work harder and harder to clarify the wording in > RFC2406 and RFC8200 for folks to understand and recognize what has > always been the specification and intent of IPv6. > > I have made yet another attempt to clarify the text here: > https://www.rfc-editor.org/errata/eid5933 > > I'd hope that the submitted errata is processed, the existing spec is > honored and respected, and folks submit a formal specification update if > they mean to change IPv6 -- as opposed to try to circumvent the spec for > the n-th try. > > Thanks, > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
