Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

[Ron Bonica <[e-mail]>]

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 <[e-mail]> 
Sent: Thursday, September 5, 2019 4:19 AM
To: Ron Bonica <[e-mail]>
Cc: Fernando Gont <[e-mail]>; Suresh Krishnan <[e-mail]>; [e-mail]; [e-mail]; draft-voyer-6man-extension-header-insertion <[e-mail]>; draft-ietf-spring-srv6-network-programming <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
> Sent: Wednesday, September 4, 2019 2:58 AM
> To: Fernando Gont <[e-mail]>
> Cc: Suresh Krishnan <[e-mail]>; Ron Bonica 
> <[e-mail]>; [e-mail]; [e-mail]; 
> draft-voyer-6man-extension-header-insertion 
> <[e-mail]>; 
> draft-ietf-spring-srv6-network-programming 
> <[e-mail]>
> Subject: Re: Question about SRv6 Insert function
> 
> [ snip ]
> I would prefer that we calmed down a bit on the protocol policing.
> 
> [ snip ]