Subject: Re: [6tisch] Adam Roach's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Nov 2019 17:43:51 -0400

Adam Roach via Datatracker <[email-masked]> wrote:
    > §8.1.1:

    >> o The Uri-Path option is set to "j".

    > COAP URIs are generally subject to BCP 190 restrictions, which would
    > require the path to either be provisioned, discovered, or under the
    > ".well-known" tree. The use of a reserved domain name here may change
    > the rationale; but for the sake of not establishing a precedent for

Yes, we think that it does.
The Host: is "6tisch.arpa", so we think that we are the owner of the URI, as
per BCP190 section 1, paragraph 3:

   }  Because the owner of the URI (as defined in [webarch]
   }  Section 2.2.2.1) is choosing to use the server or the application,
   }  this can be seen as reasonable delegation of authority.

How/where should we reference this?

    > path squatting in CoAP, this document needs to clearly explain the
    > rationale of why BCP 190 should not apply in this case. Alternately,
    > the implied URI can be changed to something like
    > "coap://6tisch.arpa/.well-known/j"

We feel that those 11 bytes are not needed. We already didn't like the
6tisch.arpa part....

    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------

    >> This document allocates a well-known name under the .arpa name space
    >> according to the rules given in [RFC3172].  The name "6tisch.arpa" is
    >> requested.  No subdomains are expected.  No A, AAAA or PTR record is
    >> requested.

    > Although "No subdomains are expected" is useful text, I don't think
    > it's sufficient to satisfy RFC 3172's requirements of specifying "the
    > rules for how the subdomain is administered." I would suggest something
    > like:

    > "No subdomains are expected, and addition of any such subdomains
    > requires the publication of an IETF standards-track RFC."

I used your text.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Nov 2019 17:46:15 -0400

> Note also the parameter update exchange describe in Section 8.2, where
    > the joined node is supposed to act as a CoAp server and expose the "/j"
    > resource.  The justification of the reserved domain name does not seem
    > to apply to that case, which seems to suggest that .well-known will be
    > needed.

I've added that the 6LR should locate this at the "6tisch.arpa" hostname.
This isolates the "/j" from any other uses of CoAP on the node.

If that's not acceptable, then we could live with .well-known, as the 6LR
has already joined, and it can negotiate for bandwidth, etc.

---

From: Adam Roach <[email-masked]>
Date: Fri, 1 Nov 2019 17:39:57 -0500

> How/where should we reference this?

Wherever you prefer. If I were editing the document, I would put it as 
an indented note paragraph directly under the bulleted list in Section 
8.1.1; but I defer to your judgement if you think it works better 
somewhere else.

> We feel that those 11 bytes are not needed. We already didn't like the

Understood. Ben pointed out something interesting that I didn't catch -- 
the text in Section 8.2.1 doesn't indicate what the "Uri-Host" value 
should be for parameter update exchange, and I can't quite figure out 
the answer myself. If it's supposed to be "6tisch.arpa", please add a 
bullet saying as much. If it's not "6tisch.arpa," then the URI ownership 
rationale above doesn't apply, and the path handling will need to change.

/a

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Nov 2019 17:40:08 -0400

> Wherever you prefer. If I were editing the document, I would put it as an
    > indented note paragraph directly under the bulleted list in Section 8.1.1;
    > but I defer to your judgement if you think it works better somewhere else.

I've a paragraph to added it to 8.1.1, and I've clarified that the
Parameter Update should have a Uri-Host value of 6tisch.arpa.