Ole,
The IETF does not write de jure standards. At the same time, it must not
blithely progress proposals that ignore existing standards. We need to find a
balance.
Generally speaking, proposals that conform to the spirit and letter of existing
standards are better than proposals that deviate. This is a matter of hygiene.
However, exemptions might be granted.
IMHO, a WG can progress a proposal that deviates from existing standards if all
of the following conditions are met:
1) The proposal documents the deviation
2) The proposal explores alternative solutions that do not deviate
3) The proposal explains either a) that alternative solutions do not exist, or
b) why alternative solutions are not viable
4) The proposal describes the possibly limited deployment environment in which
it is applicable
5) The WG cannot demonstrate any risk associated the deviation in the described
deployment environment
A naïve reading of your message, below, suggests that we fixate on Condition
#5, ignoring conditions #1 - #4. I'm pretty sure that wasn't your intent. If it
were, our new process lead us into some bad places.
Like you, I want to avoid legalistic readings of existing standards. This is
why I talk about the "spirit and letter" of a standard. For example, assume the
following:
- An existing standard defines a mechanism for doing something
- A new proposal reinvents that wheel without sufficient motivation
The new proposal does not violate the letter of the existing standard, but it
does violate its spirit.
Clearly, the barriers to progressing a draft that violates the letter of an
existing standard should be higher than the barriers to progressing a draft
that violates the spirit of an existing standard.
Ron
Juniper Business Use Only
-----Original Message-----
From: Ole Troan <otr...@employees.org>
Sent: Thursday, September 5, 2019 4:19 AM
To: Ron Bonica <rbon...@juniper.net>
Cc: Fernando Gont <ferna...@gont.com.ar>; Suresh Krishnan
<suresh.krish...@gmail.com>; spring@ietf.org; 6...@ietf.org;
draft-voyer-6man-extension-header-insertion
<draft-voyer-6man-extension-header-insert...@ietf.org>;
draft-ietf-spring-srv6-network-programming
<draft-ietf-spring-srv6-network-programm...@ietf.org>
Subject: Re: Spirit and Letter of the Law (was: Question about SRv6 Insert
function)
Dear Ron,
The IETF is not writing de jure standards.
In fact reality is quite different, and the Internet evolves the way it does
somewhat independently of what documents the IETF produces.
In fact I know of no networking products (or deployments) that follow the
intent and spirit of RFC8200. I challenge to point me to one! ;-)
Let me quote Tony Li's response to Fernando's escalation email to the
architecture list:
"The fact of the matter is that the IETF is completely helpless to prevent such
things.
True, it can block standardization, but if the market wants it, the market will
drive it and all that the IETF does is to make itself irrelevant to the
process."
My suggestion to Fernando was to argue the issues on technical merit.
Can you please explain why you don't do that?
- Does it break end to end transparency?
- Can end host protect their traffic with encryption or do the proposed
mechanisms break that?
- How is PMTUD, ICMP errors, AH being handled?
- Does it break intereroperability?
Best regards,
Ole
> On 4 Sep 2019, at 20:27, Ron Bonica <rbon...@juniper.net> wrote:
>
> Ole,
>
> Yes, a deep breath and some introspection are always a good thing.
>
> First, I think that we need to make a distinction between the "spirit" and
> "letter" of the law. Next, we need to make a statement regarding good
> engineering practice.
>
> RFC 8200 mandates some things. For example, In an IPv6 header, the source
> address must precede the destination address. Any attempt to reverse those
> two would violate the letter of the law.
>
> By contrast, RFC 8200 strongly suggests other things. For example, transit
> nodes should not insert or delete extension headers. In general, these
> suggestions should be heeded. But exemptions can be granted, on a
> case-by-case basis, given that the motivation is strong, the risk is minimal,
> and there are no viable alternatives.
>
> For better or worse, RFC 8200 does not use RFC 2119 language. So it is
> difficult to distinguish between the spirit and letter of the law. I think
> that is the genesis of the current debate.
>
> Beyond that, we need to make a statement regarding good engineering practice.
> If a technology violates the spirit of RFC 8200 once, with good reason, that
> is fine. If it violates the spirit of RFC 8200 twice, we should all start
> asking questions. If it violates the spirit of RFC 8200 three times, and
> promises to do so again in the future, we should start to question whether
> that technology is building on RFC 8200 or trying to redefine it.
>
>
> Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Ole Troan <otr...@employees.org>
> Sent: Wednesday, September 4, 2019 2:58 AM
> To: Fernando Gont <ferna...@gont.com.ar>
> Cc: Suresh Krishnan <suresh.krish...@gmail.com>; Ron Bonica
> <rbon...@juniper.net>; spring@ietf.org; 6...@ietf.org;
> draft-voyer-6man-extension-header-insertion
> <draft-voyer-6man-extension-header-insert...@ietf.org>;
> draft-ietf-spring-srv6-network-programming
> <draft-ietf-spring-srv6-network-programm...@ietf.org>
> Subject: Re: Question about SRv6 Insert function
>
> [ snip ]
> I would prefer that we calmed down a bit on the protocol policing.
>
> [ snip ]
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
