Hi, I had some more off-line conversations with Ragnar.
He pointed me to the following: > I think I found why they are formated as they are: > It is according to IANA recommendations (almost at least), and we use “lists” for the "policy lists” and “tables” for registry contents. > At <https://www.iana.org/help/protocol-registration>, under "Lists Versus Tables”, they say: > "For an example of an IANA Considerations section that uses tables, see RFC 6940. For an example that uses lists, see RFC 5804.” While I still believe that explicit marking entries in the tables as 'Reserved for Future Standard Use' makes things more clear and avoids future problems, I can live with following the IANA recommendations above. This was a minor non-blocking issue anyway. Thanks for addressing this quickly. Regards, Dan On Fri, Feb 28, 2020 at 2:24 AM Ragnar Sundblad <ra...@netnod.se> wrote: > > Hi Dan, > > > On 27 Feb 2020, at 21:31, Dan Romascanu <droma...@gmail.com> wrote: > > > > Thanks Ragnar, for the quick answer. > > > > See in-line. > > > > Regards, > > > > Dan > > > > > > On Thu, Feb 27, 2020 at 6:56 PM Ragnar Sundblad <ra...@netnod.se> wrote: > > > > Hi Dan, > > > > Thank you for reviewing! > > > > On 26 Feb 2020, at 11:06, Dan Romascanu via Datatracker < > nore...@ietf.org> wrote: > > > > > > Reviewer: Dan Romascanu > > > Review result: Ready with Issues > > > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > > Review Team (Gen-ART) reviews all IETF documents being processed > > > by the IESG for the IETF Chair. Please treat these comments just > > > like any other last call comments. > > > > > > For more information, please see the FAQ at > > > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > > > Document: draft-ietf-ntp-using-nts-for-ntp-22 > > > Reviewer: Dan Romascanu > > > Review Date: 2020-02-26 > > > IETF LC End Date: 2020-02-28 > > > IESG Telechat date: Not scheduled for a telechat > > > > > > Summary: > > > > > > Ready with one minor issue to be discussed. > > > > > > A very clear, well written, nicely organized document. > > > > > > Major issues: > > > > > > Minor issues: > > > > > > 1. The tables in Sections 7.6, 7.7, 7.8 state that all undefined > values in the > > > registries start immediately after the values defined by this document > with > > > 'Reserved for Private and Experimental Use'. What about future > extensions in > > > future versions of the document? Would not it be better to leave a > range for > > > future extensions and start the values for private and experimental > use farther > > > in the total spaces? > > > > We are not sure what you mean - we believe that the tables say that the > upper halves of the spaces are 'Reserved for Private and Experimental Use’, > while the lower halves are unallocated except for those values that are > specified in the draft. > > > > Do you have an example of how you would want it to be written/formatted > instead? > > > > It would be more clear if you added in the table in Section 7.6 for > example: > > > > 8 - 16383 - Reserved for Future Standard Use > > That information is in the "policy for allocation allocation of new > entries" in a table (without frames) above the table for "the initial > contents of the table" (with frames). I believe there was some reason for > this, but I don’t know what it was. > > I guess we have to investigate this ASAP. > > > > Nits/editorial comments: > > > > > > 1. In the (very useful) Appendix A for Terms and Abbreviations, there > are a few > > > abbreviations usually considered part of the shared basis terms in IETF > > > documents (like TCP, UDP, IANA, ...) > > > > Ok - Marcus is doing that right now. > > > > Best regards, > > > > Ragnar > > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
