On Mon, May 23, 2022 at 8:01 AM Francesca Palombini via Datatracker < nore...@ietf.org> wrote:
> ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work on this document. > > Many thanks to Cullen Jennings for his ART ART review: > https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/. > > Thank you for addressing my previous DISCUSS and COMMENTs. I have reviewed > v-09 > and I noticed 4 points were not addressed (or I missed them). Do let me > know if > you think no further clarifications were necessary - just making sure these > were not missed, as I have not seen any answers to them. > > Re: the use of SHOULD - thank you for adding context to most of them. I > did not > see any added context to these following two SHOULDs: > OK, I've proposed adjustments to those two SHOULDs at https://github.com/MikeBishop/dns-alt-svc/pull/392 ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 4. ----- > > The value is then > validated and converted into wire-format in a manner specific to each > key. > > FP: Section 15.3.1 states > > registration policy ([RFC8126], Section 4.5). The designated expert > MUST ensure that the Format Reference is stable and publicly > available, and that it specifies how to convert the SvcParamValue's > presentation format to wire format. > > This covers the conversion, but does not cover the validation mentioned > above. > (This could be really easily addressed by making sure that not only it > specifies how to convert but also how to validate). > I don't think this text change is necessary, because any specification of the conversion necessarily also covers validation. A "conversion" in this context is an algorithm that accepts one input (an octet sequence) and produces one output, which is either an octet sequence or a failure indication. If the conversion fails, we say that the input was invalid. 10. ----- > > Table 1 > > FP: The table reports that > > | 65280-65534 | N/A | Private Use | (This document) | > > But that is not specified in the text above, that only talks about expert > review registration policy. That should be made consistent. > This text was slightly adjusted in -09 based on your comment. It now reads "_New_ entries in this registry are subject to an Expert Review registration policy" (emphasis mine). This is consistent with the example given in RFC 8126 Section 2.2. I believe the source of confusion here is that RFC 8126 defines "Private Use" twice, with incompatible meanings: Section 4.1 describes it as a Registration Policy, whereas Section 6 defines it as a Registration Status. This registry is using the latter definition.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
