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." _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
