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

["Rahman, Akbar" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Barry Leiba
Sent: Monday, July 28, 2014 2:17 PM
To: Rahman, Akbar
Cc: core WG; [e-mail]
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:

> -- 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.



**[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?





> 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.



**[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?




> -- 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


**[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?




>    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.


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




> -- 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.


**[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?




>    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



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





>    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?



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



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?


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




> 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.



**[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




>    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


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





>    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


**[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?



> -- 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.



**[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?





> **[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.



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


Barry