Subject: [core] CoRE RD update in SVN repository

From: Michael Koster <[email-masked]>
Date: Thu, 7 Jul 2016 15:54:09 -0700

I have uploaded an updated RD draft to the core SVN repository, with what I believe are all of the outstanding changes and comments.

draft-ietf-core-resource-directory-xx.mkd
draft-ietf-core-resource-directory-xx.xml
draft-ietf-core-resource-directory-xx.txt

The changelog describes the significant changes.

I will submit this as version -08 tomorrow if there are no urgent changes to make.

Best regards,

Michael

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 8 Jul 2016 01:54:55 +0000

Dear Michael

I did a quick review of the draft. I know you are quite swamped, but maybe we can get some updates in before publishing:

4.1.  Resource Directory Address Option (RDAO)

I am quite lost of the context here. There is only a quick hint in the bullet point list in Section 4---best add parentheses and "see ..." there. Otherwise it is unclear what kind of option you are talking about.

It is the only location where "6LR" is used without explanation. Furthermore, the endpoint could also be a 6LoWPAN host instead of a router...

Why is the length always 3? Is that right? (I haven't read the ND spec...)

5.  Simple Directory Discovery

This is still called "Discovery" although it is "Simple Registration".

It says "IP addresses of the directory server". I would change this to simply "addresses of the", since the endpoint also needs a port. The example later also shows a DNS name instead of IP literal.

5.2.  Third-party registration

The section mentions the Context parameter without reference to its definition.

6.2.  Discovery

This appears to be a repetition (with some additional information) of Section 4.  Finding a Directory Server.

I would integrate this into Section 4.

6.2. also uses the Content-Format ID 21225 without explaining what it is...

6.6.  Read Endpoint Links

Is there any functionality that is not provided through the lookup interface (apart from a quicker ep selection)?

As part of the RD evolution, a GET on the handle resource should primarily return the forms to update and delete the registration. Forms that are pre-filled with the endpoint information could enable a nice collection-based lookup for management.

6.7.  Update Endpoint Links

Shouldn't this be merged with Section 6.4. Registration Update?

Best regards
Matthias

________________________________
From: Michael Koster [[email-masked]]
Sent: Friday, July 08, 2016 12:54 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Kovatsch Matthias; Hannes Tschofenig; Oscar Novo; Zach Shelby; Carsten Bormann
Subject: CoRE RD update in SVN repository

Best regards,

Michael

---

From: peter van der Stok <[email-masked]>
Date: Fri, 08 Jul 2016 12:20:26 +0200

> Req: POST coap://rd.example.com/rd-group?gp=lights 		
> 
>    ct: 40
> 
I think it needs to be removed. It is not defined in the URI-template

---

From: peter van der Stok <[email-masked]>
Date: Fri, 08 Jul 2016 12:35:24 +0200

Hi Matthias,

> I did a quick review of the draft. I know you are quite swamped, but
> maybe we can get some updates in before publishing:

Thanks, there is one point where I can be useful.....

>  I am quite lost of the context here. There is only a quick hint in
> the bullet point list in Section 4---best add parentheses and "see
> ..." there. Otherwise it is unclear what kind of option you are
> talking about.

In the bullets of section 4 it is mentioned see section 4.1; I probably 
do not understand what you mean.

> 
> It is the only location where "6LR" is used without explanation.
> Furthermore, the endpoint could also be a 6LoWPAN host instead of a
> router...

Right, 6LR should be endpoint.

> Why is the length always 3? Is that right? (I haven't read the ND
The length does not change; and is fixed to 3 * 8 bytes. (standard ND)

cheerio,
Peter

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Jul 2016 06:39:02 -0700

That should be :

Content-Format: application/link-format

MIchael

> On Jul 8, 2016, at 3:20 AM, peter van der Stok <[email-masked]> wrote:
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Jul 2016 07:06:13 -0700

Hi,

comments below 
> On Jul 8, 2016, at 3:35 AM, peter van der Stok <[email-masked]> wrote:
> 
> Hi Matthias,
> 
> 
> In the bullets of section 4 it is mentioned see section 4.1; I probably do not understand what you mean.
> 

Fixed.

Also addressed some of Matthias comments

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Jul 2016 07:16:08 -0700

Here's another update. I went through and made the Content-Format options in the examplr consistent. The CoAP ecamples are Content-Format with numeric types where there is a type assigned, and the HTTP examples use Content-Type and a media type string. When referring to Content Formats in general, I use the string for human readability.

> On Jul 8, 2016, at 7:06 AM, Michael Koster <[email-masked]> wrote:
> 
> Hi,
> 
> comments below 
> <draft-ietf-core-resource-directory-xx.txt>

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Jul 2016 07:36:44 -0700

This is important for clients that can not process large payloads, to be able tp paginate the output.

It is meant to work like the common ?start=21&count=10 used for web pages.

I don't know why "page" and not "start". 

I could add some text and an example.

Michael

> On Jul 7, 2016, at 11:42 PM, Oscar Novo <[email-masked]> wrote:
> 
>          I provided you some comment about Page and count in the lookup some time ago. I think those two elements are extremely unclear and need to be explained better or removed.
> ·         What does the ct:40 means in the following example?
>

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Jul 2016 08:00:25 -0700

Update with pagination described and example

> On Jul 8, 2016, at 7:36 AM, Michael Koster <[email-masked]> wrote:
> 
>> On Jul 7, 2016, at 11:42 PM, Oscar Novo <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Jul 2016 08:22:41 -0700

I have addressed everything except these 2 comments:

> On Jul 7, 2016, at 6:54 PM, Kovatsch Matthias <[email-masked]> wrote:
> 
> 6.6.  Read Endpoint Links
What would be the content-format used to transmit the forms? I would expect GET on a collection with the content format of the resource to return a representation of the resource content, in this case the links in the collection. How should we indicate the hypermedia controls of the resource? I think we need to give this a little more thought, how to expose the controls of a resource vs. the content. 

In the meantime, the lookup interface could be used for inspection but the idea of having read and patch update as operations on the links of one endpoint seems useful for doing read-modify-write workflow on links. It's useful to use the same URI for the resource instead of having to construct a different address to read vs update.  Also I think discovery (lookup), modifying links, and registration refresh are logically separate workflows in the client.
> Shouldn't this be merged with Section 6.4. Registration Update?

See above reason based on separate workflows. Does it make sense?

Best regards,

Michael

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Jul 2016 08:32:02 -0700

couple more nits

> On Jul 8, 2016, at 8:22 AM, Michael Koster <[email-masked]> wrote:
> 
>> On Jul 7, 2016, at 6:54 PM, Kovatsch Matthias <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 6.6.  Read Endpoint Links

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Jul 2016 09:26:34 -0700

Candidate to submit.

> On Jul 8, 2016, at 8:32 AM, Michael Koster <[email-masked]> wrote:
> 
> couple more nits
> 
>> On Jul 8, 2016, at 8:22 AM, Michael Koster <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Oscar Novo <[email-masked]>
Date: Mon, 11 Jul 2016 07:06:02 +0000

Hi Michael,

Thanks for the answer. I think the blockwise transfer in CoAP method is already taking care of processing large payloads and fragmenting it.
I –somehow- understand some clients might want to limit the number of entries in a lookup to a certain number. Thus, they can limit the processing time of a lookup’s response.
However, I don’t really understand the use of the pagination if the blockwise method is already solving it. In addition, how does a client know how to fragment a request if it cannot know the outcome of a request? In many cases, the CoAP server will have to use blockwise anyway to fragment some of the paginations. I am not sure how to implement it once you have several pages. How do you handle the errors using this method? For instance, if one page is lost in the network. Are the pages sent in sequence? How does the client know the order of the pages? Are the pages enumerated?  How does the client inform the server that a page has been successful sent? I think there are many issues unsolved using this method. Issues that are already solve in the blockwise method.

I would rather remove the Page parameter and use the Count parameter as the maximum number of entries in a lookup response. Would that make sense?

Oscar

From: Michael Koster [mailto:[email-masked]]
Sent: Friday, July 08, 2016 5:37 PM
To: Oscar Novo
Cc: [email-masked]; [email-masked]; [email-masked]; Kovatsch Matthias; Hannes Tschofenig; Zach Shelby; Carsten Bormann
Subject: Re: CoRE RD update in SVN repository

Michael

On Jul 7, 2016, at 11:42 PM, Oscar Novo <[email-masked]<mailto:[email-masked]>> wrote:

         I provided you some comment about Page and count in the lookup some time ago. I think those two elements are extremely unclear and need to be explained better or removed.
•         What does the ct:40 means in the following example?