In my view – there is a fundamental difference. The stated rfc refers to a derived interface identifier – with an interface identifier being a well defined concept in RFC4291 – it specifies the actions taken on said interface identifier – it does not alter the specification.
Here – you have gone way beyond that. This actually eliminates the interface identifier from the address and replaces the interface identifier with something that has no bearing on an interface – that is a redefinition of the specification. Andrew From: Robert Raszuk <rob...@raszuk.net> Sent: Friday, 20 December 2019 18:58 To: Andrew Alston <andrew.als...@liquidtelecom.com> Cc: Alexandre Petrescu <alexandre.petre...@gmail.com>; Gyan Mishra <hayabusa...@gmail.com>; SPRING WG <spring@ietf.org>; Mark Smith <markzzzsm...@gmail.com>; Pablo Camarillo (pcamaril) <pcama...@cisco.com> Subject: Re: [spring] 64-bit locators Therefore – this redefines the address semantics – and that – should be accompanied by an update to said drafts to avoid confusion and to avoid potential future complications Please observe that we have a lot of IETF documents putting various stuff into IPv6 128 bits. Take rfc7599 as an easy example. Where do you see anyone in IETF requested to update IPv6 base specs when any of such documents were going via standards track ? Cheers, R.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
