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(_at_)isdg(_dot_)net> 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(_at_)stpeter(_dot_)im> 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