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

[peter van der Stok <[e-mail]>]

Hi Jim,

some additional questions and remark,

>> > 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.
> 
> I believe that if you register with existing ep and d, it will remove 
> the
> existing registration and create a new registration with the SAME 
> location.
> This is part of being idempotent.
> 
> I agree w/ the endpoint/d mismatch.

Idempotency says that applying the same operation multiple times should 
lead to the same result independent of the number of times.
The problem is: what is the same operation; If only ep and d are 
relevant then applying multiple times an operation (registration) with 
the same ep and d values indeed leads to the same result ignoring all 
other attribute values (including location)

If one says that the same operation implies that all other specification 
parameters are unchanged, then indeed location should not be changed in 
that case.

What view do you adhere to?

And do you suggest we should insert clarifying text?


>> >
>> > 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.
> 
> If I do the lookup of
> /rd/gp-lookup?rt=foobar
> 
> And one of the groups has the following
> 
> /rd-group/xxx
> https://otherrd/rd-group/yyy
> 
> I would follow the local group definition to find out if the resource 
> type
> is defined on some resource in the group, however the question is do I 
> need
> to go and query the other group which is not local in order to do the 
> same
> tree walking when doing attribute comparisons.  Not that this applies 
> to
> remote endpoint registrations in a group as well.

Thanks for the example.
Indeed following the latest text, the comparison should include the 
remote registration.

The text could include words like tree walking is done locally only; 
personally I would not be too happy about that.
Apparently the text should say something about remote groups and tree 
walking. I will add the issue to github.
> 
>> 
>> >
>> > 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.
> 
Also an issue for github to get more reactions
> 
>> >
>> > 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.
> 
> This is not the sequence that I was looking for.
> 
> POST /rd?ep=node1
>    - payload contains the set of resources the register.
>    - returns a location of /rd/yyyy
> 
> POST /rd/yyyy?ep=node1
>    - payload is empty.
> 
> In the first post, the rd will infer a context based on how the 
> registration
> is done.  The second post just says that the TTL value is to be 
> refreshed
> back to the life-time value.  However, the inferred context could also 
> be
> changed.

Thanks for the example; it would take me long to figure this out 
otherwise.

Reading the update specification, the ep=node1 is illegal in the update. 
Specifying ep means creating a new registration.

sending the update
POST /rd/yyy will update the lt value.
It is allowed to change the value of con in the update POST 
specification.
The question is:
When an updating ep, different from the registering one, sends the 
update of lt, does the context change to the hosts relation value of the 
updating ep.

My gut reaction is no. it does not change the context value in the RD 
because that needs an explicit ?con= in the update specification.

A warning in the RD text to this effect looks reasonable.
> 
> 
>> >
>> > 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.
> 
> Would accept be a better option to use?  This would allow for more than 
> one
> value to be specified.

Agree.
> 
>> >
>> > 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.
>> >
>> >

will add the simple registration template to the text.

many thanks for your additional explanations.
One issue of idempotency is left.

Peter