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

[Fernando Gont <[e-mail]>]

On 6/9/19 06:26, Ron Bonica wrote:
> 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.

That is *exactly* the point I've been trying to make.




> 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. 

In this case, EH-insertion violates both the letter and the spirit of
the standard. And the proposal never even commented why encap/decap is
not a feasible solution, instead of EH-insertion. (the most basic
content of your item #2 above).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492