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

Hi JIm,

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

> * 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.
> 
> 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?
> 
> * 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.  
> 
> 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.
> 
> * 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.
> 
> only hrefs of registration resource; I am undecided on this; what about ct unequal 40
> 
> * Section 5.3 - Is it a bad request if there is a 'base' in the content?
> 
> Can you explain?
> I suspect in the payload things like:
> </sensors/temp>;base=my-ip
> 
> * 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.
> 
> May be you want to look at appendix A? management of registrations has been placed in the appendix.
> 
> *  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 
> 
> 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
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core