ietf
[Top] [All Lists]

Re: 2119bis

2011-08-30 11:06:59
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/30/2011 08:44 AM, Keith Moore wrote:

On Aug 30, 2011, at 11:38 AM, Marc Petit-Huguenin wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 08/30/2011 07:58 AM, Keith Moore wrote:
On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 08/30/2011 07:35 AM, Keith Moore wrote:
On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 08/30/2011 06:54 AM, Keith Moore wrote:
I think you're overgeneralizing.  My experience is that judicious
use of SHOULD seems to make both protocols and protocol
specifications simpler; trying to nail everything down makes them
more complex.

But using SHOULD does not make the implementation less complex, it
simply decreases the complexity for the *author* and increases the
probability that two independent implementations will have
interoperability problems.

To the extent that SHOULD is causing interoperability problems, it
may be that some authors are misusing SHOULD.  But it's not an
inherent problem with SHOULD.

As an implementer, I would ban all SHOULD/SHOULD
NOT/RECOMMENDED/NOT RECOMMENDED.

I'm an implementor also, and I've found SHOULD to be very helpful.

Yes, it is very helpful in convincing one's PHB that one does not have
to implement something, or in convincing another company to reactivate
a feature during interop tests because one did not bother to implement
it.


Rather than vaguely attacking SHOULD, maybe it would be more illuminating
to cite specific examples?

It is difficult because of a mix of NDAs, employment confidentiality
agreements and desire to not single out individuals.  I'll send you an
example in a private email.

I look forward to seeing it.

But in general I get the impression that people are attacking SHOULD because
of specific problems rather than general problems.  Since I find SHOULD very
useful, to me it makes more sense to try to outline cases where SHOULD is
problematic, and provide advice for those cases, than to try to get rid of it
or change what it means.

The meaning of SHOULD is clear for the authors (it "mean[s] that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course."), the problem is that some implementers use a different
meaning (I do not have to implement this if it is inconvenient or difficult for
me to implement), vendors another one (SHOULD gave us the right to not implement
it).  I even read somewhere, perhaps on this list, about a vendor that rejected
any bug report against a SHOULD.  Conditional MUST, in my opinion, does not have
this problem.


e.g. For the specific case of optional features that must be negotiated, I
don't think that SHOULD is the problem.  Rather I think that optional
features are too common.  That's not to say that optional features and
feature negotiation are never useful, particularly when extending a protocol
that is already well-established in the field.  But if making features
optional is seen by WGs as a way to avoid making hard decisions about what is
required to interoperate, that really is a problem.  It just doesn't have
anything to do with SHOULD.

- -- 
Marc Petit-Huguenin
Personal email: marc(_at_)petit-huguenin(_dot_)org
Professional email: petithug(_at_)acm(_dot_)org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5dCosACgkQ9RoMZyVa61e8iwCfZccbWf20L0VaDtBFH6ekmhm5
l30AoJmTDscY/dAGwjfU3toAnydGZHft
=pbTY
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>