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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: peter van der Stok <[e-mail]>
> Sent: Wednesday, April 4, 2018 2:21 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; 'core' <[e-mail]>
> Subject: 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.

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.

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

In this case, TTL would be the number of seconds until the registration
expires.   I have seen TTL used in non-packet situations to describe the
exact same thing - how long is this going to be alive.  I have debated using
the smallest TTL value when I return a result as the option Max-Age, but
that does not quite mesh with how that option is defined.

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

This is how I read the current text, but it was not the only possible
answer.  If the answer is not b, then I don't think extra text is needed.

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

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

This is a dup of the TTL question above.  Sorry that I missed that.

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


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

> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/core