Re: 2119bis

Keith Moore wrote:
> On Aug 31, 2011, at 8:30 AM, Hector wrote:
>
> > In my view, SHOULD are user protocol options to set.  
> In my view, SHOULD should rarely be used for optional protocol features, 
> because optional protocol features should themselves be rare.  And the primary 
> purpose of SHOULD is not to permit optional protocol features.
If SHOULD is read as a MUST IMPLEMENT, and that also implies MUST USE 
with no provision to disable then its should of been a MUST in the 
first place.
When presented to consumers, we do this for the most part:

o MUST items

No options, to way to turn off. No GUI, Nada.  Under rare 
circumstances, usually due to protocol conflicts, i.e. a MUST really 
should of been a SHOULD and it might have been a SHOULD in protocol 
STD, but made into a MUST in protocol RFC update and that now causes 
problems, hence undocumented switches are provided for support.
o SHOULD items

Here we have three forms of the options:

   [X] Extended Feature A    -  higher sweet benefit! default ON
   [_] Extended Feature B    -  Nice, but high overhead, default OFF
   [_] Extended Feature C    -  It was default ON, but operator said 
NAHHHHH!
MAY options are similar but heres you have learn more about the 
consumer needs to decide what protocol overhead is added and/or 
initial ON/OFF position.
Many Implementators makes decides on the basic of this SHOULD value 
offers. Its a big waste of them, it won't be implemented.  But when 
its get more adoption, maybe.  And we can't impose Bloat Ware options 
that prove to be bad or not desired, so you have to present these 
SHOULDS as options.
I sense a bad direction with what is basically "ALL or Nothing" 
protocol implementation, including with there little adoption, complex 
to support and simply not required. This might be enough to raise the 
barrier on adoption for some protocols that insist on on a "All or 
Nothing" conformance mandate.
Why even bother with SHOULD, and use have MUST and MAY?

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