Subject: [core] draft-ietf-core-resource-directory

From: Jim Schaad <[email-masked]>
Date: Sun, 26 Aug 2018 13:23:34 -0700

* The term registree-ep is in the document.  This is not a word that I can
find.  I think what you want to say is registrant-ep.

* Section 5.3 - there is a statement that the endpoint name must be unique
within a sector.  I cannot think of any way that this can be enforced by an
RD.  

* Section 6.1 - I am trying to decide if there should be a sentence that
says that only the href is allowed in the body.  Any other properties are
either ignored or an error.

* Section 5.3 - Is it a bad request if there is a 'base' in the content?

* Section 5.3 - We seem to have lost the following operations.  Is this
intentional?  Cannot do a get, post or delete to an endpoint.  I probably
only care about the last as the other two are doable in other ways.

*  I cannot figure out where the base that is assigned in a group would be
used.  For group lookup it would not make any sense as you are returning
endpoints on the RD.  For endpoint lookup again we return pointers to the
RD.  For resource lookups I would expect it to return everything relative to
the base of the endpoint.  It would appear that there is no longer a GET on
/rd/groups 

Jim

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 27 Aug 2018 09:56:46 +0200

Hi JIm,

thanks for the questions.
some quick reactions to some of your comments
Jim Schaad schreef op 2018-08-26 22:23:

> An endpoint can be both a registrant-ep and a being-registered-ep;
> With RD an endpoint can only be a being-registered-ep
> I thought that being-registered-ep <=> registree-ep
> Looked it in vain up in dictionary; What is the correct term here?
> 
> Suppose there are registration with the same sector and endpoint name, How do you distinguish them?
> In 5.3 the registration procedure to create unique (endpoint name, sector) pairs is described.
> Why can this not be enforced? The RD can check all pairs before going to the act of registering.
> 
> only hrefs of registration resource; I am undecided on this; what about ct unequal 40
> 
> Can you explain?
> I suspect in the payload things like:
> </sensors/temp>;base=my-ip
> 
> May be you want to look at appendix A? management of registrations has been placed in the appendix.
> 
> Appendix A.5 might be useful.
> 
> Jim
> 
> I am afraid the separation of management to the appendix A has provoked many of your questions.
> W thought that separating management from registration and lookup would clarify the differences between registration resources and registered resources.
> 
> Peter
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Jim Schaad <[email-masked]>
Date: Mon, 27 Aug 2018 09:15:20 -0700

From: Peter van der Stok <[email-masked]> 
Sent: Monday, August 27, 2018 12:57 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; 'core' <[email-masked]>
Subject: Re: [core] draft-ietf-core-resource-directory

Hi JIm,

[JLS]  Registrant refers to “One that registers or is registered” This is the closest work I know to that would reference to an entity currently being registered.  I would probably use registrant if I thought about it.

[JLS] The text also says that if a get a new registration request with a sector and endpoint name, that the RD is supposed to replace the current existing registration.  My code can validate that the registrar is permitted to do the registration, but not that the ep/d pair are unique and refer to the same entity.

[JLS] My original thought was that it should be only a list of hrefs, but that is not explicitly stated.  Then I thought that it might be useful to potentially add some of the DNS type properties to a group list such as “priority” to indicate which servers in a group would be preferred over others.

Can you explain?

[JLS] Yes that is the type of thing that I had in mind.  The issue is that while the base as a uri-query applies to the whole group this would apply to only the one line.  It would make more sense to require that it be registered as

<coap://my-ip/sensors/temp>;ct=40

[JLS} I totally missed that – I never read appendixes as a general rule.  They are appendixes and thus are designed to be ignored.  “Appendix – supplementary material usually attached at the end of a piece of writing”.  This does not sound very supplementary to me.

[JLS] See above answer.  I was really kind of expecting to be able to do a query along the lines of “Return the resources in a group” and get back something along the lines of the list of resources resolved against the base address of the group if one exists and against the base address of the endpoint if it does not.  Current resource lookups always resolve against the endpoint.

Jim

[JLS] I don’t object to the separating of these concepts.  I object to them being in an appendix.  I can now go back and continue making sure my implementation is correct according to the spec.

Jim

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Aug 2018 21:02:59 +0100

That does not work so well for ietf documents, where appendices can be and often are normative. 

Sent from mobile

> On 27. Aug 2018, at 17:15, Jim Schaad <[email-masked]> wrote:
> 
> I never read appendixes as a general rule.  They are appendixes and thus are designed to be ignored.