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.”
> 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 <ragge@xxxxxxxxx> wrote:
Hi Dan,
> On 27 Feb 2020, at 21:31, Dan Romascanu <dromasca@xxxxxxxxx> wrote:
>
> Thanks Ragnar, for the quick answer.
>
> See in-line.
>
> Regards,
>
> Dan
>
>
> On Thu, Feb 27, 2020 at 6:56 PM Ragnar Sundblad <ragge@xxxxxxxxx> wrote:
>
> Hi Dan,
>
> Thank you for reviewing!
>
> On 26 Feb 2020, at 11:06, Dan Romascanu via Datatracker <noreply@xxxxxxxx> 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
>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
