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

[Adam Roach via Datatracker <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-6tisch-minimal-security-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who invested their time in this document. I have one
blocking comment that I believe should be easy to resolve, and one fairly major
comment that should be trivial to fix.

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


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