Re: [bmwg] Murray Kucherawy's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

[John C Klensin <[e-mail]>]

Barry, 

While I don't think our position are far apart, I'm not sure I
agree, partially because of the concern I (and Stewart) tried to
express earlier about perfectd foresight and enumerating all
possible cases.   Now, if every statement of the sort you
suggest came with an additional clause equivalent to "unless you
run into a case that we didn't anticipate at all", it would end
up fairly close to what I suggested.   More generally, I think
the IETF and its predecessors have always -- both before and
after we started using the term "standard" regularly -- been a
bit ambivalent and conflicted about clear conformance
statements.  Some of that ambivalence, IMO, comes from the
differences between trying to write specs for implementers who
want to work together in good faith to produce interoperable
implementations, using those specs for guidance versus writing
specs for regulators and contract-enforcers who are concerned
about specifications that can identify implementations that try
to cut corners or offer variations to gain, e.g., competitive
advantage.  

I remember some discussions very early on, long before OSI
turned into a poster child for the other point of view, about
how it was better to reach agreements on a design or protocol,
document it mostly for the reference of those who agreed and
those who might follow in their footsteps, and then move on
rather than spending weeks, months, or longer trying to pin down
every possible detail.  I vaguely even remember a Padlipsky rant
or two on the subject.  To some extent, the Robustness Principle
came out of that thinking too: we might more precisely restate
at least part of the intent today, in far more words, as "if you
are not very confident you know what the spec intended and that
others will read it the same way you do, then be conservative in
what you send..."

So, I think that, unless we have reached the stage where we want
and expect our specifications to cover every detail and be exact
about it, SHOULD serves real value... but only if we require
explanations of why it is present rather than using it as "MUST,
but maybe not" or "MUST unless you don't feel like it".

best,
  john


--On Friday, February 11, 2022 11:34 -0500 Barry Leiba
<[e-mail]> wrote:

> I agree with what Scott, Michael, and John have said, and
> agree with Scott that we should not have "SHOULD", but it's
> too late to change that.  The sense that "SHOULD" is really
> there for would be adequately covered by "MUST" with an
> explicit escape clause documented: "You MUST do this unless
> <escape explicitly specified>."
> 
> For example, "You MUST include the exact length value unless
> computing it is so time-consuming that it would be likely to
> exceed client timeout periods."  (In contrast to "You MUST
> include the exact length value even if it is time-consuming to
> compute."  And even better, "You MUST include the exact length
> value unless computing it is so time-consuming that it would
> be likely to exceed client timeout periods.  Clients rely on
> the length value <for purpose>, and inaccurate length values
> can cause <these types of problems>."
> 
> Our specs would be much better if we made every effort to
> specify SHOULD conditions that way instead.