subject:"RE\: 2119bis"

Yes, but there is another factor that appears to be presumed in the 
discussions that might will help explains the critical difference:


Even if SHOULD is interpreted as a MUST IMPLEMENT,
there is no MUST USE guarantee by protocol consumers.

An implementator might decide a particular SHOULD has an absolute no 
consumer value, it might even be harmful, and it might be a low 
adoption currently, that might be enough to ignore it.


On the hand, if he says Oh, lets add it anyway, he must still 
present it as OPTION to the consumer for them to decide.


In my view, SHOULD are user protocol options to set.  Odds are good a 
SHOULD would be enabled out of the box.  Some might be disabled out of 
the box.   If its not an user option, then that means it must be 
enabled with no way to turn off.  If so, then logic tells me that this 
SHOULD should of been a MUST to be begin right. No?


--
HLS


Eric Burger wrote:

My interpretation of what you wrote is that in your mind there is absolutely no 
difference between a SHOULD and a MAY.  They are both optional, and you 
implement whatever you have time to implement, with SHOULD's prioritized higher 
than MAY's.

Even if that is not what you mean, it is what many implementors do.

I would offer this highlights the problem with today's SHOULD.  Some think 
SHOULD means something is OK to implement, but life does not end if you do not 
do it. Others think SHOULD means something HAS to be implemented, unless the 
environment indicates the protocol will not work in some corner case.


On Aug 30, 2011, at 3:08 PM, hector wrote:


When I approach a protocol to implement, the first thing I typically do is extract and 
develop the basic wiring of the protocol, the minimum requirements.  Make sure the basic 
framework is correct 100%, then I look for the SHOULDs and also MAYS which are the 
easiest to add.  I look at the SHOULD by order of importance and also complexity.  How 
much CANDY is it?  It is a security feature?  What are the other 
implementation requirements, tools, APIs, etc.  Generally I want to get security out the 
way.  Its like SMTP AUTH - its not required but anyone cleaning up and rewriting an SMTP 
spec today, might include the AUTH extension as a SHOULD. And implementators are keen to 
the importance of it.  But nothing won't break down if you don't, less functionality but 
the basic structure is still there.

Its the same approach used for all the protocols we support. Start with the 
basics and then add on  as necessary.

Eric Burger wrote:

What is the difference in this case between SHOULD or MAY?
On Aug 30, 2011, at 2:49 PM, Adam Roach wrote:

On 8/29/11 9:44 PM, Eric Burger wrote:

Yes, and...

I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X 
*are* what people usually mean when they say SHOULD.  In the spirit of Say What 
You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the 
author to turn the statement into the if Y then MUST X or if Z then MUST NOT X 
form.  Being pedantic and pedagogic:
SHOULD send a 1 UNLESS you receive a 0
really means
UNLESS you receive a 0, one MUST send a 1.

My vision of the UNLESS clause is not necessarily a protocol state, but an 
environment state.  These are things that I can see fit the SHOULD/UNLESS form:
SHOULD send a 1 UNLESS you are in a walled garden
SHOULD flip bit 27 UNLESS you have a disk
SHOULD NOT explode UNLESS you are a bomb
are all reasonable SHOULD-level statements.

I would offer that ANY construction of SHOULD without an UNLESS is a MAY.

Eric. Put down the axe and step away from the whetstone. Here, I'll give you 
some text from RFC 3265 to mull.


 deactivated: The subscription has been terminated, but the subscriber
SHOULD retry immediately with a new subscription.  One primary use
of such a status code is to allow migration of subscriptions
between nodes.


Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is 
it an interop issue? No.

Is it in the interest of the implementation to re-subscribe? Yes. At least, 
under most circumstances. Otherwise, they won't get the state change 
notifications they want.

Are there cases in which it makes sense for the subscriber _not_ to 
re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens 
to be shutting down but hasn't gotten around to terminating this particular 
subscription yet. But any such exceptions are highly implementation-dependent. 
Listing them would be useless noise to the reader, and senseless text creation 
for the author.

Does SHOULD get abused by some authors in some documents? Of course it does. 
But your crusade to throw out a useful tool just because it has been misused on occasion 
is an extreme over-reaction. I like this tool. I use this tool. If you see people 
misusing it, slap them.

But don't ban the tool.

/a

Re: 2119bis

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.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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 
NAH!


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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


On Aug 31, 2011, at 9:12 AM, Hector wrote:

 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.

Just because a feature is optional does not mean that it's a protocol 
feature... i.e. it doesn't mean that it affects how the implementation 
interacts with peers.  

SHOULD is IMO most often useful not when specifying how a protocol acts on the 
wire, but when specifying how a protocol needs to be implemented on a 
particular platform, where the precise semantics, API details, etc. naturally 
differ from one platform to another.

 Why even bother with SHOULD, and use have MUST and MAY?

To get people out of the rathole of trying to specify exactly how everything 
must work in excruciating detail, in a world where there is inherently going to 
be some necessary variation.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Scott O. Bradner

I've been traveling so have not had a chance to do anything but watch
the discussion on a RFC 2119 update.

a few thoughts

1/ I am far from convinced that there is a need to update RFC 2119
  there is a bug in the boilerplate (as has been mentioned) 
  and some people seem to have a hard time understanding what 
  (to me) seem like clear descriptions of (for example) MUST  
  SHOULD - but the issues do not seem serious enough to warrant
  replacing what is, basically, a simple dictionary  usage 
  constraint

2/ it seems like a very Bad Idea to move 2119 to historic- we move
 RFCs to historic when no one uses them or when they are a Bad
 Idea in light of updated technology - I do not think that makes 
 much sense in this case - in addition it makes the status of RFCs
 that have a normative reference to a historic document a bit
 funky - if an update is actually needed there is no reason that
 I can come up with that it could not just be that -- an update

3/ I doubt that I'll ever catch up with Postel as the most referenced
 RFC author so that is not a consideration (for me)

I wrote RFC 2119 (most using text from RFC 1122) because people were
using MUST without saying what they meant, an update, if people think
that one is actually needed, will serve that purpose as well as 2119 has.  

When I posted the original ID it was pointed out that I should also
address when such terms should be used (i.e. try to limit the use to
where it actually made sense protocol-wise) - I tried to do that but
that part may not have been as successful as it might have been - any
update might try to be clearer in this area that RFC 2119 is.

Scott


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread hector


Keith Moore wrote:

On Aug 31, 2011, at 9:12 AM, Hector wrote:

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.


Just because a feature is optional does not mean that it's a 
protocol feature... i.e. it doesn't mean that it affects how the 
implementation interacts with peers.  


Thats the problem with trying generalize SHOULD as single 
interpretation for all SHOULDs when it is so highly subjective many times.


I think you are speaking of long term operations where an SHOULD is so 
widely adopted, it inherently because a MUST have in all new 
implementations.  So that vain, sure, eventually the better options 
naturally become part of the protocol to the extent the options might 
be even remove to simplify things.  We also have the opposite where a 
SHOULD is implemented but no one users it so eventually, it may be 
remove as an option.


SHOULD is IMO most often useful not when specifying how a protocol 
acts on the wire, but when specifying how a protocol needs to be 
implemented on a particular platform, where the precise semantics, 
API details, etc. naturally differ from one platform to another.


Yeah, but its also very very useful to offering what parts of a 
protocol are on and off and let operators decide what they want. 
Don't we already do this?





Why even bother with SHOULD, and just use MUST and MAY?


To get people out of the rathole of trying to specify exactly how 
everything must work in excruciating detail, in a world where there is 
inherently going to be some necessary variation.


I agree, it is the easy way out.  But wouldn't it still be a rathole 
if SHOULD was still a MUST-IMPLEMENT concept which is why a MUST made 
it an rathole in the first place?  Too many people didn't like, not 
want it nor wish to waste time on a unproven concept. So you make it a 
SHOULD or a MAY.


With a MUST-IMPLEMENT view of SHOULD, then SHOULD really isn't 
compromise if you have to implement and even more so if no one is 
allowed to turn it off.


-1 on RFC2119bis :)


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric 
 Burger
 Sent: Wednesday, August 31, 2011 12:37 AM
 To: hector
 Cc: IETF discussion list
 Subject: Re: 2119bis

 I would offer this highlights the problem with today's SHOULD.  Some
 think SHOULD means something is OK to implement, but life does not end
 if you do not do it. Others think SHOULD means something HAS to be
 implemented, unless the environment indicates the protocol will not
 work in some corner case.

On the other hand, given the current SHOULD definition in RFC2119, I'm at a 
loss to understand how one could reasonably come to other than the second 
interpretation you give here.  It's fairly explicit to me.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

On Aug 31, 2011, at 10:03 AM, Murray S. Kucherawy wrote:

 On the other hand, given the current SHOULD definition in RFC2119, I'm at a 
 loss to understand how one could reasonably come to other than the second 
 interpretation you give here.  It's fairly explicit to me.

The simplest explanation is that people don't bother to read 2119.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

On Aug 31, 2011, at 9:57 AM, hector wrote:

 SHOULD is IMO most often useful not when specifying how a protocol acts on 
 the wire, but when specifying how a protocol needs to be implemented on a 
 particular platform, where the precise semantics, API details, etc. 
 naturally differ from one platform to another.
 
 Yeah, but its also very very useful to offering what parts of a protocol are 
 on and off and let operators decide what they want. Don't we already do this?

yes, it is done to some degree.  but that's not, in general, a desirable 
practice. (though there are cases where it can be justified).

Keith


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Jari Arkko




Unless of course one considers us the Protocol Nanny's(tm) - if do not do a 
SHOULD, we will send you to bed without your treacle! I.e., there IS NO 
DISTINCTION BETWEEN A BARE SHOULD AND A MAY.



Of course there is. Its the distinction between -

Qualified SHOULD) Here lie dragons. Take the recommended route, unless you know 
how to fight them.

Unqualified SHOULD) Here lie some dangers. Check with someone who knows, or 
take the recommended route.

MAY) Here's an area. You could go there.

Of course, the first and last pieces of text are preferred. But sometimes no 
one was brave enough to explore the area, so we don't actually know what 
dangers there are, they cannot be listed.

Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Jari Arkko


Keith, Peter,


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.


I agree.

In any case, Peter, I think its fine to add the NOT RECOMMENDED word to the 
boilerplate. Publish a spec on that, have it Update 2119, and then new RFCs 
would refer to that (say, 7119) instead of 2119 and everyone would be happy.

But I'm not quite sure why there are other changes in the text. Maybe I need to 
be educated better. On quick read I got more questions from it than what I get 
from 2119...

Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Peter Saint-Andre

On 8/31/11 9:48 AM, Jari Arkko wrote:
 Keith, Peter,
 
 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.
 
 I agree.
 
 In any case, Peter, I think its fine to add the NOT RECOMMENDED word to
 the boilerplate. Publish a spec on that, have it Update 2119, and then
 new RFCs would refer to that (say, 7119) instead of 2119 

Yes, that is one path.

 and everyone
 would be happy.

I'm not sure that everyone would be happy, because I do think that some
clarifications and additional guidelines might be helpful. But those,
too, could go in a separate (likely Informational) document that would
not necessarily update (and certainly not obsolete) 2119.

 But I'm not quite sure why there are other changes in the text. Maybe I
 need to be educated better. On quick read I got more questions from it
 than what I get from 2119...

Thus the desirability of writing a separate document.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Peter Saint-Andre

On 8/31/11 9:52 AM, Keith Moore wrote:
 or maybe just file an erratum.

There is an erratum on file:

http://www.rfc-editor.org/errata_search.php?eid=499

I started down this road in part while working to clear out errata...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


Keith Moore wrote:

On Aug 31, 2011, at 9:57 AM, hector wrote:


Yeah, but its also very very useful to offering what parts of a protocol are 
on and off and let operators decide what they want. Don't we already do this?


yes, it is done to some degree.  


Every protocol I have implemented such as PPP, RADIUS, SMTP, TELNET, 
FTP, POP3 among the augmented protocols all have some levels of 
Features presented as SHOULDs and MAYs and those seem necessary 
where exposed in some form of configuration options. They might be 
tweaked for optimal out of the box performance, so you might not need 
them.  Just look at SMTP extensions, EHLO features.  There are SHOULD 
for 5 mins timeouts and 5321 states that its good idea to make this 
configurable.  Came in handy the other day! :) or even DKIM. Protocol 
options made available, but fined tune so the operators just can start 
using it.  But not all will use the setting you prepare for them.


but that's not, in general, a desirable practice. (though there are 
cases where it can be justified).


While I agree long time engineering  fine tuning, options become 
stable, deprecated or obsolete and  short of an finely tuned embedded 
system, turnkey system, even smart phone/devices, and not really even 
then, I hardly seen any protocol with options not implement with some 
level of exposure deemed necessary.



The simplest explanation is that people don't bother to read 2119.


How can you make a claim like this with a straight face or I guess 
fingers? That invites useless conflicts like get a dictionary for 
the word Recommended,  or just plain old accepting the simple idea 
that after determining all full implications above and beyond what was 
necessary is a valid reason to IGNORE the recommendation.


--
HLS

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

or maybe just file an erratum.  I think it's fairly obvious that any document 
that actually uses NOT RECOMMENDED should define what it means, if it expects 
those words to have any meaning other than the ordinary English meaning of 
those words (with or without capitalization).  

I've seen documents that didn't quote the 2119 boilerplate verbatim because 
they didn't use all of the terms defined in 2119.   I didn't see any problem 
with that.

On Aug 31, 2011, at 11:48 AM, Jari Arkko wrote:

 In any case, Peter, I think its fine to add the NOT RECOMMENDED word to the 
 boilerplate. Publish a spec on that, have it Update 2119, and then new RFCs 
 would refer to that (say, 7119) instead of 2119 and everyone would be happy.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


On Aug 31, 2011, at 11:55 AM, Hector wrote:

 Keith Moore wrote:
 On Aug 31, 2011, at 9:57 AM, hector wrote:
 
 Yeah, but its also very very useful to offering what parts of a protocol 
 are on and off and let operators decide what they want. Don't we already do 
 this?
 
 yes, it is done to some degree.  
 
 Every protocol I have implemented such as PPP, RADIUS, SMTP, TELNET, FTP, 
 POP3 among the augmented protocols all have some levels of Features 
 presented as SHOULDs and MAYs and those seem necessary where exposed in some 
 form of configuration options. They might be tweaked for optimal out of the 
 box performance, so you might not need them.  Just look at SMTP extensions, 
 EHLO features.  There are SHOULD for 5 mins timeouts and 5321 states that its 
 good idea to make this configurable.  Came in handy the other day! :) or even 
 DKIM. Protocol options made available, but fined tune so the operators just 
 can start using it.  But not all will use the setting you prepare for them.

Old protocols that were extended after they were widely deployed are one of the 
exceptional cases where SHOULD / SHOULD NOT / etc. make sense to describe 
protocol features.   They can't always be MUSTs or MUST NOTs because of the 
need to maintain backward compatibility with old implementations.

Things like timeout intervals are often labeled as SHOULDs because they aren't 
precisely determined, they're educated guesses.  So implementors and perhaps 
operators should have some leeway to tweak them in light of experience.

 The simplest explanation is that people don't bother to read 2119.
 
 How can you make a claim like this with a straight face or I guess fingers?

Because of long experience that indicates that implementors often fail to read 
base specifications thoroughly, much less the referenced specifications.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis - SHOULD Classifications

2011-08-31 Thread Hector Santos


Barry Leiba wrote:

Just responding to a small part, here:


� B) RFC2119 states SHOULD is the same as the adjective RECOMMENDED.

As far I am concern, a recommendation is not a mandate nor obligation.


..

But don't make the mistake of thinking that, in the context of RFC
2119, one can use one's own English sense of what the meanings of
these terms are.


Agree, that is why the final part of my email I suggested the 
consideration to remove the last sentence of the text be removed;  The 
term RECOMMENDED is equivalent to SHOULD.


Personally, it benefit us if we state SHOULD under different 
classifications. I'm just winging it, but perhaps:


 NEW ITEM
 IMPROVEMENT
 SECURITY (VERY IMPORTANT)

A context of which the SHOULD offers has a lot of weight in the 
decision making process.


Example:

 If the SHOULD is related to security,
 then all efforts MUST be to made to support it.

 If the SHOULD item is an improvement not related to security,
 then all efforts SHOULD be to made to support it.

 If the SHOULD item is a new item not related to security,
 then all efforts MAY be to made to support it.

Of course, there is the interesting nature of recursion here and the 
last two can possibly be folded, but I think stating SHOULD compliance 
classified under new, improvement and the level of importance context 
will help rather than trying to state it as a generalize, ambiguous 
rule of thumb - A MUST BUT OPTIONAL IFF YOU KNOW WHAT YOU ARE DOING.


The basic idea is that when is something is NEW there is lesser 
obligation to support it until its becomes widely adopted. If its 
really an important feature, like security, then it ought to be stated 
with a heavy obligatory emphasis.


Also, we may consider other general guidelines text like:

New protocol enhancements with SHOULD key words MUST NOT be used 
a non-compliance
measurement tool of existing compliant implementations. i.e. 
current implementator

are not broken because they are not currently supporting a SHOULD.

A new protocol that has a OPTIONAL dependency on an existing 
optional protocol
MUST NOT use MUST|SHOULD as an enforcement tool for make 
implementator to

support the optional protocol.

The last one I had trouble writing it, but I think you get the gist of it.

Overall, I believe the system has worked - we got this far because 
we gave implementators the benefit of the doubt that valid reasons to 
ignore was done responsibly and the protocols still worked.


The problem, in my view, has been an agenda of enforcing protocol 
behavior from a Throw the book non-compliance mindset, worst when 
dealing with integrated of optional protocols, yet not equally 
applied. e.g., I don't wish to honor that other protocol SHOULD but 
you MUST follow my protocol SHOULD.


--
Sincerely

Hector Santos
http://www.santronics.com



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Michael Richardson


 Keith == Keith Moore mo...@network-heretics.com writes:
 In my view, SHOULD are user protocol options to set.

Keith In my view, SHOULD should rarely be used for optional
Keith protocol features, because optional protocol features should
Keith themselves be rare.  And the primary purpose of SHOULD is not
Keith to permit optional protocol features.

Let me give an example of where I think SHOULD is useful:
a TLS end-point SHOULD verify the received certificate against
a trusted anchor.

Removing this requirement in SMTP-TLS has meant that we now have
opportunistically encrypted email transmission.  It makes sense for the
TLS library to have this option.   

In a web browser, the same SHOULD is much more controversial.

Some TLS libraries have this as a MUST, and there is all sorts of
trouble for people implementing other protocols or authentication
mechanisms over TLS.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE
   then sign the petition. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Jari Arkko


I think we should update our RFCs when there's a generally accepted errata. I 
mean, I know about errata. I browse IETF docs through tools.ietf.org and they 
show me the errata links. But... shame on me... I don't click through those 
links often enough. I suspect I'd miss a few even if I was implementing 
something. Its far better if the entire document is up to date. I suspect this 
holds for other at least some other people, too.

Jari

On 31.08.2011 18:54, Peter Saint-Andre wrote:

On 8/31/11 9:52 AM, Keith Moore wrote:

or maybe just file an erratum.




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith 
 Moore
 Sent: Wednesday, August 31, 2011 9:03 AM
 To: Hector
 Cc: IETF discussion list
 Subject: Re: 2119bis

 Because of long experience that indicates that implementors often fail
 to read base specifications thoroughly, much less the referenced
 specifications.

I absolutely agree, and also with your earlier point that a lot of people 
apparently either don't bother to read RFC2119 at all, or (in my experience) 
read it selectively.

If there is an RFC2119bis, I would like to see it illustrate the cases where a 
MUST would be preferred over a SHOULD, and vice-versa, such that the 
implications to both the spec author and the reader are clarified.  It already 
seems to start down that road, which is fine.  But I don't think there's 
anything wrong with the definitions as we have them; I think they've served us 
well for the last fourteen years.

I don't agree at all with the interpretation of SHOULD as an optional protocol 
feature in all cases.  RFC2119 makes it clear what SHOULD and RECOMMENDED mean 
beyond the dictionary definition.  They are not an invitation to disregard 
those requirements merely because they are hard to implement or would confuse 
end users if exposed.  It seems clear to me that SHOULD is the same as MUST... 
UNLESS, and the unless part has to be carefully considered in terms of how 
interoperability will be affected, not how your source code or user interface 
will become more complicated.

It's certainly the case that there are some documents that got use of SHOULD 
wrong, but that doesn't mean RFC2119 is broken.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


Murray S. Kucherawy wrote:

-Original Message-


But I don't think there's anything wrong with the definitions as we have them; 
I think they've served us well for the last fourteen years.


Correct and by far, most deployments have use SHOULD = OPTION with an 
documented right to IGNORE - so be it written so be it followed.  The 
MUST-IMPLEMENT seems to be an exception and not the rule and even 
then is inconsistency in application seem to be very selective.


Maybe Tony's I-D can help reinforce this concept of a Recommendation:

   SHOULD, RECOMMENDED:  The words ought, encouraged and suggest
 strongly can be used to connote something that is strongly
 urged.

and I hope these terms still don't means MUST-IMPLEMENT and worst a 
MUST-USE by the operator.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector
 Sent: Wednesday, August 31, 2011 10:57 AM
 Cc: IETF discussion list
 Subject: Re: 2119bis

  But I don't think there's anything wrong with the definitions as we have 
  them;
  I think they've served us well for the last fourteen years.

 Correct and by far, most deployments have use SHOULD = OPTION with an
 documented right to IGNORE - so be it written so be it followed.

This sentence is self-contradictory.  SHOULD is, by definition, not 
OPTIONAL.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Randy Presuhn

Hi -

 From: Murray S. Kucherawy m...@cloudmark.com
 To: IETF discussion list ietf@ietf.org
 Sent: Wednesday, August 31, 2011 11:00 AM
 Subject: RE: 2119bis

  -Original Message-
  From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
  Hector
  Sent: Wednesday, August 31, 2011 10:57 AM
  Cc: IETF discussion list
  Subject: Re: 2119bis

   But I don't think there's anything wrong with the definitions as we have 
   them;
   I think they've served us well for the last fourteen years.

  Correct and by far, most deployments have use SHOULD = OPTION with an
  documented right to IGNORE - so be it written so be it followed.

 This sentence is self-contradictory.  SHOULD is, by definition, not 
 OPTIONAL.

I disagree with the claim that there is a contradiction there, but I also think
IGNORE is incorrect.

The only difference between SHOULD and MAY is that the implementor /
deployer needs a good excuse to not implement / employ a SHOULD.
That's not the same as IGNORE.

However, looking at an implementation from a conformance testing perspective,
these are indistinguishable.  If the conditions under which the feature may
be omitted are well-defined, then an if not x MUST y structure would be
much more appropriate, and this can be easily handled with the existing
keywords.

Randy

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy 
 Presuhn
 Sent: Wednesday, August 31, 2011 11:31 AM
 To: IETF discussion list
 Subject: Re: 2119bis

  This sentence is self-contradictory.  SHOULD is, by definition, not 
  OPTIONAL.

 I disagree with the claim that there is a contradiction there, but I also 
 think
 IGNORE is incorrect.

What was said is SHOULD = OPTION, but RFC2119 says OPTIONAL is the same as 
MAY.  That's the contradiction.

 The only difference between SHOULD and MAY is that the implementor /
 deployer needs a good excuse to not implement / employ a SHOULD.
 That's not the same as IGNORE.

But that's a big difference.  I think some people are being cavalier about the 
good excuse part, and that's where I have a problem.  RFC2119 is not unclear 
on this point.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


Murray S. Kucherawy wrote:


The only difference between SHOULD and MAY is that the implementor /
deployer needs a good excuse to not implement / employ a SHOULD.
That's not the same as IGNORE.


But that's a big difference.  I think some people are being cavalier 
about the good excuse part, and that's where I have a problem.  
RFC2119 is not unclear on this point.


Correct again, it is not unclear.  It says it very clear.  I don't 
know why you wish to ignore Tony's I-D reinforcing this concept and 
optional implementation:


   SHOULD, RECOMMENDED:  The words ought, encouraged and suggest
 strongly can be used to connote something that is strongly
 urged.

There is no possibility to interpret SHOULD as nothing else as an 
optional implementation and thus can be ignored. Of course, the 
presumptions are:


 - Faith in your engineering peers,
 - Due Diligence decision to decide to ignore it, and
 - understanding if it was implemented, it could be ignored by 
consumers.


If that is not enough, we have a huge deployment history where SHOULDs 
was ignored and implemented as an option for operators, and we have 
history where a SHOULD was changed to a MUST and it caused problems. 
If your interpretation was correct, this change would not have been 
necessary.


IMV, the evidence is quite clear that SHOULD has no MUST-IMPLEMENT 
concept and never had.  If people read it that way, it probably did 
not cause a problem. So no big deal.  But if they expected others to 
MUST-IMPLEMENT a SHOULD and broke down because of that expectation, 
then I suggest they didn't read RFC2119 correctly.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

2011-08-31 Thread Christer Holmberg

Hi,

Sometimes the drafts says that something SHOULD be done, but the justification 
is unclear to the reader, so it can be difficult to interpret the meaning 
correctly.

So, I think it would cause less confusion if drafts made a better job of 
describing WHY something is a SHOULD, or MUST.

Something like SHOULDBECAUSE :)

Regards,

Christer


From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Hector 
[sant9...@gmail.com]
Sent: Wednesday, August 31, 2011 10:07 PM
Cc: IETF discussion list
Subject: Re: 2119bis

Murray S. Kucherawy wrote:

 The only difference between SHOULD and MAY is that the implementor /
 deployer needs a good excuse to not implement / employ a SHOULD.
 That's not the same as IGNORE.

 But that's a big difference.  I think some people are being cavalier
 about the good excuse part, and that's where I have a problem.
 RFC2119 is not unclear on this point.

Correct again, it is not unclear.  It says it very clear.  I don't
know why you wish to ignore Tony's I-D reinforcing this concept and
optional implementation:

SHOULD, RECOMMENDED:  The words ought, encouraged and suggest
  strongly can be used to connote something that is strongly
  urged.

There is no possibility to interpret SHOULD as nothing else as an
optional implementation and thus can be ignored. Of course, the
presumptions are:

  - Faith in your engineering peers,
  - Due Diligence decision to decide to ignore it, and
  - understanding if it was implemented, it could be ignored by
consumers.

If that is not enough, we have a huge deployment history where SHOULDs
was ignored and implemented as an option for operators, and we have
history where a SHOULD was changed to a MUST and it caused problems.
If your interpretation was correct, this change would not have been
necessary.

IMV, the evidence is quite clear that SHOULD has no MUST-IMPLEMENT
concept and never had.  If people read it that way, it probably did
not cause a problem. So no big deal.  But if they expected others to
MUST-IMPLEMENT a SHOULD and broke down because of that expectation,
then I suggest they didn't read RFC2119 correctly.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


Randy Presuhn wrote:


Murray stated:
This sentence is self-contradictory.  SHOULD is, by definition, not 
OPTIONAL.


I disagree with the claim that there is a contradiction there, but I also think
IGNORE is incorrect.


That's a good point because if a good-faith decision was made to not 
implement a SHOULD, then there was no intent to ignore, there was no 
negligence and there is technical or protocol liability in that decision.


--
HLS
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


On Aug 31, 2011, at 3:07 PM, Hector wrote:

 Murray S. Kucherawy wrote:
 
 The only difference between SHOULD and MAY is that the implementor /
 deployer needs a good excuse to not implement / employ a SHOULD.
 That's not the same as IGNORE.
 But that's a big difference.  I think some people are being cavalier about 
 the good excuse part, and that's where I have a problem.  RFC2119 is not 
 unclear on this point.
 
 Correct again, it is not unclear.  It says it very clear.  I don't know why 
 you wish to ignore Tony's I-D reinforcing this concept and optional 
 implementation:
 
   SHOULD, RECOMMENDED:  The words ought, encouraged and suggest
 strongly can be used to connote something that is strongly
 urged.
 

When the text in 2119 is already clearly written, but people fail to read it, I 
don't understand why adding more text in yet another document is likely to 
improve understanding.   Adding additional text and documents inherently 
increases the burden on readers.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Melinda Shore


On 08/31/2011 11:14 AM, Keith Moore wrote:

When the text in 2119 is already clearly written, but people fail to read it,

 I don't understand why adding more text in yet another document is
 likely to improve understanding.   Adding additional text and
 documents inherently increases the burden on readers.

This seems pretty clear to me, and perhaps it's been the only clear 
thing in this discussion so far.  2119 was published in 1997 and aside

from a typo (that does not seem to have caused confusion, for whatever
that's worth) there haven't been a lot of complaints.  Thumbs up on
correcting typos, and both thumbs down on using the process of
correcting a typo to reopen a SHOULD/MAY rathole, or even a NOT
RECOMMENDED rathole.  I'd rather let the typo stand.  I don't think
the putative benefits of revising 2119 justify the effort.

Melinda
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


Keith Moore wrote:

Correct again, it is not unclear.  It says it very clear.  I don't know 
why you wish to ignore Tony's I-D reinforcing this concept and 
optional implementation:


  SHOULD, RECOMMENDED:  The words ought, encouraged and suggest
strongly can be used to connote something that is strongly
urged.



When the text in 2119 is already clearly written, but people fail to read 
it, I don't understand why adding more text in yet another document is 
likely to improve understanding.   Adding additional text and documents 
inherently increases the burden on readers.


I'm having a hard time understanding why you continue to work on the 
basis that people fail to read essentially implying stupidity in the 
process.  The Point being that if Tony's I-D has it as it was  shown 
above, then it would be incorrect too in its understanding of RFC2119 
because non-normative words are clearly concepts related to a 
non-required mandate.


I suggest we have a huge history of protocol deployment where SHOULDs 
are ignored and SHOULDs implemented as an option, but in addition, the 
idea of the possibility that isn't presented as an option to operators 
was solely an implementator decision to enforce it and not make an 
optional feature for the operator to play with.  It is really up to 
the author to describe what the intent is for a particular SHOULD 
because its not an universal idea that SHOULD is always implemented.


Anyway, I think that's it for me on this. :)

--
HLS
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

On Aug 31, 2011, at 3:44 PM, Hector wrote:

 I'm having a hard time understanding why you continue to work on the basis 
 that people fail to read essentially implying stupidity in the process.

I work on the basis of fail to read because I've seen countless examples of 
it.   And stupidity is not the same thing as lack of diligence.

  The Point being that if Tony's I-D has it as it was  shown above, then it 
 would be incorrect too in its understanding of RFC2119 because non-normative 
 words are clearly concepts related to a non-required mandate.

As far as I'm concerned, Tony's I-D is a nonstarter, and therefore irrelevant.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith 
 Moore
 Sent: Wednesday, August 31, 2011 12:51 PM
 To: Hector
 Cc: IETF discussion list
 Subject: Re: 2119bis

 On Aug 31, 2011, at 3:44 PM, Hector wrote:

  I'm having a hard time understanding why you continue to work on the
  basis that people fail to read essentially implying stupidity in the
  process.

 I work on the basis of fail to read because I've seen countless
 examples of it.   And stupidity is not the same thing as lack of
 diligence.

Ditto.  And I also see a lot of creative interpretation.  There's little we can 
do to thwart any of those problems; some people read what they want to read and 
do so in a vacuum.

 As far as I'm concerned, Tony's I-D is a nonstarter, and therefore
 irrelevant.

I certainly agree that it's irrelevant to this discussion, plus it's only an 
I-D at this point anyway.  We're talking about a published BCP here.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Tony Hansen


On 8/31/2011 3:14 PM, Keith Moore wrote:

On Aug 31, 2011, at 3:07 PM, Hector wrote:


RFC2119 is not unclear on this point.
Correct again, it is not unclear.  It says it very clear.  I don't know why you 
wish to ignore Tony's I-D reinforcing this concept and optional implementation:

   SHOULD, RECOMMENDED:  The words ought, encouraged and suggest
 strongly can be used to connote something that is strongly
 urged.


When the text in 2119 is already clearly written, but people fail to read it, I 
don't understand why adding more text in yet another document is likely to 
improve understanding.   Adding additional text and documents inherently 
increases the burden on readers.


context check. The purview of the non2119-nonkeywords doc is to suggest 
wording to use when *NOT* in the 2119 context.


Perhaps the paragraph in the non2119-nonkeywords docs should read:

*instead* of SHOULD or RECOMMENDED:  The words ought, 
encouraged and suggest

strongly can be used to connote something that is strongly
urged.

Tony
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Melinda Shore


On 08/31/2011 12:09 PM, Tony Hansen wrote:

context check. The purview of the non2119-nonkeywords doc is to suggest
wording to use when *NOT* in the 2119 context.


Personally, I'm okay with an ambiguous, informal may.  I'm
even okay with an ambiguous, informal must.  I'm less okay
with the IETF publishing a thesaurus.

Melinda

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis


Keith Moore wrote:

The Point being that if Tony's I-D has it as it was  shown above, 
then it would be incorrect too in its understanding of RFC2119 
because the non-normative words are clearly concepts related to a 
non-required mandate.


As far as I'm concerned, Tony's I-D is a nonstarter, and therefore irrelevant.


Oh the irony in the Failure to Read labeling category, the art of 
selective synergism, :) if only to acknowledge the rich IETF-MAN-YEARS 
behind the production of this I-D and its obvious relationship to 
RFC2119 and any future consideration for a RFC2119BIS. :)


Thanks
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Mark Nottingham

If the author is disciplined enough to use them in that manner, sure.

I haven't come across many.


On 01/09/2011, at 1:43 AM, Jari Arkko wrote:

 
 Unless of course one considers us the Protocol Nanny's(tm) - if do not do a 
 SHOULD, we will send you to bed without your treacle! I.e., there IS NO 
 DISTINCTION BETWEEN A BARE SHOULD AND A MAY.
 
 
 Of course there is. Its the distinction between -
 
 Qualified SHOULD) Here lie dragons. Take the recommended route, unless you 
 know how to fight them.
 
 Unqualified SHOULD) Here lie some dangers. Check with someone who knows, or 
 take the recommended route.
 
 MAY) Here's an area. You could go there.
 
 Of course, the first and last pieces of text are preferred. But sometimes no 
 one was brave enough to explore the area, so we don't actually know what 
 dangers there are, they cannot be listed.
 
 Jari
 

--
Mark Nottingham   http://www.mnot.net/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-31 Thread Eric Burger

This highlights an interesting issue as an RFC goes from PS to IS.  I would 
offer that most SHOULDs in a document will, if there are real implementations 
out there, migrate to MUST or MUST NOT.

On Aug 31, 2011, at 9:57 AM, hector wrote:

 I think you are speaking of long term operations where an SHOULD is so widely 
 adopted, it inherently because a MUST have in all new implementations.  So 
 that vain, sure, eventually the better options naturally become part of the 
 protocol to the extent the options might be even remove to simplify things.  
 We also have the opposite where a SHOULD is implemented but no one users it 
 so eventually, it may be remove as an option.



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

2011-08-30 Thread Thomson, Martin

On 2011-08-30 at 07:36:58, Peter Saint-Andre wrote:
 for long enough, I finally decided to submit an I-D that is intended 
 to obsolete RFC 2119. 

bike-shed
IS THERE ANY CHANCE OF AGREEING THAT SHOUTING IS BAD?  (i.e., Burger's first 
anti-law.)  As opposed to mandating that requirements ought to be shouted.  
Lowercase must can be as effective as uppercase as long as it is consistently 
applied.
/bike-shed

On a more serious note, many documents lean too heavily on conformance terms.

A gentle reminder that conformance terms ought to be sparingly used might not 
go astray here.  It's just like the F-bomb, it's a F-ing big deal if used 
infrequently enough.  People are more likely to pay attention when it's rare.

--Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-30 Thread HLS

On 8/30/11, Murray S. Kucherawy m...@cloudmark.com wrote:

 Mark Nottingham:
 1) I agree that the SHOULD... UNLESS pattern ought be documented.

 I had never thought of this before.  I kind of like the idea, especially 
 since SHOULD
 has always meant MUST unless you really know what you're doing

Such an odd reading.  Does it mean you MUST because you could not
handle it otherwise?

It takes two to tango.  One side reasons can be different than the
other. If a software breaks down because it read SHOULD as a MUST and
expected the other end will also view is a MUST, then it didn't know
what it was doing.  Things break down. Implementors on either side
can't depend on it and need to function in lieu of it. There is always
the possibility one decided Na, not needed, not worth the cost.
Its not required. etc, and no one should die because of that
decision.

I think it MUST be noted that a Minimum Implementation for a protocol
is all anyone can expect. If a SHOULD item is among the listed minimum
requirements, it MUST be removed from the list or changed to a MUST.

Maybe the term Minimum Implementation (is part of, is not part of) can
be incorporated into each of the key word text.

-- 
hls
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-30 Thread Eliot Lear

Frank,


On 8/30/11 12:15 AM, Frank Ellermann wrote:
 On 29 August 2011 23:36, Peter Saint-Andre wrote:

 staring at http://www.rfc-editor.org/errata_search.php?eid=499 for
 long enough, I finally decided to submit an I-D that is intended to
 obsolete RFC 2119.
 There are literally thousands of documents (not only RFCs, also W3C
 standards, etc.) with normative references to RFC 2119 (sic!) instead
 of BCP 14, and I see no compelling reason to render these references
 as historic.

On the basis of this logic we wouldn't be able to supercede any of our
key RFCs.

 [...]

 How about trying an updates 2119 and status BCP, where BCP 14 then
 consists of 2119 and 2119bis, and old RFC 2119 references are still
 okay as is.

What ends up happening, then, is that we need Internet lawyers to
traipse through references.  I challenge you or anyone else here to list
all the process RFCs that update RFC 2026.  Let's not repeat that fiasco
with 2119.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-30 Thread Mykyta Yevstifeyev


Frank,

2119bis is going to replace RFC 2119, and Obsoletes: 2119 header is 
fine here.  Updates: header means that some changes are made, and 
these specific changes are clearly indicated; 2119bis imports all the 
content of 2119 plus adding own changes, and is a significant update of 
2119, so Updates: 2119 is inappropriate (sorry for pun).


I would rather object to making RFC 2119 Historic; I remember RFC 2026 
discusses such case (probably Section 6.3, which is also applicable to 
BCPs).  So, the following change is necessary:


Abstract and Introduction (similar text).  OLD: If approved, this 
document obsoletes RFC 2119 and changes its status to Historic.; NEW: 
This document obsoletes RFC 2119.


Mykyta Yevstifeyev

30.08.2011 1:15, Frank Ellermann wrote:

On 29 August 2011 23:36, Peter Saint-Andre wrote:


staring at http://www.rfc-editor.org/errata_search.php?eid=499 for
long enough, I finally decided to submit an I-D that is intended to
obsolete RFC 2119.

There are literally thousands of documents (not only RFCs, also W3C
standards, etc.) with normative references to RFC 2119 (sic!) instead
of BCP 14, and I see no compelling reason to render these references
as historic.

For starters simply confirm the erratum, I don't see why that caused
you headaches.

IMO it is not necessary (but allowed) to import any BCP 14 terms not
actually used in a document, i.e., I disagree with section 4 in your
draft.

How about trying an updates 2119 and status BCP, where BCP 14 then
consists of 2119 and 2119bis, and old RFC 2119 references are still
okay as is.

Readers with difficulties to figure out what RFC 2119 meant might
find the confirmed erratum and the updated by 2119bis with better
answers.  Authors could use RFC 2119, 2119bis, or even BCP 14 in
the references of new documents, where BCP 14 would be new, IIRC
RFC 2119 did not permit this -- fearing precisely what is happening
now, somebody trying to update critical terms.  I think that your
new definitions match precisely what RFC 2119 wanted, but I'm also
almost sure that some old 2119 clients will disagree.

-Frank
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-30 Thread Mykyta Yevstifeyev

30.08.2011 3:08, Mark Nottingham wrote:

Thanks for starting this, Peter. A few comments / topics for discussion:

1) I agree that the SHOULD... UNLESS pattern ought be documented.

I think 2119bis should discuss use of the keywords in conditional
clauses, how to interpret something like a MUST be set to b if c
is d, or a SHOULD be b if c and SHOULD be d if e etc.
Defining the keyword ... IF/keyword ... UNLESS constructions for
all of them?

2) I strongly believe that authors should be encouraged to enumerate the
potential subjects of conformance terms, and to use them in every instance.

For example, a requirement like this:

The Foo header MUST contain the bar directive

is ambiguous; it doesn't specify who has to do what. Rather,

Senders MUST include the bar directive when producing the Foo header; recipients that receive a Foo
header without a bar directive MUST ...

is unambiguous (assuming that the spec defines the terms sender and
recipient).

+1.

3) It may be worth further cautioning against over-use of MAY; this is the
most-abused term, IME. Perhaps encouraging people to make requirements testable
on the wire would help.

My personal observation is that MAY is often used in sense of can,
i.e. to designate possibility rather than optionality. So 2119bis
should be clear that MAY is used for describing discretionary
actions/behavior, and those authors who wish to denote possible action
should use can, which shouldn't be included in the repertoire as being
irrelevant to conformance.

4) WRT to the status of the document -- if people really feel that we don't
need to revise 2119, I'd define this as a superset of 2119 and NOT obsolete it;
i.e., have documents opt into it. However, I'd hope that we can get consensus
that it's time to build on what 2119 offers.

See my previous message.

Mykyta Yevstifeyev

Cheers,

On 30/08/2011, at 7:36 AM, Peter Saint-Andre wrote:

After staring at http://www.rfc-editor.org/errata_search.php?eid=499 for
long enough, I finally decided to submit an I-D that is intended to
obsolete RFC 2119. I hope that I've been able to update and clarify the
text in a way that is respectful of the original. Feedback is welcome.

http://www.ietf.org/id/draft-saintandre-2119bis-01.txt

Peter

--
Peter Saint-Andre
https://stpeter.im/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

--
Mark Nottingham http://www.mnot.net/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-30 Thread Marshall Eubanks

Dear Eric;

I support adding the SHOULD ... UNLESS formalism (although maybe it should
be MUST... UNLESS). It would be useful as there will be times where the
UNLESS can be specified and has been given due consideration at the time of
writing. That, however, will not always be the case. (More inline).

On Mon, Aug 29, 2011 at 10:44 PM, Eric Burger ebur...@standardstrack.comwrote:

 Yes, and...

 I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X
 *are* what people usually mean when they say SHOULD.  In the spirit of Say
 What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting
 to the author to turn the statement into the if Y then MUST X or if Z then
 MUST NOT X form.  Being pedantic and pedagogic:
SHOULD send a 1 UNLESS you receive a 0
 really means
UNLESS you receive a 0, one MUST send a 1.

 My vision of the UNLESS clause is not necessarily a protocol state, but an
 environment state.  These are things that I can see fit the SHOULD/UNLESS
 form:
SHOULD send a 1 UNLESS you are in a walled garden
SHOULD flip bit 27 UNLESS you have a disk
SHOULD NOT explode UNLESS you are a bomb
 are all reasonable SHOULD-level statements.


But how about

SHOULD do FOO UNLESS you have given serious consideration as to the
consequences of not doing FOO.

Isn't that really the original intention of SHOULD ?  Do we gain anything if
that is added every time it is used?


 I would offer that ANY construction of SHOULD without an UNLESS is a MAY.


How about this as a counterexample.

In London, you MAY use the tube for transport. Given the weather, you SHOULD
carry an umbrella.

This SHOULD and  MAY convey different things, in a way that I would argue is
useful, and enumerating a list of UNLESSes is not going to be exhaustive.


 Unless of course one considers us the Protocol Nanny's(tm) - if do not do a
 SHOULD, we will send you to bed without your treacle!


Now, now, now. This is the IETF. We use cookies for motivation.

Regards
Marshall


 I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY.

 On Aug 29, 2011, at 9:47 PM, ned+i...@mauve.mrochek.com wrote:

  Hi -
 
  From: Eric Burger eburge...@standardstrack.com
  To: Narten Thomas nar...@us.ibm.com; Saint-Andre Peter 
 stpe...@stpeter.im
  Cc: IETF discussion list ietf@ietf.org
  Sent: Monday, August 29, 2011 3:08 PM
  Subject: Re: 2119bis
 
  I would assume in the text of the document.  This paragraph is simply
 an enumeration of Burger's Axiom:
  For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a
 MAY.
 
  I disagree.
 
  I concur with your disagreement. SHOULD should *not* be used when the
  list of exceptions is known and practically enumerable.
 
  If the UNLESS cases can be fully enumerated, then
  SHOULD x UNLESS y is equivalent to WHEN NOT y MUST X.
  (Both beg the question of whether we would need to spell out that
  WHEN y MUST NOT X is not necessarily an appropriate inference.)
 
  RFC 2119 SHOULD is appropriate when the UNLESS cases are
  known (or suspected) to exist, but it is not practical to exhaustively
  identify them all.
 
  Let's not gild this lily.
 
  +1
 
Ned
  ___
  Ietf mailing list
  Ietf@ietf.org
  https://www.ietf.org/mailman/listinfo/ietf


 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

+1, too.

This goes along with my strong desire to eliminate passive voice, unless the 
goal is to have the actor be obfuscated (as an example).

On Aug 30, 2011, at 5:29 AM, Mykyta Yevstifeyev wrote:

 2) I strongly believe that authors should be encouraged to enumerate the 
 potential subjects of conformance terms, and to use them in every instance.
 
 For example, a requirement like this:
 
 The Foo header MUST contain the bar directive
 
 is ambiguous; it doesn't specify who has to do what. Rather,
 
 Senders MUST include the bar directive when producing the Foo header; 
 recipients that receive a Foo header without a bar directive MUST ...
 
 is unambiguous (assuming that the spec defines the terms sender and 
 recipient).
 
 +1.



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote:
 Dear Eric;
 
 I support adding the SHOULD ... UNLESS formalism (although maybe it should be 
 MUST... UNLESS). It would be useful as there will be times where the UNLESS 
 can be specified and has been given due consideration at the time of writing. 
 That, however, will not always be the case. (More inline).
[snip]
 But how about 
 
 SHOULD do FOO UNLESS you have given serious consideration as to the 
 consequences of not doing FOO.
 
 Isn't that really the original intention of SHOULD ?  Do we gain anything if 
 that is added every time it is used?

Looking at this from a protocol perspective, SHOULD now equals MAY.  There is 
no objective way of deciding when to do FOO or not.

[snip]

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

I would offer that working groups that say to do something that may or may not 
hold in foreseen or unforeseen circumstances is most likely working on a 
protocol that is way too complex and is begging for interoperability problems.  
What ever happened to building simple, point-solution protocols that followed 
the hour-glass and end-to-end principles, and then building your complex 
protocols out of them?

On Aug 29, 2011, at 11:11 PM, Keith Moore wrote:

 On Aug 29, 2011, at 10:44 PM, Eric Burger wrote:
 
 I would offer that ANY construction of SHOULD without an UNLESS is a MAY.
 
 The essential beauty of SHOULD is that it gets specification writers and 
 working groups out of the all-too-common rathole of trying to anticipate and 
 nail down every exceptional case.
 
 Keith
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

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.

Keith

On Aug 30, 2011, at 9:51 AM, Eric Burger wrote:

 I would offer that working groups that say to do something that may or may 
 not hold in foreseen or unforeseen circumstances is most likely working on a 
 protocol that is way too complex and is begging for interoperability 
 problems.  What ever happened to building simple, point-solution protocols 
 that followed the hour-glass and end-to-end principles, and then building 
 your complex protocols out of them?
 
 On Aug 29, 2011, at 11:11 PM, Keith Moore wrote:
 
 On Aug 29, 2011, at 10:44 PM, Eric Burger wrote:
 
 I would offer that ANY construction of SHOULD without an UNLESS is a MAY.
 
 The essential beauty of SHOULD is that it gets specification writers and 
 working groups out of the all-too-common rathole of trying to anticipate and 
 nail down every exceptional case.
 
 Keith
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote:

 I support adding the SHOULD ... UNLESS formalism (although maybe it should be 
 MUST... UNLESS). It would be useful as there will be times where the UNLESS 
 can be specified and has been given due consideration at the time of writing. 
 That, however, will not always be the case. (More inline).

How would SHOULD...UNLESS or MUST...UNLESS differ from using the current 2119 
definitions and just writing SHOULD...unless or MUST ... unless?

Personally I think 2119 is just fine and doesn't need to be updated.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

This sentiment mostly makes sense.

If an endpoint expects SHOULD/MAY items implemented as MUSTs on the remote end, 
then one should slap the endpoint developer silly.  Read the RFC!  If it says 
SHOULD/MAY, then your implementation MUST be able to handle the feature present 
*and* absent.

Note that every SHOULD/MAY in a specification introduces cyclomatic complexity. 
 Every SHOULD/MAY results in at least one if statement, to test the presence 
or absence of the feature in the remote end.  Protocols will be much simpler to 
implement. Moreover, given the results in the software engineering literature 
that indicate latent defects appear super-linearly with cyclomatic complexity, 
protocols without (or a minimum) of SHOULD/MAY features will have fewer defects 
in the field.

Remember, we are working on Internet protocols, where a one-in-a-million corner 
case happens many times per day.

On Aug 30, 2011, at 4:00 AM, HLS wrote:

 On 8/30/11, Murray S. Kucherawy m...@cloudmark.com wrote:
 
 Mark Nottingham:
 1) I agree that the SHOULD... UNLESS pattern ought be documented.
 
 I had never thought of this before.  I kind of like the idea, especially 
 since SHOULD
 has always meant MUST unless you really know what you're doing
 
 Such an odd reading.  Does it mean you MUST because you could not
 handle it otherwise?
 
 It takes two to tango.  One side reasons can be different than the
 other. If a software breaks down because it read SHOULD as a MUST and
 expected the other end will also view is a MUST, then it didn't know
 what it was doing.  Things break down. Implementors on either side
 can't depend on it and need to function in lieu of it. There is always
 the possibility one decided Na, not needed, not worth the cost.
 Its not required. etc, and no one should die because of that
 decision.
 
 I think it MUST be noted that a Minimum Implementation for a protocol
 is all anyone can expect. If a SHOULD item is among the listed minimum
 requirements, it MUST be removed from the list or changed to a MUST.
 
 Maybe the term Minimum Implementation (is part of, is not part of) can
 be incorporated into each of the key word text.
 
 -- 
 hls
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

On Aug 30, 2011, at 9:56 AM, Eric Burger wrote:

  Every SHOULD/MAY results in at least one if statement, to test the 
 presence or absence of the feature in the remote end. 

false. 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

Strictly speaking, you are correct, in that if one interprets SHOULD/MAY as 
'not bother', one does not need to check, unless the presence of the remote end 
doing the feature results in your barfing.  However, if one interprets 
SHOULD/MAY as 'bother', then one most likely needs to check on the capabilities 
of the far end or handle the varying data elements or protocol states that will 
or will not happen.

On Aug 30, 2011, at 9:58 AM, Keith Moore wrote:

 On Aug 30, 2011, at 9:56 AM, Eric Burger wrote:
 
  Every SHOULD/MAY results in at least one if statement, to test the 
 presence or absence of the feature in the remote end. 
 
 false. 
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-30 Thread Marc Petit-Huguenin

-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.

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

 
 Keith
 
 On Aug 30, 2011, at 9:51 AM, Eric Burger wrote:
 
 I would offer that working groups that say to do something that may or may
 not hold in foreseen or unforeseen circumstances is most likely working on
 a protocol that is way too complex and is begging for interoperability
 problems.  What ever happened to building simple, point-solution protocols
 that followed the hour-glass and end-to-end principles, and then building
 your complex protocols out of them?
 
 On Aug 29, 2011, at 11:11 PM, Keith Moore wrote:
 
 On Aug 29, 2011, at 10:44 PM, Eric Burger wrote:
 
 I would offer that ANY construction of SHOULD without an UNLESS is a
 MAY.
 
 The essential beauty of SHOULD is that it gets specification writers and
 working groups out of the all-too-common rathole of trying to anticipate
 and nail down every exceptional case.
 

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

iEYEARECAAYFAk5c8DMACgkQ9RoMZyVa61dv/ACfRCGdkyioOtkcLOR5P5AT7EGE
y/gAn2LtqRUztE/HJEpTAMuY2eoVrRjp
=VFmG
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

2011-08-30 Thread HLS

On 8/30/11, Keith Moore mo...@network-heretics.com wrote:
 On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote:

 Personally I think 2119 is just fine and doesn't need to be updated.

 Keith

+1

-- 
hls
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis