Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Tue, 17 Dec 2013 23:37:46 +0000

Hi Akbar, Esko,

thanks for the quick and rich response.  I’m cutting the comments that you
agreed to address, and focus on the remaining bits.  BTW, your inline
comments provide a lot of good stuff that would be nice to see in the
final version of the document.

On 17/12/2013 19:49, "Rahman, Akbar" <[email-masked]> wrote:
>>Section 1.1
>>
>>- httpbis has been sent to IESG for publication, I guess it's ok to
>>reference it instead of 2616;
>[AKBAR] I THINK IT IS SAFER FOR US TO REFER STILL TO RFC 2616 FOR NOW.
>OUR LOGIC IS AS FOLLOWS - IF THE HTTPBIS DOCUMENTS (E.G.
>http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/ ) GET
>PUBLISHED IN TIME, THEN THE RFC EDITOR WILL AUTOMATICALLY CHANGE THE
>REFERENCE IN THIS DOCUMENT (AS THE NEW DOCUMENTS WILL OBSELETE RFC 2616).
> ALSO THERE IS A SET OF 5 DOCUMENTS REPLACING 2616 SO WE ARE NOT SURE
>WHAT CONVENTION THE RFC EDITOR WILL USE (I.E. WILL THEY REFERENCE ALL 5
>DOCUMENTS OR ONLY THE FIRST?).

IIRC at some point in time there was a “Part 0” document floating around
HTTPbis, which provided a single reference point for the whole docs set.
I’ve searched briefly in http://datatracker.ietf.org/wg/httpbis/ but I
can’t find it anymore.  Agreed to let the RFC Editor adjust the reference
as needed.

>>- fifth para: is the "It is recommended" meant to be RFC2119?
>[AKBAR] WE PREFER TO LEAVE IT AS NON RFC 2119.  REASON - IT HAS NO IMPACT
>ON INTEROPERABILITY AS THE PROCESS DESCRIBED HAPPENS INSIDE A SINGLE COAP
>CLIENT THAT OPTIONALLY CONTACTS A NON-COAP AWARE DNS SERVER.  THE
>RECOMMENDATION SERVES HERE TO MAKE THIS PROCESS MORE EFFICIENT BY
>SKIPPING THE DNS RESOLUTION STEP, WHENEVER POSSIBLE.  ALSO, THE WG
>INDICATED THAT DNS RESOLUTION OF IP MULTICAST ADDRESSES MAY OFTEN NOT BE
>DEPLOYED (AT LEAST INITIALLY).

OK.

>>- last para: not clear what the use case for the reverse DNS mapping
>>would be.
>[AKBAR] REVERSE DNS MAPPING MAY OCCUR DURING AN AUDIT/INSPECTION OF A
>BUILDING CONTROL SYSTEM.  AN AUTHORIZED COAP CLIENT (E.G. LOCAL
>COMMISSIONING TOOL OR DIAGNOSTICS NODE ON THE IP NETWORK) USES THE
>RESTFUL INTERFACE (SECTION 2.7.2) TO RETRIEVE GROUP MEMBERSHIP (IP
>MULTICAST ADDRESS) OF A NUMBER OF NODES.  THEN IT USES REVERSE DNS
>MAPPING TO TRANSLATE THESE BACK TO HUMAN-READABLE HOSTNAMES, TO SHOW IN
>THE DIAGNOSTICS UI.

Excellent.  Would you mind adding the use-case described above to the
current text?

>>Section 2.3
>>
>>- isn't bullet 3. (i.e. use the default CoAP port) just a special case
>>of 1. (i.e. pre-configured port number)?
>[AKBAR] YES, BUT IT IS CLEARER TO LEAVE THEM AS SEPARATE CASES AS THE
>DEFAULT IS A SPECIAL VALUE THAT SHOULD BE EXPLICITLY CALLED OUT.

OK.
(Looking at it with my implementer specs on I was seeing a config file
providing static settings, shipping with the port-number variable having a
pre-canned 5683 value.)

>>- second para: the "Thus only authorized controllers [...]" is not clear
>>to me: it seems to imply that DTLS provides authorisation, which it
>>doesn't.
>[AKBAR] (COMMENT IS TO 2.7.2).  THIS SEEMS TO GET INTO THE WHOLE QUESTION
>OF ACL BEING RAISED IN
>http://www.ietf.org/mail-archive/web/ace/current/msg00049.html .  BUT
>PERHAPS WE CAN JUST CHANGE THE SENTENCE TO: "PREFERABLY A FORM OF
>AUTHORIZATION (MAKING USE OF DTLS AUTHENTICATION) IS IMPLEMENTED AS WELL,
>SUCH THAT ONLY AUTHORIZED CONTROLLERS ARE ALLOWED BY AN ENDPOINT TO
>CONFIGURE ITS GROUP MEMBERSHIP".

Sounds good.

>>Section 2.7.2.3
>>
>>- the "/" in  "/{+location}" looks redundant
>>- would be nice to have text that describes the actions that are to be
>>done by the server on successful deletion
>>Section 2.7.2.4
>>
>>- the "/" in  "/{+location}" looks redundant
>[AKBAR] THIS WAS TAKEN FROM CORE-RESOURCE-DIRECTORY-00 SO WE WILL KEEP IT
> UNLESS THEY CHANGE AS WELL.

Ah, OK.  Anyway, with URI-templates, if you have a variable 'location'
populated by a Location-Path Option like this:

  location := '/coap-group/12'

And an associated URI-template like this:

  /{+location}

Then the expansion would be:

  //coap-group/12

>>Section 2.8
>>
>>- It is said that the response suppression should be configurabile,
>>which is great.  But then why not allowing this via the "Group
>>Membership RESTful Interface"?
>[AKBAR] WE SPECIFICALLY KEPT THE GROUP MEMBERSHIP INTERFACE TO ONLY
>DEFINE THE NAME AND IP ADDRESSES OF THE GROUP.  IF WE OPEN IT UP TO OTHER
>PARAMETERS THEN IT WILL GET UNWIELDLY.

OK.  Agreed this is not the right timing for a comment like this.  I
should have done it pre-WGLC :-)

>>Section 2.10
>>
>>- shameless plug: the "Multipart Content-Format Encoding for CoAP" I-D
>>could provide the aggregation format needed ;-)
>[AKBAR] NICE PROPOSAL, BUT THE MULTIPART FORMAT IF  USED FOR GROUPCOMM
>WOOULD ALSO HAVE TO ENCODE THE IDENTITIES (IP ADDRESSES) OF THE
>INDIVIDUAL SERVERS THAT PROVIDE EACH RESPONSE.  SO IT IS NOT 100%
>SUITABLE YET.  DO YOU AGREE?

Multipart is recursive, so you could have an inner multipart which
aggregates the per-response attributes (i.e. identifier/locator of the
sender, CoAP payload), and an outer multipart providing the list/set that
gathers all the responses together.

Cheers, Thomas.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 18 Dec 2013 12:24:31 -0500

Hi Thomas,

>Multipart is recursive, so you could have an inner multipart which aggregates the per-response attributes (i.e. identifier/locator of the sender, CoAP payload), and an outer multipart providing the >list/set that gathers all the responses together.

Our proposal is that we can change the following in our Section 2.10 (Proxy Operation).  This would be similar to our Section 5.3.3 (Security Future Evolution).

FROM:
     "There is no default format defined in CoAP for aggregation of
      multiple responses into a single response."

TO:

     "There is no default format yet adopted in CoAP for aggregation of
      multiple responses into a single response.  However, some proposals are being considered such as fossati-core-multipar-ct."

Please tell us if you have any further comments.

/Akbar & Esko