Subject: [Dime] RFC4005bis and issue tracker Ticket #19

From: Jouni <[email-masked]>
Date: Fri, 2 Mar 2012 09:51:20 +0200

Mark,

Are you OK for me to close the Ticket #19 ? Ref these emails:
http://www.ietf.org/mail-archive/web/dime/current/msg04690.html
and then the comment in issue tracker:
http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:1

From my side, I see this issue resolved.

- Jouni

---

From: Mark Jones <[email-masked]>
Date: Fri, 2 Mar 2012 17:47:08 -0500

Hi Jouni,

I'm OK to close the ticket but I suggest adding Glen's explanation to it:

>> And the reasoning behind is?

> OK,I give: how many different reasons could there be?  I can only think
> of one: the text is meant to be descriptive, not prescriptive, that is,
> no rationale is required for acting differently and Diameter
> interoperability is not, AFAICT, effected.

/Mark

---

From: jouni korhonen <[email-masked]>
Date: Sat, 3 Mar 2012 13:24:26 +0200

Hi,

Ok good. I support adding the clarification below.

Glen, once you have done the update I'll take the required
actions to advance this document.

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Sun, 04 Mar 2012 16:58:51 +0700

> Ok good. I support adding the clarification below.

OK, what am I supposed to be updating/clarifying, the ticket or the
draft?  I don't understand the term 'clarify' in the latter case: the
draft seems pretty much crystalline, esp. insofar as the words in
question are intentionally not capitalized.

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Mark Jones <[email-masked]>
Date: Mon, 5 Mar 2012 13:55:51 -0500

> OK, what am I supposed to be updating/clarifying, the ticket or
the draft?

My request was to update the ticket. I assume Glen's "Yes. Its intentional"
in the ticket was referring to the absence of requirement keywords in this
4.5.8 sub-clause:

   - If this AVP is not present, then the session is assigned to an unnamed
   tunnel. If an unnamed tunnel does not yet exist between the specified
   endpoints, then it is established and used for this session and for
   subsequent ones established without the Tunnel-Assignment-Id attribute. A
   tunnel initiator MUST NOT assign a session for which a Tunnel-Assignment-Id
   AVP was not specified to a named tunnel (i.e., one that was initiated by a
   session specifying this AVP).

My request was to add Glen's explanation of the intent to the ticket so we
have at least captured our agreed interpretation of this sub-clause.

I did not think Glen's response was referring to the lower case "should" in
section 4.5.8. I understand from RFC2119 that a "SHOULD" is a "should" is a
"ShOuLd". Correct?

/Mark

---

From: Glen Zorn <[email-masked]>
Date: Tue, 06 Mar 2012 15:13:53 +0700

On 3/6/2012 1:55 AM, Mark Jones wrote:
> My request was to update the ticket. 

OK, thanks.

> I assume Glen's "Yes. Its
> intentional" in the ticket was referring to the absence of requirement
> keywords in this 4.5.8 sub-clause:
> 
>   * If this AVP is not present, then the session is assigned to
>     an unnamed tunnel. If an unnamed tunnel does not yet exist
>     between the specified endpoints, then it is established and used for
>     this session and for subsequent ones established without the
>     Tunnel-Assignment-Id attribute. A tunnel initiator MUST NOT assign
>     a session for which a Tunnel-Assignment-Id AVP was not specified
>     to a named tunnel (i.e., one that was initiated by a
> My request was to add Glen's explanation of the intent to the ticket so
> we have at least captured our agreed interpretation of this sub-clause.
> 
> I did not think Glen's response was referring to the lower case "should"
> in section 4.5.8. 

Actually, it was referring to everything in that section after this:

   If a tunnel initiator supports the Tunnel-Assignment-Id AVP, then it
   should assign a session to a tunnel in the following manner:

> I understand from RFC2119 that a "SHOULD" is a
> "should" is a "ShOuLd". Correct?

I guess that this comes from the statement in the abstract for 2119 that

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.

My interpretation of this is a little different, though: I take it as a
description of the existing practice at the time, not as part of the
codification of future practice that the rest of the document specifies.

> 
> /Mark
> 
> 
> On Sun, Mar 4, 2012 at 4:58 AM, Glen Zorn <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     >> On Fri, Mar 2, 2012 at 2:51 AM, Jouni <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >> Mark,
>     >>
>     > [email-masked] <mailto:[email-masked]>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Mar 2012 12:29:08 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Glen Zorn

[[DR]] As Glen says. More specifically in a normative document, wherever
interoperability on the wire is impacted the good practice is to use
capitalized keywords. Otherwise use them scarcely if at all. 

Dan

---

From: Mark Jones <[email-masked]>
Date: Tue, 6 Mar 2012 09:15:37 -0500

Hi Dan,

> capitalized keywords. Otherwise use them scarcely if at all.

Agreed. I follow this practice but I recently noticed that the
Terminology section in some RFCs (like 4005) have:

   The key words "MUST", ...

But others (e.g. RFC3920) have:

   The capitalized key words "MUST",...

Should I interpret a lower-case "should" differently in these two RFCs?

/Mark

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Mar 2012 15:58:43 +0100

> From: Mark Jones [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2012 4:16 PM
> To: Romascanu, Dan (Dan)
> Cc: Glen Zorn; [email-masked]
> Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19
> 
> Hi Dan,
> 

No, I do not think the interpretation is different. It is rather about
the automatic tools having started to prompt rigorously to the
boilerplate text deviations at some point in time. 

Dan