Re: [core] Questions on draft-ietf-core-resource-directory-12

Hi Jim,

thanks for the questions. Se my answers below.

Jim Schaad schreef op 2018-04-01 20:37:
> Here are some more questions on the document.
> 
> 1.  The registration text in section 5.3 says that the interface is
> idempotent, however it is not clear to me just how idempotent this is
> supposed to be.  It is obvious that the goal is to make sure that a
> different resource is not created, however I am not clear what is 
> supposed
> to happen with some of the parameters such as the 'lt' parameter.  One 
> way
> to implement this is to just make it a POST to the previously existing
> resource which would inherit old attributes on the endpoint.  The other 
> way
> is to say we are going to create a new resource, it just has the same
> address.  It is not clear which, if any, of these two methods is to be 
> used.
> 
> Never mind I found the answer to this one.  Need to think if I want 
> clearer
> language.

I hope we find the same answer.
The text says "registering with the same endpoint parameters , ep and d, 
does not create multiple resources.
Consequently, registering with existing ep and d removes existing 
registration and creates new registration with new location. Registering 
with a different ep and same d, or different d and same ep, creates new 
registration next to the existing one. The values of the other 
parameters are irrelevant.

is additional text like above needed?
> 
> 2.  When doing an endpoint lookup, I assume that the 'lt' parameter 
> would be
> the same as the one registered at creation.  Is there/should there be a
> parameter which is a TTL value?

I don't understand the question. TTL is about the lifetime of a packet 
in the network (expressed in hops)
lt is about the lifetime of the registration expressed in seconds
> 
> 3.  How are href comparisons done.
> 	a) compare against what was registered
> 	b) Resolve what was registered and the href in the current context
> and compare
> 	c) something I did not think of

probably someone else wants to react as well.
The model in the RD stores the target as specified in /.well-known/core 
of the source.
At lookup the links are resolved against con.
Consequently, the comparison of href is the comparison versus the target 
as stored in the RD and as copied from /.well-knwon/core.

Is that reasonable for you? needs extra text in the RD spec.?

> 
> 4.  compare on group for remote endpoint.  Should this do the remote 
> lookup
> or can it just be ignored for attribute comparison

I am not quite sure what you mean by attribute comparison.
When it is about registration attributes, no remote lookup seems 
necessary to me.

> 
> 5.  Value of lt = should it be the set parameter or the time left - how
> would time left be represented outherwise - should it be represented.

Right on the nail. This is very vaguely specified. The unit is specified 
as seconds.
In my expectation the returned lt value is the time in seconds from 
lookup till end.

Other opinions by my co-authors?  If we all agree, we specify it as such 
in the RD spec.
> 
> 6.  Inferred context based on source IP when an update is done.  If no 
> con
> is provided, is that supposed to be checked again to see if it is 
> "right"?
> Only if we did the infer to begin with?

My interpretation of the current text is:
When a  registration is done with the same ep and d values, the old 
registration is removed and
a new one with the new parameter values is created at a new location. 
That means that the value of con
is specified in the registration without any memory of earlier values.
> 
> 7.  I don't understand the presence of the content-format for the empty
> message posted for simple registration.  This seems to be odd if the 
> content
> is empty.

content-format is specified such that RD knows what content-format to 
request.
> 
> 8  Is there supposed to be a way for simple registration to return an 
> error
> message?  As written this is not necessarily done.  Specifically, the
> response to the post can be executed before the query to 
> /.well-known/core
> is done and the registration is attempted.

I see what you mean: also the return of 2.04 shows in the example but 
not in the specification.
This warrants additional text to specify the simple registration text.
> 
> 
Many thanks for these questions.
Looking forward to your answer,

Greetings,

peter
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core