Subject: [core] AD review of draft-ietf-core-groupcomm-20, part 1

From: Barry Leiba <[email-masked]>
Date: Fri, 25 Jul 2014 22:18:47 -0400

I have reviewed Sections 1 and 2 of draft-ietf-core-groupcomm-20, and
I have a lot of comments, so I wanted to get them to you now, while I
work on the rest of the document.  Please discuss these with me if you
need to (and some of them specifically ask you to), and tell me that
you think I'm wrong about any that you think that way about.

Barry, as AD

==========================

-- Section 1.3 --

   The above key words are used to establish a set of guidelines for
   CoAP group communication.  An implementation of CoAP group
   communication MAY implement these guidelines; an implementation
   claiming compliance to this document MUST implement the set of
   guidelines.

We don't do compliance, so let's please avoid saying this sort of
thing.  I think you can remove that whole paragraph.  If you want to
keep any of it, only the first sentence is appropriate.

-- Section 2.3 --

   A CoAP server that is a member of a group listens for CoAP messages
   on the group's IP multicast address, on a specified UDP port.  The
   default UDP port is the CoAP default port 5683 but a non-default UDP
   port MAY be specified for the group; in which case implementers MUST
   ensure that all group members are configured to use this same port.
   These rules imply that different ports (for the same IP multicast
   address) cannot be used to specify different CoAP groups.

This sounds to me like rather affected and unnecessary 2119 usage.
CoAP can always use a non-default port, and I don't see the point of
the MAY and the MUST.  Also, if the port defaults, it's because it's
*not* specified, so "specified UDP port" isn't right.

NEW
   A CoAP server that is a member of a group listens for CoAP messages
   on the group's IP multicast address, usually on the CoAP default UDP
   port, 5683.  If the group uses a specified non-default UDP port, be
   careful to ensure that all group members are configured to use that
   same port.  These rules imply that different ports for the same IP
   multicast address cannot be used to specify different CoAP groups.
END

   1.  A pre-configured port number.  The pre-configuration mechanism
       MUST ensure that the same port number is pre-configured across
       all endpoints in a group and across all CoAP clients performing
       the group requests.

Isn't that second sentence true for cases 2 and 3 as well (without the
"pre-configuration mechanism" bit)?  Shouldn't it be factored out?

NEW
   1.  A pre-configured port number.

   2.  If the client is configured to use service discovery including
       port discovery, it uses a port number obtained via a service
       discovery lookup operation for the targeted CoAP group.

   3.  Use the default CoAP UDP port (5683).

   For a CoAP server node that supports resource discovery, the default
   port 5683 MUST be supported (Section 7.1 of [RFC7252]) for the "All
   CoAP Nodes" group.  However the port number is selected, the same
   port MUST be used across all endpoints in a group and across all
   CoAP clients performing the group requests.
END

(That also adds a missing ")".)

The similar statement about using the same URI paths in the next
numbered list should probably be similarly factored out.

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?

-- 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?  Also, is that really a SHOULD there?  Or
have you listed the *only* exception?  Remember that SHOULD is close
to MUST, but gives the implementation some discretion.  There's a
difference between "You MUST do X except in case Q, where you do Y,"
and the same sentence with SHOULD (which allows the implementation to
choose not do X in other cases as well).  And really, I would
personally word this without the 2119 language:

NEW
   Group communication uses the CoAP methods GET, PUT, and DELETE in
   most cases.  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

-- Section 2.5 --

   Re-using a Token value too early could lead
   to protocol error i.e. a wrong response/request matching in the
   client. Therefore the time between re-use of Token values (for Token
   values used in multicast requests) must be at least:

I really find that awkward, mostly because of the poor use of "i.e."
there.  How about this?:

NEW
   Re-using a Token value too early could lead
   to incorrect response/request matching in the client, which is a
   protocol error. Therefore the time between re-use of Token values
   used in multicast requests must be at least:
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?

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

-- Section 2.7.2 --

   To access this interface a client MUST use
   unicast CoAP methods (GET/PUT/POST/DELETE) only as it is a method of
   configuring group information in individual endpoints.

I had trouble parsing this and understanding it, until I realized that
you need a comma after "only".

   Also, a form of authorization (making use of DTLS-secured CoAP
   [RFC7252]) SHOULD be used such that only authorized controllers are
   allowed by an endpoint to configure its group membership.

Authorization SHOULD be used?  "SHOULD", really, not "MUST"?  How is
this not "MUST"?

   These
   alternate approaches may support

Nit: "alternative" is the correct word here.

-- Section 2.7.2.1 --

   The resource includes zero or more group
   membership JSON objects

You should add a normative reference to RFC 7159 for JSON.

   group membership JSON object contains one or more key/value pairs as
   defined below.

Your "key/value pairs" are actually JSON object members, where the
member name is they key and the member value is the value.  It would
probably be better to explain that explicitly, because JSON has no
concept of "key/value pairs" by that name.  Perhaps this works:

NEW
   A
   group membership JSON object contains one or more key/value pairs as
   defined below, and represents a single IP multicast group membership
   for the CoAP endpoint.  Each key/value pair is encoded as a member
   of the JSON object, where the key is the member name and the value
   is the member's value.
END

   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.

   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?
The MUST NOT: Really?  How *would* you include it if it's unknown?
The second SHOULD: This is very clearly a MUST, according to the
following paragraph (if you don't have an "a", you MUST have an "n").

In addition:
I suggest that you move the "at least one of" sentence to the
beginning of this paragraph (and change "group object" to "group
membership object" for consistency).  I also think it's important for
you to explain what happens when both "a" and "n" are included.  And I
don't think you have to have the sentence about the default port
number twice.

-- Section 2.7.2.2 --

     index - Group index, SHOULD be a string of 1 or 2 alphanumerical
       characters. It MUST be generated as locally unique.

What is the scope of "locally"?  Unique on the server?  Unique in the
group?  Something else?

1 or 2 alphanumeric characters: (we don't usually put "al" at the end)
What characters are valid?  In what character set?  Do you mean ASCII
alphanumeric characters?  If so, please say that.  Are they
case-sensitive (are "a1" and "A1" the same, or different)?

Why is this a SHOULD?  What happens if it's not 1 or 2 alphanumeric characters?

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?

   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?

   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?

-- Sction 2.7.2.4 --

   A (unicast) GET on the CoAP-group resource returns a JSON object
   containing multiple keys and values, the keys being group indices and
   the values the corresponding group objects.  Each group object is a
   group membership JSON object that indicates one IP multicast group
   membership.

Again, let's be clear how the keys and values map to JSON.  Let's also
fix terminilogy consistency, "group objects" -> "group membership
objects", and as the term has been defined before, you don't have to
do it again:

NEW
   A (unicast) GET on the CoAP-group resource returns a JSON object
   containing multiple keys and values. The keys (member names) are
   group indices and the values (member values) are the corresponding
   group membership objects.  Each group membership object describes
   one IP multicast group membership.
END

   URI Template Variables:
     gp - see earlier definition

I think it would be better to point to exactly where the earlier
definition is.  Happily, xml2rfc makes that easy, with an <xref/>
element (and make similar changes below, in sections 2.7.2.5, .6, and
.7).

NEW
   URI Template Variables:
     gp - see definition in Section 2.7.2.2
END

   Note: the returned IPv6 address may be a different string from the
   one originally submitted in group membership creation, due to
   different choices in IPv6 string representation formatting that may
   be allowed for the same address (see [RFC5952]).

I think it would help to be explicit, just to avoid any confusion,
that even though it might not be the same character string, it
represents the same IPv6 address.  Maybe this:

NEW
   Note: the returned IPv6 address string will represent the same
   IPv6 address that was originally submitted in group membership
   creation, though it might be a different string because of
   different choices in IPv6 string representation formatting that
   may be allowed for the same address (see [RFC5952]).
END

What happens if the requested index doesn't exist?  Do you get an
error?  Or do you get the empty JSON object?  (Same question for
Section 2.7.2.5.)

-- Section 2.7.2.5 --
Just a comment, to take or leave as you see fit (no need to respond):
It seems to me that there might be an advantage in having both GET
methods return the same structure, so they can be parsed the same way.
If you did that, the example in this section would read this way:

   Example:
     Req: GET /coap-group/12
     Res: 2.05 Content
          Content-Format: application/coap-group+json
       { "12" :{"n": "All-Devices.floor1.west.bldg6.example.com",
                "a": "[ff15::4200:f7fe:ed37:abcd]:4567"}
       }

-- Section 2.7.2.6 --

   This operation SHOULD only be used
   to delete or update group membership objects for which the CoAP
   client, invoking this operation, is responsible.  The responsibility
   is based on application level knowledge.

Again: Why "SHOULD"?  When it is safe to ignore the SHOULD?  What
happens if I ignore it?

And: Are there no access controls here?  Isn't an entity that
shouldn't be fiddling with group membership *prevented* from doing so?
 Or could a faulty (or malicious) device or tool really clear out all
the group memberships?

   Example: (replacing all existing group memberships with two new
   groups)

Two new *groups*?  Or two new *members*?

I'm also confused here: When I use POST to create a group membership,
the server returns the index -- the server tells the client the index.
In this case, the client selects the indicies.  Is that really what
you want?  And if so, are there any constraints on that?  In the
example, you show them as sequential numbers starting at 1.  If they
can be arbitrary, it might be better to change the example to make
them, say "QX" and "5", just to be clear that it doesn't matter.

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

-- Section 2.9 --

   o  A response to an IP multicast request SHOULD be Non-confirmable
      (Section 5.2.3 of [RFC7252]).

I take from the reference to Sec 5.2.3 that what you're really saying
here is that responses follow the normal CoAP rules, and you're not
giving advice that differs from that at all.  Do you mean otherwise?
You should probably say that, as, "As is usual with Non-confirmable
requests, a response to...."

   o  A server does not respond immediately to an IP multicast request,
      but SHOULD first wait for a time that is randomly picked within a
      predetermined time interval called the Leisure.

Unfortunately, in English, "but" has two different meanings:
contradiction (as Spanish "pero") and alternative (as Spanish "sino").
You mean the Spanish "sino" here, but it will likely be read as the
Spanish "pero" (sorry to refer to Spanish, but this is hard to
explain).  I suggest changing "but" to "and" or "but rather", to make
the sense clear (I prefer "and").

   o  A server in an LLN should only support group communication GET for
      resources that are small.  For example, the payload of the
      response is limited to approximately 5% of the IP Maximum Transmit
      Unit (MTU) size so it fits into a single link-layer frame in case
      6LoWPAN [RFC4944] is used.

What's the purpose of the 6LoWPAN reference?  If it's to talk about
the MTU, then 4944 is a fine reference, but I would give a section
reference to make it clear: "in case 6LoWPAN is used (see Section 4 of
[RFC4944])."  But if the purpose is to have a more general explanation
of what 6LoWPAN is, I think RFC 4919 is a better reference for this
case.  Up to you; I just wanted to raise the question.

   o  A server can also minimize the payload length of a response to a
      group communication GET (e.g., on "/.well-known/core") using CoAP
      blockwise transfers [I-D.ietf-core-block], returning only a first
      block of the CoRE Link Format description.  For this reason, a
      CoAP client sending an IP multicast CoAP request to "/.well-known/
      core" SHOULD support core-block.

I believe the "SHOULD support" makes core-block a normative reference.

   More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944]
   are given in Section 4.5.

I'm pretty certain that for this reference, 4919 is better than 4944.

-- Section 2.10 --

   Due to above issues, a guideline is defined here that a CoAP Proxy
   SHOULD NOT support processing an IP multicast CoAP request but rather
   return a 501 (Not Implemented) response in such case.  The exception
   case here (i.e., to process it) is allowed under following
   conditions:

It's not clear whether *all* of the following conditions must be met,
or whether *any* of the following conditions must be met.

==========================

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 27 Jul 2014 01:48:07 -0400

Hi Barry,

1) First, thank you very much for your thorough review.  I agree with
many of your suggestions.  I  have given point by point feedback inline
below (identified by: **[Akbar-x]).  

2) Can you please specifically look and respond to the proposals in: 
[Akbar-5], [Akbar-6], [Akbar-10], [Akbar-11], [Akbar-16], [Akbar-17],
[Akbar-24], [Akbar-25], [Akbar-26], [Akbar-32], [Akbar-34], [Akbar-35],
[Akbar-36] and [Akbar-39].

3) We will do a fast update of the draft once we have agreement with you
on all your comments in this and your second email.

Best Regards,

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Friday, July 25, 2014 10:19 PM
To: [email-masked]
Cc: core WG
Subject: [core] AD review of draft-ietf-core-groupcomm-20, part 1

I have reviewed Sections 1 and 2 of draft-ietf-core-groupcomm-20, and I
have a lot of comments, so I wanted to get them to you now, while I work
on the rest of the document.  Please discuss these with me if you need
to (and some of them specifically ask you to), and tell me that you
think I'm wrong about any that you think that way about.

Barry, as AD

-- Section 1.3 --

We don't do compliance, so let's please avoid saying this sort of thing.
I think you can remove that whole paragraph.  If you want to keep any of
it, only the first sentence is appropriate.

**[Akbar-1] - Ok.  Then it is probably cleanest to just delete the whole
paragraph as the preceding RFC2119 paragraph is the standard
requirements terminology.

-- Section 2.3 --

This sounds to me like rather affected and unnecessary 2119 usage.
CoAP can always use a non-default port, and I don't see the point of the
MAY and the MUST.  Also, if the port defaults, it's because it's
*not* specified, so "specified UDP port" isn't right.

NEW

**[Akbar-2] - Ok.  Your re-wording definitely captures our original
intent.  I am fine with it if you think that the RFC2119 usage is not
necessary.  We will update as you suggested.

NEW

**[Akbar-3] - Ok.  Our original thinking was that case 2 was slightly
different as the assumption was that all clients would use the same
service discovery mechanism so that the "pre-configuration mechanism"
would be enforced in a slightly different way.  But if we remove that
term, then your proposal is good.  We will update as  you suggested.

**[Akbar-4] - Ok.  We will update as you suggested.

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?

-- Section 2.4 --

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?

Also, is that really a SHOULD there?  Or have you listed the *only*
exception?  Remember that SHOULD is close to MUST, but gives the
implementation some discretion.  There's a difference between "You MUST
do X except in case Q, where you do Y,"
and the same sentence with SHOULD (which allows the implementation to
choose not do X in other cases as well).  And really, I would personally
word this without the 2119 language:

NEW

**[Akbar-7] - I am okay with this (i.e. in removing the RFC2119
language).  We will update as you suggested.  (Note that the text may
change based on how you answer [Akbar-6] above).

-- Section 2.5 --

NEW

**[Akbar-8] - Ok.  We will update as you suggested.

   Using the CoAP

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.

-- Section 2.6 --

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?

-- Section 2.7.2 --

**[Akbar-11] - How about rephrasing as follows to make it more readable:

NEW
  To access this interface a client MUST use unicast CoAP methods
(GET/PUT/POST/DELETE). 
  This interface is a method of configuring group information in
individual endpoints.
END

**[Akbar-12] - Ok.  We will update as you suggested.

   These

**[Akbar-13] -Ok.  We will update as you suggested.

-- Section 2.7.2.1 --

**[Akbar-14] - Ok.  We will update as you suggested.

NEW
   A

**[Akbar-15] - Ok.  We will update as you suggested.

NEW

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

More 2119 follies...

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

**[Akbar-18] - Ok.  Will just delete the phrase "... and MUST NOT be
included if unknown" as it is not required.

**[Akbar-19] - Ok.  We will update as you suggested.

In addition:
I suggest that you move the "at least one of" sentence to the beginning
of this paragraph (and change "group object" to "group membership
object" for consistency).  I also think it's important for you to
explain what happens when both "a" and "n" are included.  And I don't
think you have to have the sentence about the default port number twice.

**[Akbar-20] - Ok.  We will update as you suggested.

-- Section 2.7.2.2 --

**[Akbar-21] - Locally means unique to the server.  We will clarify to:
"It MUST be generated as locally unique to the server".

**[Akbar-22] -Yes,  we meant case insensitive ASCII alphanumeric
characters.  We will update to clarify.

Why is this a SHOULD?  What happens if it's not 1 or 2 alphanumeric
characters?

**[Akbar-23] -We can make it a MUST.

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

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

   If only the "n" pair is

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

-- Sction 2.7.2.4 --

Again, let's be clear how the keys and values map to JSON.  Let's also
fix terminilogy consistency, "group objects" -> "group membership
objects", and as the term has been defined before, you don't have to do
it again:

NEW

**[Akbar-27] -Ok.  Will update as you suggested.

   URI Template Variables:

NEW
   URI Template Variables:

**[Akbar-28] -Ok.  Will update as you suggested.

I think it would help to be explicit, just to avoid any confusion, that
even though it might not be the same character string, it represents the
same IPv6 address.  Maybe this:

NEW

**[Akbar-29] -Ok.  Will update as you suggested.

What happens if the requested index doesn't exist?  Do you get an error?
Or do you get the empty JSON object?  (Same question for Section
2.7.2.5.)

**[Akbar-30] -Probably best to return an empty JSON object.  We can
clarify this in the text.

-- Section 2.7.2.5 --

   Example:
     Req: GET /coap-group/12
     Res: 2.05 Content

**[Akbar-31] -Ok.  This is a good idea.  Will update as you suggested.

-- Section 2.7.2.6 --

And: Are there no access controls here?  Isn't an entity that shouldn't
be fiddling with group membership *prevented* from doing so?
 Or could a faulty (or malicious) device or tool really clear out all
the group memberships?

**[Akbar-32] -First, as per reply [Akbar-12] the transaction will be
DTLS protected.  Secondly, we can change the "SHOULD" to "MUST" to make
it mandatory.

**[Akbar-33] - We can clarify to two new "group memberships".

I'm also confused here: When I use POST to create a group membership,
the server returns the index -- the server tells the client the index.
In this case, the client selects the indicies.  Is that really what you
want?  And if so, are there any constraints on that?  In the example,
you show them as sequential numbers starting at 1.  If they can be
arbitrary, it might be better to change the example to make them, say
"QX" and "5", just to be clear that it doesn't matter.

**[Akbar-34] -We used the given approach just to keep everything simple.
As we discussed in reply [Akbar-21], the index is unique to the server.
We can change the example to make non-sequential index numbers as you
suggest.

-- Section 2.8 --

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.

      Note that in this

**[Akbar-35] - Please first note that this document (groupcomm) is
Informational.  As we stated in section 1.2 (Scope), the normative
aspects of group communications is specified in RFC7252 (e.g.
http://tools.ietf.org/html/rfc7252#section-8 and some of the congestion
control guidance scattered elsewhere in RFC7252).  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.  Assuming that you agree with
this, 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).

-- Section 2.9 --

**[Akbar-36] - Yes, we are not differing from normal CoAP rules anywhere
in this document in fact.  That is why the document is Informational.
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.

Unfortunately, in English, "but" has two different meanings:
contradiction (as Spanish "pero") and alternative (as Spanish "sino").
You mean the Spanish "sino" here, but it will likely be read as the
Spanish "pero" (sorry to refer to Spanish, but this is hard to explain).
I suggest changing "but" to "and" or "but rather", to make the sense
clear (I prefer "and").

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

What's the purpose of the 6LoWPAN reference?  If it's to talk about the
MTU, then 4944 is a fine reference, but I would give a section reference
to make it clear: "in case 6LoWPAN is used (see Section 4 of
[RFC4944])."  But if the purpose is to have a more general explanation
of what 6LoWPAN is, I think RFC 4919 is a better reference for this
case.  Up to you; I just wanted to raise the question.

**[Akbar-38] - The main reason was to talk about MTU.  We can add the
section reference as you suggested.

**[Akbar-39] - Since that was not our intent, we will change the text to
use non-RFC2119 language.

**[Akbar-40] - Ok.  Will change as you suggested.

-- Section 2.10 --

It's not clear whether *all* of the following conditions must be met, or
whether *any* of the following conditions must be met.

**[Akbar-41] - Should be "all" the conditions.  We will clarify the text
to reflect this.

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