Good point, timeouts are important and we know in practice, they vary
for many reasons, and in many cases, there are different functional
needs depending on human versus automated interfaces/handlers.
Nonetheless, I always prefer being specific when all possible. I still
believe this is universal and global and readers will "get it." Give
them the benefit of the doubt. Its a matter of having better written
specifications and understanding there are multiple disciplined readers
and conflicts between administrators (sysops) vs developers (coders).
IMO, in this case because it is related to a required time property
(including the idea that it could be infinite, forever, zero, -1 or
otherwise ), it would be up to the protocol specification to clearly
define what are the boundary conditions for success and failure;
The implementator MUST offer a reasonable timeout value for the
AUTH_LIFETIME notification. A RECOMMENDED timeout value is
4 minutes. Anything less risk X, Y and Z and anything more has
shown to cause this or that.
etc, "Being specific is Terrific"
(Note, I am not aware of RFC 4478. I am provided general input because
this is a general problem. Maybe its too late for existing specs but
future specifications can benefit from better guidelines.)
--
HLS
On 6/25/2013 4:41 PM, Yoav Nir wrote:
Those sentences are here without the context given in RFC 4478. But that RFC is entirely about AUTH_LIFETIME, so if you're not sending it, you're just not implementing the RFC.
Those sentences are about the timing of sending the message. Upon receipt of the message, the client software prompts the user for credentials, so we'd like to have that message sent soon enough so that a human user will have enough time to enter the credentials before the SA expires. So is specifying 4 minutes a "recommendation" or a "should-level requirement"?
IMO, in normal English this would be a recommendation. But in an RFC this is also a should-level requirement, one that a particular implementation might ignore (if the implementers know that the client in this case has no human user). In terms of code, you do the same thing with both sentences: you make sure your VPN gateway sends AUTH_LIFETIME at least 4 minutes before the SA is scheduled to expire. You might even do 15 if you find out that your users tend to take coffee breaks that last that long.
On Jun 25, 2013, at 8:13 PM, Hector Santos <hsantos@xxxxxxxx> wrote:
I want to know more what it translates to as a technical specification for CODING. To me, it means this:
o Authorization Lift Time
[X] Send Notification
Time to send: __4__ mins (default)
The problem as I experienced thus far is whether one MUST IMPLEMENT this protocol feature,in this case code for AUTH_LIFETIME and make it flexible with a default 4 mins timeout.
At the end of the day, this feature is not functionally described as a MUST protocol requirement, therefore as a product producer I have two design options:
1) Don't implement, possible less feature than competitors.
See if others implement it.
2) Implement and make it optional as the UI shows above.
So I don't think its a really a language or native culture thing, its just poor functional/technical specification writing. Of course, if one does not implement AUTH_LIFETIME and they later find out there are interoperability issues with other products in the market, then there is a "BUG" in the specification. It may need to be fixed in a BIS as a MUST or maybe the products that failed when a peer did not support it, then its considered buggy because it read the above as a MUST.
I would like to see a focus to produce more protocol writing guidelines, outline examples and tips on how to best reduce the ambiguity. I think the available RFC templates should include a new section:
1.x Minimum Requirements
This should help writers focus on these type of issues for the multiple discipline readers out there.
--
HLS
On 6/24/2013 4:18 PM, Yoav Nir wrote:
On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre <stpeter@xxxxxxxxxx> wrote:
On 6/24/13 1:47 PM, Michael Thornburgh wrote:
my feeling and belief is that RFC 2119 only gives SHOULD and
RECOMMENDED the same normative requirement level, but that it does
not override or change the distinct meanings of these words in
English. sentences using each of these terms have different meanings
in English, even when those sentences appear in RFCs.
I expect that the subtle differences between these words are lost on
non-native speakers, and even most native speakers, of English. I'd be
genuinely curious to hear that you think the distinct meanings are.
"It is RECOMMENDED that implementations send the AUTH_LIFETIME notification at least 4 minutes before the SA is to be deleted, to facilitate the user entering credentials in time."
"The implementation SHOULD send the AUTH_LIFETIME notification at least 4 minutes before the SA is to be deleted, to facilitate the user entering credentials in time."
- What are the subtle differences in meaning between these two sentences?
- Would an implementation written by a native speaker be any different depending on which of the above sentences was in the RFC?
Yoav