Subject: [core] Questions and comments against the github version

From: Jim Schaad <[email-masked]>
Date: Mon, 10 Dec 2018 18:22:48 -0800

*  In section 5.3, I don't understand why the rule exists that if the
attribute values are different then the location of the registration needs
to be changed.   It seems that this could lead to some interesting conflicts
in behavior depending on what messages are used.  For example  (content
omitted for clarity):

POST /rd?ep=e1&foo=over

Res: 2.01 Created
Location-Path: /rd/4001

POST /rd?ep=e1&foo=under

Res: 2.01 Created
Location-Path: /rd/4002

As opposed to:

POST /rd?ep=e1&foo=over

Res: 2.01 Created
Location-Path: /rd/4001

POST /rd/4001?foo=under

Res: 2.01 Changed

*  In Section 5.3 - What is the correct behavior if the RD is configured to
recognize an endpoint, but the endpoint supplies a different name?  Is this
an error or does one of them override?

* In section 5.3.1 - I assume it would be an error to include the base
attribute - perhaps this should be explicit?

* In section 5.3.1 - When doing simple registration, I do not believe that
it should be a requirement that the result MUST be returned prior to doing
the query.  This allows for situations where the EP believes itself to be
registered when in fact is is not because the query to /.well-known/core
failed for some reason.  Additionally, the EP no longer has a cue as to when
it can shut down because it does not know how long it will be before the RD
performs the query operation.  If this is done inline then both of these
situations are addressed.  ( I have previously registered this complaint.
Also this is how my implementation works.)

* In section 5.3.1 - A valid response code might be 4.XX - method not
supported if this functionality is disabled.  I am not sure what the "or is
empty" means for the 4.04 response code.  Which one is empty, the RD or the
EP? 

* In section 5.3.1 - Is the RD responsible for dealing with resource-link
items which would not make sense by doing full resolutions on everything or
re-writing them?

* In section 5.4.1 - s/lt,con/lt,base/

* In section 5.4.1 - Description of 4.04 failure - I think this should be
'may have been garbage collected' as I believe from previous text that one
should be able to refresh an expired registration.

* In section 6.4 - The example is missing the rt="core.rd-ep" attribute.  It
appears to be required from the second paragraph.

* In section 6.4 - Can you give an example of a "Links to endpoints"?  The
only one that I can think of is 'base'.

* General - Should there be a value for lt which means infinite?

Jim

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 11 Dec 2018 09:59:00 +0100

Hi Jim,

thanks, for the questions.
One explanation for one question.
Jim Schaad schreef op 2018-12-11 03:22:

> <pvds>
> The feeling was that a first ep having done the earlier registration /rd/4001 
> should not be able to manipulate the 2nd registration by a 2nd ep, by removing /rd/4001
> and having a registration /rd/4002 only known to 2nd ep.
> </pvds>

---

From: Jim Schaad <[email-masked]>
Date: Tue, 11 Dec 2018 09:41:01 -0800

From: Peter van der Stok <[email-masked]> 
Sent: Tuesday, December 11, 2018 12:59 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Questions and comments against the github version

Hi Jim,

POST /rd?ep=e1&foo=over

Res: 2.01 Created
Location-Path: /rd/4001

POST /rd?ep=e1&foo=under

Res: 2.01 Created
Location-Path: /rd/4002

As opposed to:

POST /rd?ep=e1&foo=over

Res: 2.01 Created
Location-Path: /rd/4001

POST /rd/4001?foo=under

Res: 2.01 Changed

<pvds>

[JLS] The only problem with this is that the query of endpoints needs to be changed so that the endpoint locations are not returned.  Once the query is done then the location is known to a 2nd ep.

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 12 Dec 2018 09:21:19 +0100

Jim Schaad schreef op 2018-12-11 18:41:

> FROM: Peter van der Stok <[email-masked]> 
> SENT: Tuesday, December 11, 2018 12:59 AM
> TO: Jim Schaad <[email-masked]>
> CC: [email-masked]; [email-masked]
> SUBJECT: Re: Questions and comments against the github version 
> 
> Hi Jim,
> 
>> Is true.
>> The above statement is not about security and hiding information.
>> It is to prevent non-malicious unwanted mistakes.
>> </pvds>

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 12 Dec 2018 09:51:19 +0100

Hi Jim,

Some reactions to some of your other questions
Jim Schaad schreef op 2018-12-11 03:22:

> Recognizing an endpoint falls under the category "use of security context"?
> as described under ep parameter specfication.
> I am afraid security context is not defined in this draft.
> Possibly remove this phrase from the ep? 
> </pvds>
> 
> The text says: "the base attribute is not accepted to keep the registration interface simple"
> Looks sufficient to me.
> </pvds>
> 
> "or is empty" is about response from simple ep to RD
> meaning the /.well-known/core of the server ep is empty.
> I am not sure to understand the 4.XX remark though.
> </pvds>
> 
> For me a difficult question. "making sense" is very context/application dependent.
> The less the RD decides about validity of link contents, the better I feel.
> </pvds>
> 
> Thanks, missed that one.
> Many thanks,
> Other questions, suggestions in next e-mail

---

From: Lauri Piikivi <[email-masked]>
Date: Wed, 12 Dec 2018 09:55:58 +0000

Hi,

I just want to verify that the endpoint identity, and related access control is part of the question below. If a EP publishes itself in rd, no other ep, based on adequate authenticaiton, can overwrite it. If an earlier registered EP makes a new registration to the RD, where it does not include the location in the path, is an indication that the EP may have reset or otherwise wants a new registration (e.g. Due to changed attributes) in the rd.

Another ep trying to post to another ep’s url should get an error. This requires authenticaiton.

If there is adeqaute authenticaiton, and access control to the publishing, then retrieving all the eps is not a problem.

Sincerely,
- Lauri

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: core <[email-masked]> on behalf of Peter van der Stok <[email-masked]>
Sent: Wednesday, December 12, 2018 8:21 AM
To: Jim Schaad
Cc: [email-masked]; [email-masked]
Subject: Re: [core] Questions and comments against the github version

Hi Jim,

POST /rd?ep=e1&foo=over

Res: 2.01 Created
Location-Path: /rd/4001

POST /rd?ep=e1&foo=under

Res: 2.01 Created
Location-Path: /rd/4002

As opposed to:

POST /rd?ep=e1&foo=over

Res: 2.01 Created
Location-Path: /rd/4001

POST /rd/4001?foo=under

Res: 2.01 Changed

<pvds>

<pvds>
Is true.
The above statement is not about security and hiding information.
It is to prevent non-malicious unwanted mistakes.
</pvds>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Christian M. Amsüss <[email-masked]>
Date: Sun, 16 Dec 2018 14:33:30 +0100

Hello Jim, Peter,

(trying to wrap up all the comments that have been exchanged here)

On Mon, Dec 10, 2018 at 06:22:48PM -0800, Jim Schaad wrote:
> in behavior depending on what messages are used.

Frankly, I don't understand why those rules need to be here in the first
place -- from my PoV the only thing that matters is CoAP idempotency
(ie. identical messages that arrive with no other related operations
inbetween have the same result).

Peter, any concrete ideas on how to clean them up -- preferably in a way
that they don't speak of "updates"?

(My alternative would be: "The following rules" and their items, and
state that "Any Registration that has the same endpoint name and sector
('ep' and 'd' values) as a previously active one implicitly deletes that
registration." -- the idempotency rule stays intact and allows some
optimizations in terms of retransmission, but for everything else
everyone pretty please use the Location returned, whatever that is.)

> an error or does one of them override?

4.01 Unauthorized. Were the credentials valid for any other ep, the
server could not "recognize" the endpoint; thus it follows that the
credentials are not good enough to create a registration with the given
ep value.

> registration interface simple"

Agreed. I'd expect 4.00 Bad Request, but whoever sends that is already
in violation of the interface.

> the query.

See https://github.com/core-wg/resource-directory/issues/186

> empty" means for the 4.04 response code.  Which one is empty, the RD or the

The 4.04 is an error here IMO that has been reitrated time and again in
the context of link format lookups (an empty list of links is distinct
from an absent list!); fixed.

> items which would not make sense by doing full resolutions on everything or

(pvds)
> The less the RD decides about validity of link contents, the better I feel.

It is generally demanded of the base URI that it "MUST be suitable as a
base URI to resolve any relative references given in the registration".
For regular registration that's explicit in the base parameter
description, for simple that follows from the registrant needing to
provide RFC6690 discovery (which doesn't work if links can't be
resolved).

If URIs make no sense, then that's the registrant's fault, and I don't
see how the RD could tell whether they do.

If the URIs can't be resolved (though I'm not sure the 3986 process
defines any error condition at all), then I'd treat that as equivalent
to any other syntax error in the submitted links (and either silently
fail or return Bad Request depending on what comes out of the above on
when the response is sent.)

> * In section 5.4.1 - s/lt,con/lt,base/

Thanks, fixed.

> should be able to refresh an expired registration.

Should say "may have been removed (explicitly or after its
expiration)"; that removal could have been explicit or as a concequence
of an overly long expiration. Fixed.

> appears to be required from the second paragraph.

Thanks, fixed (also on other locations).

> * General - Should there be a value for lt which means infinite?

I think there should at least be a value for "as long as this TCP or
WebSocket connection is open" -- which primarily makes sense with an
additional "and please build a base name for me and act as a forward
proxy" parameter. Both can be covered using extensions.

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Jim Schaad <[email-masked]>
Date: Sun, 16 Dec 2018 12:07:56 -0800

> -----Original Message-----
> From: Christian M. Amsüss <[email-masked]>
> Sent: Sunday, December 16, 2018 5:34 AM
place --
> from my PoV the only thing that matters is CoAP idempotency (ie. identical
> messages that arrive with no other related operations inbetween have the
> same result).
> 
that
> they don't speak of "updates"?
> 
> (My alternative would be: "The following rules" and their items, and state
that
> "Any Registration that has the same endpoint name and sector ('ep' and 'd'
> values) as a previously active one implicitly deletes that registration."
-- the
> idempotency rule stays intact and allows some optimizations in terms of
> retransmission, but for everything else everyone pretty please use the
Location
> returned, whatever that is.)
> 
> > *  In Section 5.3 - What is the correct behavior if the RD is
> > configured to recognize an endpoint, but the endpoint supplies a
> > different name?  Is this an error or does one of them override?
> 
> 4.01 Unauthorized. Were the credentials valid for any other ep, the server
> could not "recognize" the endpoint; thus it follows that the credentials
are not
> good enough to create a registration with the given ep value.

Ok, I can accept this.

> Agreed. I'd expect 4.00 Bad Request, but whoever sends that is already in
> violation of the interface.
> 
> > * In section 5.3.1 - When doing simple registration, I do not believe
> > that it should be a requirement that the result MUST be returned prior
> > to doing the query.
> 
> > supported if this functionality is disabled.  I am not sure what the
> > "or is empty" means for the 4.04 response code.  Which one is empty,
> > the RD or the EP?
> 
the
> context of link format lookups (an empty list of links is distinct from an
absent
> list!); fixed.
> 
> > * In section 5.3.1 - Is the RD responsible for dealing with
> > resource-link items which would not make sense by doing full
> > resolutions on everything or re-writing them?
> 
> (pvds)
base
> URI to resolve any relative references given in the registration".
description, for
> simple that follows from the registrant needing to provide RFC6690
discovery
> (which doesn't work if links can't be resolved).
> 
> If URIs make no sense, then that's the registrant's fault, and I don't see
how the
> RD could tell whether they do.
> 
defines any
> error condition at all), then I'd treat that as equivalent to any other
syntax error
> in the submitted links (and either silently fail or return Bad Request
depending
> on what comes out of the above on when the response is sent.)

My issue was not with the question of can the URI be referenced, but the
vague memory that I had where there were some things that one could have
that would make sense in terms of /.well-known/core but did not make any
sense when the same links were delivered from a RD.  It may be that by
always returning fully resolved URIs we have dealt with this problem and I
am just having bad memory echoes.

> > * In section 5.4.1 - Description of 4.04 failure - I think this should
> > be 'may have been garbage collected' as I believe from previous text
> > that one should be able to refresh an expired registration.
> 
> Should say "may have been removed (explicitly or after its expiration)";
that
> removal could have been explicit or as a concequence of an overly long
> expiration. Fixed.
> 
> > * In section 6.4 - The example is missing the rt="core.rd-ep"
> > attribute.  It appears to be required from the second paragraph.
> 
> > * In section 6.4 - Can you give an example of a "Links to endpoints"?
> > The only one that I can think of is 'base'.
> >
WebSocket
> connection is open" -- which primarily makes sense with an additional "and
> please build a base name for me and act as a forward proxy" parameter.
Both
> can be covered using extensions.

I was thinking in terms of the CT case for the small system that Peter had
referenced to for simple registration.  If the CT can go in and say that
this is good forever and does not need to leave some system around that is
going to need to do refresh of the registration information since it is not
ever expected to change.  I recognize the inherent risks in that a device
may be taken out of service and the registration not removed but I think it
may be a simple system optimization.

Jim

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 17 Dec 2018 11:53:43 +0100

Hi JIm, Christian,

Just my hesitant 2 cents below, given my earlier explanation on this
subject.

> On Mon, Dec 10, 2018 at 06:22:48PM -0800, Jim Schaad wrote: *  In section 5.3, I don't understand why the rule exists that if the

<pvds>
Original text:
"The following rules apply for an for an update identified by a given
(ep, d)
   value pair:

   o  when the parameter values of the Update generate the same
      attribute values as already present, the location of the already
      existing registration is returned.

   o  when for a given (ep, d) value pair the update generates attribute
      values which are different from the existing one, the existing
      registration is removed and a new registration with a new location
      is created.

   o  when the (ep, d) value pair of the update is different from any
      existing registration, a new registration is generated." New text:
"The following rules apply for a registration-request targeting a given
(ep, d)
   value pair:
 o  when the (ep, d) value pair of the registration-request  is
different from any
      existing registration, a new registration is generated."
o  when the (ep, d) value pair of the registration-request is equal to
an
      existing registration, the content of the existing registration is
replaced with the content of the registration-request"

Better?
</pvds>

Peter

---

From: Christian M. Amsüss <[email-masked]>
Date: Mon, 17 Dec 2018 12:04:38 +0100

Hi Peter, Jim,

On Mon, Dec 17, 2018 at 11:53:43AM +0100, Peter van der Stok wrote:
> New text:
> [...]

To me, yes. I've added "the content *and parameters* of [...] are
replaced" and merged that in.

Thanks
Christian

-- 
I love it when a draft comes together.
  -- Hannibal Smith (quoted freely)

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 19 Dec 2018 09:39:46 +0100

Hello Lauri,

On Wed, Dec 12, 2018 at 09:55:58AM +0000, Lauri Piikivi wrote:
> If a EP publishes itself in rd, no other ep, based on adequate
> authenticaiton, can overwrite it. If an earlier registered EP makes a
> new registration to the RD, where it does not include the location in
> the path, is an indication that the EP may have reset or otherwise
> wants a new registration (e.g. Due to changed attributes) in the rd.

Yes.

> This requires authenticaiton.

An new ep trying to post to an old ep's registration URL is what I'd
call "registration hijacking". It is not allowed, but begs the question
of how the RD would know that the hijacking endpoint is actually
different from the original one.

If the credentials are suitable, the only assumption the RD can make is
that the "new" endpoint is the same as the old one, and that it has only
just switched its network address.

Otherwise, the RD would reject the operation with 4.01 Unauthorized.

Best regards
Christian

-- 
The detailed semantics of CoAP methods are "almost, but not entirely
unlike" [HHGTTG] those of HTTP methods.
[HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979.
  -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP)