Re: 2119bis

John C Klensin wrote:
> --On Wednesday, August 31, 2011 23:10 -0400 Sam Hartman
> > Hmm.  Most of the times I use SHOULD I'd expect them to stay
> > SHOULD. SHOULD doesn't mean "this feature is desired," it
> > means "do this unless you have justification for doing
> > something else." There are a few cases (new algorithms) where
> > you mean SHOULD+ (we'll move to MUST in the future) but often
> > you mean do this unless you're in a constrained environment,
> > or you know you won't need it or something like that. In those
> > cases, SHOULDS tend to stay SHOULDS.
> +1
>
> Exactly right.   Indeed, if I agreed with Eric's view, I'd think
> we should abolish SHOULD and SHOULD NOT (almost) entirely,
> replacing them with temporary qualifications for MUST that would
> convey "not quite sure about this yet, but MUST is certainly our
> intention".  "Tentative"  or "Provisional", with appropriate
> IETF-specific definitions, would be two such words.
I like those terms, Tentative, Provisional, perhaps also Exploratory, 
Experimental.
But consider, if SHOULD [NOT] was to be abolished, wouldn't MUST [NOT] 
now be redundant and implied in functional and technical semantics?
It seems it will reduce to usages of key words such as: IMPLEMENT, 
USE, NEGOTIATE, IFF, DON'T, CAPABLE, DEPEND and perhaps PLEASE and 
their negatives.
   PLEASE IMPLEMENT X, Y, Z. PLEASE NEGOTIATE for X first and PLEASE
   USE Y IFF peer implementators are not CAPABLE of Z.

      IMPLEMENTATION NOTE:  PLEASE DON'T DEPEND on X, Y, or Z if
      peer implementation are not capable of X, Y or Z.

Jokes to the side, IMO, I don't see how it would be possible to impose 
things on implementators deciding on items that are not necessary, 
overdone, "candy" and perhaps Pareto's principle comes into play - It 
works 100% of the time for the minimum required which represents 80% 
of the total capabilities.
The situation here appears to be features in the remaining 20% now 
become more necessary overtime and in hindsight, we see there are a 
lot "Oops" that didn't make those things part of the minimum 
requirements.
Will any future rewording of "compliance" docs change this or make it 
better?  I don't seem to think so because as we all know, perfection 
is not possible - we need to have those knobs and switches.  Making 
everything a MUST [NOT] or wording things to steer people to 100% 
implementation will most like raise the adoption barrier and  and we 
end up relaxing things anyway just to get people to consider an RFC.
My opinion.

--
HLS
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf