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: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
