Subject: [core] Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Thu, 21 Aug 2014 05:14:34 -0700

Pete Resnick has entered the following ballot position for
draft-ietf-core-groupcomm-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with others: I sure would like to see this be Experimental, see
some implementation experience, and, when security issues are sussed out,
see it moved onto the Standards Track.

A few small comments; nothing earth-shattering:

2.7.2.1/2.7.2.2/2.7.2.6/2.7.2.7:

   ...the endpoint MUST effect registration...as soon as possible.
   
"MUST" do something "as soon as possible" does not seem like a testable
requirement. What purpose is it serving?

2.8: These normative behaviors and guidelines look like they could use
2119 keywords. In particular, quite a few of those "should not"s look
like they are meant as "SHOULD NOT"s. They obviously don't need to be,
but I was wondering if there was something I was missing.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Aug 2014 10:27:04 -0400

> but I was wondering if there was something I was missing.

That was actually due to my push-back: earlier versions had too much
SHOULD/SHOULD NOT, and used some of them in ways I thought were
inappropriate.  The authors chose to resolve that by taking all the
2119 key words out of 2.8 and 2.9 entirely.  I thought that was
farther than they needed to go, but that it didn't make the result
incorrect, so I accepted it.

Barry

---

From: Pete Resnick <[email-masked]>
Date: Thu, 21 Aug 2014 09:39:26 -0500

> incorrect, so I accepted it.

"The AD said something! Quick! Change it!" :-D

I agree, there's nothing actively bad about the current text. But if the 
authors want an excuse to say, "See Barry, I told you we should have 
more SHOULD NOTs!", I'm there to back you up. ;-)

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 28 Aug 2014 08:59:30 +0000

Hello Pete, Barry, Ben, (all reviewers,)

Thanks for your input. Due to holidays I wasn't able to follow the groupcomm discussion (regarding RFC2119 language) in detail; hence my late entry in the discussion - see below.

There is a consistency problem in the current text (-22). Sometimes capitals MUST/SHOULD are used to restate an existing requirement from another RFC (such as 7252), in other cases lowercase is used. I would like to see this made consistent if possible.

Martin prefers not repeating requirements from 7252. Ben prefers not repeating requirements from 7252; but also suggests to avoid lower case versions of 2119 words. This makes it a bit of a challenge to find the right words. Barry did not seem to favor either approach, as long as consistent.

The authors preference was repeat capitals and indicating clearly in the paragraph intro that these requirements are from 7252. But given the comments, we can remove the 2119 language in the whole document wherever a MUST/SHOULD/etc requirement is already specified in 7252 or another referred RFC. We then use the lower case version of the same word; to make it easier for us & future readers.

Let me know whether this proposal is okay for you.

Regards,
Esko

-----Original Message-----
From: Pete Resnick [mailto:[email-masked]]
Sent: Thursday, August 21, 2014 16:39
To: Barry Leiba
Cc: [email-masked]; The IESG; core WG; [email-masked]
Subject: Re: Pete Resnick's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT)

On 8/21/14 9:27 AM, Barry Leiba wrote:
>> like they are meant as "SHOULD NOT"s. They obviously don't need to
>> be, but I was wondering if there was something I was missing.
>>

I agree, there's nothing actively bad about the current text. But if the authors want an excuse to say, "See Barry, I told you we should have more SHOULD NOTs!", I'm there to back you up. ;-)

pr

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Aug 2014 09:53:33 -0400

Hi, Esko.  I hope you enjoyed your holidays.

> Martin prefers not repeating requirements from 7252. Ben prefers not
> repeating requirements from 7252; but also suggests to avoid lower
> case versions of 2119 words. This makes it a bit of a challenge to
> find the right words. Barry did not seem to favor either approach, as
> long as consistent.
>
> The authors preference was repeat capitals and indicating clearly in
> the paragraph intro that these requirements are from 7252. But given
> the comments, we can remove the 2119 language in the whole document
> wherever a MUST/SHOULD/etc requirement is already specified in 7252 or
> another referred RFC. We then use the lower case version of the same
> word; to make it easier for us & future readers.

For my part, I think this:

1. Avoiding the use of "may", "should", and "must" as plain English
words is silly, and an unfortunate artifact.  I would prefer to use
the right word, and explain in the 2119 boilerplate that it only
applies to words in ALL CAPS.  We have a number of examples where this
has been done, and Ted Lemon drafted a statement about that, which the
IESG never agreed upon, but which you can use as an example:
http://trac.tools.ietf.org/group/iesg/trac/wiki/Draft2119BoilerplateSuggestions

2. If the main requirements really are in another document, I prefer
handling it in one of two ways:

2a. Quote the requirement verbatim, and include it indented (as in a
blockquote).  That would include the 2119 key words, but would make it
clear that it was a direct quote from 7252 (or wherever).

2b. Paraphrase the requirement from 7252, giving the sense of it but
not using an exact quote.  Use no 2119 key words, but send people to
7252 for the details.

2.1. In either case of 2a or 2b, include the section number(s) in the
7252 citation(s).  7252 is a big document, and it needs to be easy for
the reader to find exactly what you're pointing to.

(Actually, 2.1 is a good general rule here: Whenever you cite 7252 for
something specific, please include a section number where the specific
thing can be found.  Obviously, if you're just referring to "the CoAP
specification [RFC7252]", that's not specific, and this doesn't apply
to that.)

Barry