Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Jul 2014 14:17:08 -0400

Hi, Akbar.  Thanks for the quick response.  I'm merging the two
reviews and replying in one message.  I'm also eliminating everything
that needs no further comment.  If you don't see it here, it means
your response is fine.

The most important bit first:

> -- Section 5 --
> I really think the security aspects of this are horrid, and it's not
> clear to me that this should be advanced, especially not at Proposed
> Standard, as long as that's the case.  With questionable authentication,
> questionable confidentiality, and apparently no access control, I don't
> know that we should be proposing it now.  But is the working group has
> consensus on doing so, I will send it to the community and the IESG.
> Were I you, I'd expect to get lambasted in the SecDir review and by the
> Sec ADs.  Just a warning.
>
> **[Akbar-7] - First, please note that this document (groupcomm) is
> proposed to be Informational and not Proposed Standard.  As we stated in
> section 1.2 (Scope), the normative aspects of group communications is
> specified in RFC7252 (e.g. basic rules for multicast are in
> http://tools.ietf.org/html/rfc7252#section-8 and for security in
> http://tools.ietf.org/html/rfc7252#section-9.1 ).  The intent of this
> groupcomm draft is just to explain/illustrate the normative rules of
> RFC7252 which is fairly terse and sometimes a bit hard to understand
> without a lot of background knowledge.  The only really "new"
> functionality we are introducing is in section
> 2.7.2 (Membership Configuration RESTful Interface).  This functionality
> for setting the group membership is not covered in any other CoAP
> document.  Can you please confirm that an Informational document can
> define the functionality included in section 2.7.2.  We have brought
> this up in the WG several times and the answer was always positive.  But
> we would like to ask you again.

And, gee, yes, I knew when I started the review that this was
Informational.  And I forgot by the time I got here.  That does make a
difference.

That said, I think you *are* specifying a protocol here: the protocol
is the group management that's wrapped around the already-standard use
of CoAP with multicast, and the way to use requests and responses with
groups -- you're layering a group protocol over CoAP.

Let's go ahead and continue this as Informational, and see whether
other ADs think it's a protocol that should be Standards Track.

Let's also try to avoid having this shredded by the Sec ADs, though.
See if you can come up with a paragraph to put into Section 1.2 that
talks about how there's no authentication, confidentiality, or access
control available in CoAP over multicast, and that group communication
does nothing to change that.  Say something about the work that's in
progress to address this, and what still might have to be done to
ensure that the right security, including access controls, is
available.  Then put a backward reference to Section 1.2 into the
Security Considerations.

> While I don't object to it, I don't see why you need to cite RFC 7320
> here.  Maybe you should explain the second list item 1 to me more.
> It's my understanding that the URI paths are *used* by the clients, but
> that they don't represent resources in the clients -- they represent
> resources in the servers.  Is that correct?
>
> **[Akbar-5] - Yes, the URIs (authority/path) represent resources in the
> servers (and not the sending client).   The RFC7320 reference was added
> because at one time we had discussions in the WG regarding if we should
> hardcode a path name for group communications.  Meaning that we should
> take the "/.well-known/core" idea for discovery and try to hardcode
> something similar for group communications (e.g. "/groupcomm/core" or
> "/core/groupcomm").   However, RFC7320
> (http://tools.ietf.org/html/rfc7320#section-2.3) specifically advises
> against this approach.   So, we would prefer to leave the RFC7320
> reference in (and point it to specifically section 2.3 if that helps
> clarify).  Is that ok with you?

As I said, I don't object to your citing 7320 if you think you need to
(I think it doesn't need to be normative, if you're just explaining a
rationale for the way you're doing something).  But I still don't
think you explain enough in the last sentence for me to understand why
you're saying that: "Note that ([RFC7320]). prescribes that any
specification must not constrain, define structure or semantics for
any path component." (There's an extra "." in that sentence, by the
way.)

If you want to say this, I think you should say "we did X instead of
Y, because 7320 precludes Y when it says Z."  And, again, I'd have to
see the final text to be sure, but my guess is that the reference can
go back to Informative.

> -- Section 2.4 --
>
>    Idempotent CoAP RESTful methods (i.e., GET, PUT, and DELETE) SHOULD
>    be used for group communication, with one exception as follows.  A
>    non-idempotent CoAP method (i.e., POST) MAY be used for group
>    communication if the resource being POSTed to has been designed to
>    cope with the unreliable and lossy nature of IP multicast.
>
> The term "idempotent" is used only here, and you give an exhaustive list
> of the methods anyway.  Why distract readers, rather than just focusing
> on the methods?
>
> **[Akbar-6] - The term "idempotent" is clearly defined in RFC7252
> (http://tools.ietf.org/html/rfc7252#section-5.1), and is an important
> concept in REST in general.  So we wanted to use the term because it
> helps draws the reader's attention to the potential complications of
> using group communications for non-idempotent methods.  So we would
> prefer to leave the term there.  Is that ok with you?

OK, that makes sense.  In that case, merging "idempotent" back into my
suggested change:

NEW
   Group communication uses the idempotent CoAP RESTful
   methods, GET, PUT, and DELETE, in most cases.  The
   non-idempotent CoAP method, POST, may only be used for group
   communication if the resource being POSTed to has been designed
   to cope with the unreliable and lossy nature of IP multicast.
END

>    Using the CoAP
>    default protocol parameters the re-use time becomes at least 250
>    seconds, but may need to be much longer in practice since there is no
>    time limit defined in CoAP for generation of responses by a server.
>
> This concerns me, as it gives no reasonable upper bound as guidance.
> Given that the consequence of falling afoul of it is a potocol error, we
> really should try to scope it better.  Can you provide any upper bound
> for the length of time, even if it comes with some warning?
>
> **[Akbar-9] - Okay.  We will think about an upper bound number and add
> it to the draft.

Thanks.  I'm not expecting anything cast in concrete... just guidance,
so implementers can have a sense of what to do.

> -- Section 2.6 --
>
>    CoAP Groups, and the membership of these groups, can be discovered
>    via the lookup interfaces in the Resource Directory (RD) defined in
>    [I-D.ietf-core-resource-directory].
>
> Given this statement and the second case in 2.7.1, I don't see how that
> document is not a normative reference.  Can you explain your thinking
> about that?  Or can you re-word this so it's clearer that the Resource
> Directory document is optional reading, and doesn't need to be
> understood here?
>
> **[Akbar-10] - The main reason that we do not think that the
> core-resource-directory is normative is because you can build and run a
> system implementing CoAP group communications without a resource
> directory (RD) endpoint in the system.  So the RD concept is useful (and
> complementary) but not mandatory for implementing group communications.
> For example, to implement the functionality in the rest of section 2.7.2
> does not require an RD at all (i.e. the reference to RD in section 2.7.1
> was purely for background).  So I would prefer to leave the document
> informative.  Is that okay with you?

Not on this basis.  Things that are required for optional features are
still normative references, in general.  Consider that CoAP itself
does not have to use DTLS; it's an option.  Yet RFC 6347 is a
normative reference.

It's possible you could convince me that RD is not a normative
reference, but the "optional feature" argument isn't going to do it.

>    The following ABNF rule can be
>    used for parsing the address, referring to the definitions in
>    Section 6 of [RFC7252] and [RFC3986].
>
> It's hard to tell what the scope of "Section 6" is.  Ty this:
>
> NEW
>    The following ABNF rule can be
>    used for parsing the address, referring to the definitions in
>    Section 6 of [RFC7252] and Section 3.2.2 of [RFC3986].
> END
>
> But what definition in 7252 are you referring to?  I don't see one.
>
> **[Akbar-16] - Ok.  We will update as you suggested.  The definition in
> 7252 that we were referring to was in the second paragraph of section 6.
> Do you agree?

Well, all that paragraph says is "go see 3986," and you already cite
3986.  I found it confusing to have the 7252 citation, because I was
looking for something else.  Maybe this sort of thing would make you
happy?:

NEW
   The following ABNF rule can be
   used for parsing the address, as in the base CoAP protocol,
   referring to the definitions in Section 3.2.2 of [RFC3986].
END

>    In a response, the "a" key/value pair
>    SHOULD be included if the IP address is known at the time of
>    generating the response, and MUST NOT be included if unknown.  If the
>    "a" value is not provided in a request, the "n" value in the same
>    group membership object SHOULD be a valid hostname with optional port
>    number that can be translated to an IP multicast address via DNS
>
> More 2119 follies...
> The first SHOULD: Why is it a SHOULD?  What happens to the protocol if
> you don't?
>
> **[Akbar-17] - The "a" is optional.  So that is why it is stated that it
> SHOULD be returned if known.  It cannot be a MUST because it may not be
> there as it is optional.  Is that clear

Right, so we have a disconnect on the meaning of SHOULD in 2119.
SHOULD doesn't mean it's optional.  SHOULD means that it's important
for interoperability, but it's possible not to do it if you understand
the situation and have carefully thought it out.  You give no guidance
for thinking it out, so I asked.

This might just be another case where 2119 key words aren't necessary.
But let's put this together with the other comments on the same list.
I still need to understand how important it is to have "a" there.
There could be three cases:

a. It's preferable to use "a", but "n" is available as a less-preferred option.
b. It's preferable to use "n", but "a" is available as a less-preferred option.
c. You can use "a" or "n", with equal preference.

In addition, there's the question of whether there's value added by
having both "a" and "n" at the same time (one of my comments below
goes to this part).

I think case (a) is correct, yes?

Assuming that:

NEW
   In any group membership object, if the IP address is known when
   the object is created, it is included in the "a" key/value pair.  If the
   "a" value cannot be provided, the "n" value MUST be included,
   containing a valid hostname with optional port number that can be
   translated to an IP multicast address via DNS
END

That says that you include "a" if you can, and if you can't, you MUST
include "n".  Does that work for you?

> How does a locally unique two-character string scale?  Even if we're
> talking about case-sensitive ASCII, that still seems to limit you to
> 3844 unique strings.  Is that enough?
>
> **[Akbar-24] -It is representing the number of IP multicast groups that
> the endpoint is taking part in.  Practically this should be in the order
> of a few tens of groups at most.  So 3844 should be more than enough.

Ah!
I had it backward (or sideways, or something): I thought it was the
endpoint's index in the group, and so it limited group size.  But
you're saying that it's the group's index in the endpoint's list of
groups, so it limits the number of groups an endpoint can belong to.

It's probably worth saying a sentence or two about that, so it's clear.

>    For the 'gp' variable it is recommended to use the path "coap-group"
>    by default.  If the "a" key/value pair is given, this takes priority
>    and the "n" pair becomes informational.
>
> What does it mean for it to be informational?  What should the server do
> with it?
>
> **[Akbar-25] -In effect, it means that the "n" can be ignored.  Should
> we say that instead of saying it becomes informational?  (This is
> because if the IP address ("a") is given, then the name ("n") becomes
> unnecessary.)

Yes.  I would say it this way:

NEW
   The "a" key/value pair is always used if it is given.  The "n" pair
   is only used when there is no "a" pair.
END

>    If only the "n" pair is
>    given, the CoAP endpoint may perform DNS resolution (if supported) to
>    obtain the IP multicast address from the hostname.
>
> What can it do other than performing DNS resolution?  What happens if
> DNS resolution isn't supported?
>
> **[Akbar-26] - If DNS resolution of a multicast name is not supported
> then nothing else can be done.  We used the "if supported" phrase
> throughout as there is not guarantee that there is even a DNS
> infrastructure setup in many constrained networks (e.g. in a building
> lighting scenario).  We will explicitly state this assumption in the
> text for clarity.

Actually, I understand that, so, while it will be fine to highlight
that here, it's not sufficient.  The text here needs to say what to do
if you have no "a", are therefore relying on the "n", and DNS
resolution isn't available.  So:

NEW
   If only the "n" pair is given, the CoAP endpoint performs DNS
   resolution to obtain the IP multicast address from the hostname
   in the "n" pair.  If DNS resolution is not available, [TELL ME].
END

> -- Section 2.8 --
>
>    For IP multicast request acceptance, the REQUIRED behaviors are:
>
> I don't understand how "REQUIRED" applies when the first three items say
> "SHOULD NOT".  Please explain what you mean here, from a protocol
> requirements point of view, so we can figure out how you should really
> say it.  The same goes for the next list in this section, though that's
> probably even worse, because you say that the sever MAY choose not to
> respond, and then you say the server responds.  That seems like bad 2119
> usage.
>
> For the part about response configuration options, why is that a 2119
> "SHOULD"?  How does it affect protocol interoperability?
>
> My guess is that all this will be better said without trying to cram
> 2119 key words into it, but let's first understand your intent.
>
>       Note that in this
>       case the client implements a "reliable group communication" (as
>       defined in Section 1.3) function using additional, non-
>       standardized functions above the CoAP layer.
>
> I'm not sure what this means (so maybe you can explain it to me), but
> I'll point out that *this* protocol (groupcomm) is non-standardized as
> well.
>
> **[Akbar-35]
...
> perhaps the best resolution will be to remove RFC2119 language
> from this section.  Do you agree?  We just wanted to recap all the
> request acceptance and response suppression rules in one place to make
> for a quick summary read for implementers).

The recap makes sense.  Yes, please re-word this bit in clear English,
without worrying about 2119 key words, and let's see what it looks
like then.  I bet it comes out better.  Sometimes we really hurt our
text by trying to put too many MUSTs and SHOULDs and MAYs in.

> **[Akbar-37] - Ok.  Will do as you suggest.  (If you used French
> examples it would have been easier for me to follow!).

:-)

OK, that's it... it looks like we should be able to sort all this out
with one document revision, and get last call started soon.

Barry

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 30 Jul 2014 00:37:36 -0400

Hi Barry,

Thank you for the revised feedback and clarifications.  My co-author,
Esko, and I have discussed them off line and following  are our
consolidated responses (identified as "**[Authors-Response-x]").  Once
you have approved our final answers, we will aim to do a quick update of
the draft to incorporate all your comments.

Best Regards,

Esko & Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barry Leiba
Sent: Monday, July 28, 2014 2:17 PM
To: Rahman, Akbar
Cc: core WG; [email-masked]
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

Hi, Akbar.  Thanks for the quick response.  I'm merging the two reviews
and replying in one message.  I'm also eliminating everything that needs
no further comment.  If you don't see it here, it means your response is
fine.

The most important bit first:

> Standard, as long as that's the case.  With questionable 
> authentication, questionable confidentiality, and apparently no access

> control, I don't know that we should be proposing it now.  But is the 
> working group has consensus on doing so, I will send it to the
community and the IESG.
> Were I you, I'd expect to get lambasted in the SecDir review and by 
> the Sec ADs.  Just a warning.
>
> proposed to be Informational and not Proposed Standard.  As we stated 
> in section 1.2 (Scope), the normative aspects of group communications 
> is specified in RFC7252 (e.g. basic rules for multicast are in
> 2.7.2 (Membership Configuration RESTful Interface).  This 
> functionality for setting the group membership is not covered in any 
> other CoAP document.  Can you please confirm that an Informational 
> document can define the functionality included in section 2.7.2.  We 
> have brought this up in the WG several times and the answer was always

> positive.  But we would like to ask you again.

That said, I think you *are* specifying a protocol here: the protocol is
the group management that's wrapped around the already-standard use of
CoAP with multicast, and the way to use requests and responses with
groups -- you're layering a group protocol over CoAP.

Let's go ahead and continue this as Informational, and see whether other
ADs think it's a protocol that should be Standards Track.

Let's also try to avoid having this shredded by the Sec ADs, though.
See if you can come up with a paragraph to put into Section 1.2 that
talks about how there's no authentication, confidentiality, or access
control available in CoAP over multicast, and that group communication
does nothing to change that.  Say something about the work that's in
progress to address this, and what still might have to be done to ensure
that the right security, including access controls, is available.  Then
put a backward reference to Section 1.2 into the Security
Considerations.

**[Authors-Response-1] - Ok.  We propose adding the following new
paragraph to the end of Section 1.2 (Scope):

NEW
While [RFC7252] supports various modes of DTLS based security for CoAP
over unicast IP, it does not specify any security modes for CoAP over IP
multicast.  That is, [RFC7252] assumes that CoAP over IP multicast is
not encrypted, nor authenticated, nor access controlled.  This document
assumes the same security model (see
http://tools.ietf.org/html/draft-ietf-core-groupcomm-20#section-5.1) .
However, there are several promising security solutions being developed
that should be considered in the future for protecting CoAP group
communications (see
http://tools.ietf.org/html/draft-ietf-core-groupcomm-20#section-5.3.3). 
END

And we propose updating Section 5.3.3 (Future Security Evolution) as
follows:

NEW
In the future, to further mitigate the threats, one or more of the
following security enhancements should be considered for group
communications once the enhancements mature.  This will allow
introduction of a secure mode of CoAP group communication, and use of
the "coaps" scheme for that purpose.  For example,
http://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/
proposes a DTLS-based IP multicast security, and
http://datatracker.ietf.org/doc/draft-mglt-dice-ipsec-for-application-pa
yload/ proposes an IPSec based IP multicast security.  Also, there is
some early work in developing group authentication such as described in
http://datatracker.ietf.org/doc/draft-zhu-ace-groupauth/. 
END

Does the above two changes address your comment?

> It's my understanding that the URI paths are *used* by the clients, 
> but that they don't represent resources in the clients -- they 
> represent resources in the servers.  Is that correct?
>
> because at one time we had discussions in the WG regarding if we 
> should hardcode a path name for group communications.  Meaning that we

> should take the "/.well-known/core" idea for discovery and try to 
> hardcode something similar for group communications (e.g.
"/groupcomm/core" or

As I said, I don't object to your citing 7320 if you think you need to
(I think it doesn't need to be normative, if you're just explaining a
rationale for the way you're doing something).  But I still don't think
you explain enough in the last sentence for me to understand why you're
saying that: "Note that ([RFC7320]). prescribes that any specification
must not constrain, define structure or semantics for any path
component." (There's an extra "." in that sentence, by the
way.)

If you want to say this, I think you should say "we did X instead of Y,
because 7320 precludes Y when it says Z."  And, again, I'd have to see
the final text to be sure, but my guess is that the reference can go
back to Informative.

**[Authors-Response-2] - Ok.  We propose changing the bullet in question
in Section 2.3 to the following:

NEW
   1.  Pre-configured group URI paths, if available.  The
pre-configuration mechanism SHOULD ensure that these (identical) paths
are pre-configured across all CoAP servers in a group and all CoAP
clients performing the group requests.  Implementers are free to define
the paths as they see fit.  However, note that ([RFC7320]) prescribes
that any specification must not constrain, define structure or semantics
for any URI path component.  So for this reason, a pre-defined URI path
is not defined in this document.
END

Also, we agree that we change [RFC7320] to be informational.  Do these
changes address your comment?

> The term "idempotent" is used only here, and you give an exhaustive 
> list of the methods anyway.  Why distract readers, rather than just 
> focusing on the methods?
>

NEW

**[Authors-Response-3] - Ok.  We agree with your proposal, except we
suggest deleting the phrase "in most cases".  This is because DELETE for
example is not expected to be as commonly used as GET (i.e. if we use
the history of HTTP requests as a guideline).  Is that okay with you?

> Given that the consequence of falling afoul of it is a potocol error, 
> we really should try to scope it better.  Can you provide any upper 
> bound for the length of time, even if it comes with some warning?
>

**[Authors-Response-4] - Ok. 

> Given this statement and the second case in 2.7.1, I don't see how 
> that document is not a normative reference.  Can you explain your 
> thinking about that?  Or can you re-word this so it's clearer that the

> Resource Directory document is optional reading, and doesn't need to 
> be understood here?
>
> core-resource-directory is normative is because you can build and run 
> a system implementing CoAP group communications without a resource 
> For example, to implement the functionality in the rest of section 
> 2.7.2 does not require an RD at all (i.e. the reference to RD in 
> section 2.7.1 was purely for background).  So I would prefer to leave 
> the document informative.  Is that okay with you?

Not on this basis.  Things that are required for optional features are
still normative references, in general.  Consider that CoAP itself does
not have to use DTLS; it's an option.  Yet RFC 6347 is a normative
reference.

**[Authors-Response-5] - Ok.  It looks like we should consider to make
the RD reference as normative.  But before we close this issue, could
you point us to any RFC that defines the criteria for making the
decision between Informative vs Normative reference?

NEW

**[Authors-Response-6] - Ok.  We may slightly wordsmith it but that
looks good.

> you don't?
>
> **[Akbar-17] - The "a" is optional.  So that is why it is stated that 
> it SHOULD be returned if known.  It cannot be a MUST because it may 
> not be there as it is optional.  Is that clear

Right, so we have a disconnect on the meaning of SHOULD in 2119.
SHOULD doesn't mean it's optional.  SHOULD means that it's important for
interoperability, but it's possible not to do it if you understand the
situation and have carefully thought it out.  You give no guidance for
thinking it out, so I asked.

a. It's preferable to use "a", but "n" is available as a less-preferred
option.
b. It's preferable to use "n", but "a" is available as a less-preferred
option.
c. You can use "a" or "n", with equal preference.

In addition, there's the question of whether there's value added by
having both "a" and "n" at the same time (one of my comments below goes
to this part).

**[Authors-Response-7] - Yes, that is correct.

Assuming that:

NEW
   the object is created, it is included in the "a" key/value pair.  If
the

**[Authors-Response-8] - Yes.  That is what we meant.  So we will use
your wording.

> **[Akbar-24] -It is representing the number of IP multicast groups 
> that the endpoint is taking part in.  Practically this should be in 
> the order of a few tens of groups at most.  So 3844 should be more
than enough.

Ah!
I had it backward (or sideways, or something): I thought it was the
endpoint's index in the group, and so it limited group size.  But you're
saying that it's the group's index in the endpoint's list of groups, so
it limits the number of groups an endpoint can belong to.

**[Authors-Response-9] - Ok.  We can change the definition of the
"index" in section 2.7.2.2 as follows:

NEW
Index - Group index.  Index SHOULD be a string of 2 alphanumeric ASCII
characters (case insensitive).  It MUST be locally unique to the
endpoint server.  It indexes the particular endpoint's list of group
memberships.
END

> What does it mean for it to be informational?  What should the server 
> do with it?
>

NEW

**[Authors-Response-10] - Yes.  That is what we meant.  So we will use
your wording.

> lighting scenario).  We will explicitly state this assumption in the 

Actually, I understand that, so, while it will be fine to highlight that
here, it's not sufficient.  The text here needs to say what to do if you
have no "a", are therefore relying on the "n", and DNS resolution isn't
available.  So:

NEW

**[Authors-Response-11] - Ok, good point, so we propose the following
wording:

NEW
If only the "n" pair is given, the CoAP endpoint performs DNS resolution
to obtain the IP multicast address from the hostname in the "n" pair.
If DNS resolution is not successful, then the endpoint does not attempt
joining or listening to any multicast group for this case since the IP
multicast address is unknown.
END

Do this address your comment?

> I don't understand how "REQUIRED" applies when the first three items 
> say "SHOULD NOT".  Please explain what you mean here, from a protocol 

> say it.  The same goes for the next list in this section, though 
> that's probably even worse, because you say that the sever MAY choose 
> not to respond, and then you say the server responds.  That seems like

> bad 2119 usage.

...
> perhaps the best resolution will be to remove RFC2119 language from 
> this section.  Do you agree?  We just wanted to recap all the request 
> acceptance and response suppression rules in one place to make for a 
> quick summary read for implementers).

The recap makes sense.  Yes, please re-word this bit in clear English,
without worrying about 2119 key words, and let's see what it looks like
then.  I bet it comes out better.  Sometimes we really hurt our text by
trying to put too many MUSTs and SHOULDs and MAYs in.

**[Authors-Response-12] - Ok, we will re-write the entire section 2.8
without any RFC2119 language as you suggested.  Also, perhaps we should
also re-write section 2.9 without any RFC2119 language as it is a
similar section.  What do you think?

:-)

**[Authors-Response-13] - Thank you!

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 Jul 2014 02:20:18 -0400

> the draft to incorporate all your comments.

Great, thanks.  I think we're all set.  All your responses are OK with me.

> decision between Informative vs Normative reference?

There is no RFC, but there is an IESG Statement:
http://www.ietf.org/iesg/statement/normative-informative.html
Look at the second paragraph and the first note.

> similar section.  What do you think?

That seems sensible.  Personally I think it's just as good to say things
like "IP multicasts requests are always Non-confirmable," instead of "An IP
multicast request MUST be Non-confirmable," though both are OK.  I don't
think the capitalized key words add anything there.

Barry

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 30 Jul 2014 10:30:38 +0000

Hello Barry,

Many thanks for your thorough review! Below additional comments from my side that I think are important to mention.

1- on the use of RFC2119 language in section 2.8 and 2.9: for some instances where this language is used, there is the same normative language in RFC7252 or RFC6690. So the text is there to recap these requirements to the reader.  Of course we can remove the capitals "SHOULD"->"should" but it may be less clear to the reader that there exists an RFC2119-level requirement on the topic.  I agree that the "REQUIRED" keywords can be removed in these sections since they can confuse.
(But perhaps there's a better way to say for certain bullet items that they are not merely our recommendation but there are protocol requirements on it.)

2- on the upper bound for Token re-use ([Akbar-9] item): I remember discussions in CoRE in the past, always coming to the conclusion that there is no upper bound for server response time (similar to HTTP). We could say we put the Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY + 10 minutes), just as a default for the case that the max response latency of any of the CoAP servers is unknown. (I.e. we don't impose a limit onto CoAP where there is none currently.) Then at the same time we could e.g. recommend that a CoAP server by default responds to multicast requests within MAX_SERVER_RESPONSE_DELAY = 5 minutes, again without forcing a limit for those cases where longer is needed.
Would that work for you?

Esko

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Wednesday, July 30, 2014 08:20
To: Rahman, Akbar
Cc: core WG; [email-masked]; Dijk, Esko
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

That seems sensible.  Personally I think it's just as good to say things like "IP multicasts requests are always Non-confirmable," instead of "An IP multicast request MUST be Non-confirmable," though both are OK.  I don't think the capitalized key words add anything there.

Barry

________________________________
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: Likepeng <[email-masked]>
Date: Wed, 30 Jul 2014 11:19:35 +0000

>We could say we put the Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY + 10 minutes), just as a default for the case that the max response latency of any of the CoAP servers is unknown. (I.e. we don’t impose a limit onto CoAP where there is none currently.)

10 minutes? Is it too long?

>Then at the same time we could e.g. recommend that a CoAP server by default responds to multicast requests within MAX_SERVER_RESPONSE_DELAY = 5 minutes, again without forcing a limit for those cases where longer is needed.

Why do we use 5 minutes for multicast requests while more than 10 minutes for Token reuse?

Thanks,

Kind Regards
Kepeng

发件人: core [mailto:[email-masked]] 代表 Dijk, Esko
发送时间: 2014年7月30日 18:31
收件人: Barry Leiba; Rahman, Akbar
抄送: [email-masked]; core WG
主题: Re: [core] AD review of draft-ietf-core-groupcomm-20

Hello Barry,

1- on the use of RFC2119 language in section 2.8 and 2.9: for some instances where this language is used, there is the same normative language in RFC7252 or RFC6690. So the text is there to recap these requirements to the reader.  Of course we can remove the capitals “SHOULD”->”should” but it may be less clear to the reader that there exists an RFC2119-level requirement on the topic.  I agree that the “REQUIRED” keywords can be removed in these sections since they can confuse.
(But perhaps there’s a better way to say for certain bullet items that they are not merely our recommendation but there are protocol requirements on it.)

2- on the upper bound for Token re-use ([Akbar-9] item): I remember discussions in CoRE in the past, always coming to the conclusion that there is no upper bound for server response time (similar to HTTP). We could say we put the Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY + 10 minutes), just as a default for the case that the max response latency of any of the CoAP servers is unknown. (I.e. we don’t impose a limit onto CoAP where there is none currently.) Then at the same time we could e.g. recommend that a CoAP server by default responds to multicast requests within MAX_SERVER_RESPONSE_DELAY = 5 minutes, again without forcing a limit for those cases where longer is needed.
Would that work for you?

Esko

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Wednesday, July 30, 2014 08:20
To: Rahman, Akbar
Cc: core WG; [email-masked]<mailto:[email-masked]>; Dijk, Esko
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

Barry

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 30 Jul 2014 11:50:50 +0000

Hi Kepeng,

> 10 minutes? Is it too long?

The NON_LIFETIME + MAX_LATENCY is already ~4 minutes anyway, so it could be at least something in the same order I think. In the 1-10 minutes range?

> Why do we use 5 minutes for multicast requests while more than 10 minutes for Token reuse?

The Token re-use time has to be longer than the MAX_SERVER_RESPONSE_DELAY at least, with some safety margin. Other proposals are welcome!

Esko

From: Likepeng [mailto:[email-masked]]
Sent: Wednesday, July 30, 2014 13:20
To: Dijk, Esko; Barry Leiba; Rahman, Akbar
Cc: [email-masked]; core WG
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

Thanks,

Kind Regards
Kepeng

发件人: core [mailto:[email-masked]] 代表 Dijk, Esko
发送时间: 2014年7月30日 18:31
收件人: Barry Leiba; Rahman, Akbar
抄送: [email-masked]<mailto:[email-masked]>; core WG
主题: Re: [core] AD review of draft-ietf-core-groupcomm-20

Hello Barry,

Esko

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 Jul 2014 20:02:22 -0400

Hey, Esko.

> 1- on the use of RFC2119 language in section 2.8 and 2.9: for some instances
> where this language is used, there is the same normative language in RFC7252
> or RFC6690. So the text is there to recap these requirements to the reader.
> Of course we can remove the capitals “SHOULD”->”should” but it may be less
> clear to the reader that there exists an RFC2119-level requirement on the
> topic.  I agree that the “REQUIRED” keywords can be removed in these
> sections since they can confuse.

I'm OK with your deciding what to keep and what not to, with respect
to the 2119 language in both of those sections.  What I'm asking is
that you look carefully at it, and address anything that's
inconsistent or unclear because of how the 2119 key words are used.

As I've pointed out, the traps usually come in using SHOULD when it's
not an issue of protocol interop, using combinations of key words that
wind up conflicting, and that sort of thing.  If you think it's best
to leave some 2119 language in there, and what you leave in is clear,
consistent, and unambiguous, I'm fine with that.

> 2- on the upper bound for Token re-use ([Akbar-9] item): I remember
> discussions in CoRE in the past, always coming to the conclusion that there
> is no upper bound for server response time (similar to HTTP). We could say
> we put the Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY +
> 10 minutes), just as a default for the case that the max response latency of
> any of the CoAP servers is unknown. (I.e. we don’t impose a limit onto CoAP
> where there is none currently.) Then at the same time we could e.g.
> recommend that a CoAP server by default responds to multicast requests
> within MAX_SERVER_RESPONSE_DELAY = 5 minutes, again without forcing a limit
> for those cases where longer is needed.
>
> Would that work for you?

Again, as I said, I'm looking for whatever guidance you can give
implementors, so they're not flying blind.  Even an explicit statement
that no guidance can be given is OK, I think, if that's really the
case.

So if you think that what you say above is reasonable guidance, and
it's the best you can give... let's go with it.  I appreciate that
discussions have been had, and I'm not trying to make the working
group revisit those incessantly.

Barry

---

From: Likepeng <[email-masked]>
Date: Thu, 31 Jul 2014 00:42:22 +0000

>Other proposals are welcome!

How about 4 and 4?

NON_LIFETIME + MAX_LATENCY + 4 minutes for token reuse, and 4 minutes for multicast requests.

Kind Regards
Kepeng

发件人: Dijk, Esko [mailto:[email-masked]]
发送时间: 2014年7月30日 19:51
收件人: Likepeng; Barry Leiba; Rahman, Akbar
抄送: [email-masked]; core WG
主题: RE: [core] AD review of draft-ietf-core-groupcomm-20

Hi Kepeng,

Esko

Cc: [email-masked]<mailto:[email-masked]>; core WG

Thanks,

Kind Regards
Kepeng

Hello Barry,

Esko

Barry

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 31 Jul 2014 03:16:19 +0200

A token cannot be reused as long as it's in use by either the client
or the server. CoAP does not include a mechanism for a client to
determine if a token is still in use by a server. (There are some
heuristics possible, but I don't trust them.) Simple solution to this
problem: Don't reuse tokens.

An implementation has to generate nonces for the security layer
anyway, so generating a new token for each request shouldn't be a
problem.

- Klaus

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 31 Jul 2014 13:40:52 +0000

Agree this is the simplest / safest solution in case the generation is not a problem. We can mention this solution in the draft as preferred solution that satisfies the requirement no matter what the latency is.

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Thursday, July 31, 2014 03:16
To: core WG
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

A token cannot be reused as long as it's in use by either the client or the server. CoAP does not include a mechanism for a client to determine if a token is still in use by a server. (There are some heuristics possible, but I don't trust them.) Simple solution to this
problem: Don't reuse tokens.

An implementation has to generate nonces for the security layer anyway, so generating a new token for each request shouldn't be a problem.

- Klaus

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 31 Jul 2014 14:22:36 -0400

> Agree this is the simplest / safest solution in case the generation is
> not a problem. We can mention this solution in the draft as preferred
> solution that satisfies the requirement no matter what the latency is.

I think a statement such as that would be exactly the kind of guidance
I'm looking for, and I'd be happy with it.

b