Brian, Is there any limit to the degree that one Internet Standard can violate another, so long as that violation is constrained to a limited domain?
For example, if I wanted to reduce the size of IPv6 header by shrinking the source and destination addresses to 64 bits each, would that be OK? Ron Juniper Business Use Only -----Original Message----- From: Brian E Carpenter <brian.e.carpen...@gmail.com> Sent: Monday, October 4, 2021 4:05 PM To: Tony Przygienda <tonysi...@gmail.com> Cc: Ron Bonica <rbon...@juniper.net>; 6...@ietf.org; SPRING WG <spring@ietf.org> Subject: Re: draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] Tony, On 05-Oct-21 02:32, Tony Przygienda wrote: > Taking this new "philosophy of limited domain" to its bitter > conclusion > > A is Internet Standard > B is also Internet Standard for "Limited Domain" that violates A C is > also Internet Standard for "Limited Domain" that violates A D is also > Internet Standard for "Limited Domain" that violetes C > > so by transitive chain D violates C and hence A but not B. Hence D and B can > be deployed together (maybe) but not any other combination. > > So what purposes will IETF serve. To define 4 different "standards" that have > "limited domain violation dependencies" amongst each other but based on > algebra closure can sometimes be deployed together. And we will track this > and call that "standards" ? Really ? There's an attempted analysis of this issue at https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8799.html*name-the-scope-of-protocols-in-l__;Iw!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG7y06gGZe$ (which is not, of course, an IETF document). Brian > > --- tony > > > > > > On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter <brian.e.carpen...@gmail.com > <mailto:brian.e.carpen...@gmail.com>> wrote: > > Ron, > > The first sentence cites RFC8402 which unambiguously describes SR as a > limited domain protcol (limited to an "SR domain", that is.) > > So within such a domain, this describes using 128 bit quantities called > Segment Identifiers that in some cases, but apparently not in the formats > defined here, has the same structure as an IP address. > > Does that harm the Internet, even if it leaks? It might disappoint the > sender, as any sender of a bogus packet is disappointed, but apart from > that, > who is damaged? > > Regards > Brian Carpenter > > On 02-Oct-21 09:34, Ron Bonica wrote: > > Folks, > > > > > > > > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new > SID types that can occupy the Destination Address field of an IPv6 > header. See Sections 4.1, 4.2, and 4.3 of the draft for details. > > > > > > > > The SPRING WG has issued a call for adoption for this draft. > > > > > > > > It is not clear that these SID types can be harmonized with the IPv6 > addressing architecture. > > > > > > > > Does anyone have an opinion? > > > > > > > > > Ron > > > > > > > > > > Juniper Business Use Only > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org <mailto:i...@ietf.org> > > Administrative Requests: > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$ > > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$ > > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6 > __;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3f > aGG74XUosUG$ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$ > > > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring