Re: [Gen-art] Genart last call review of draft-ietf-ntp-using-nts-for-ntp-22

[Dan Romascanu <[e-mail]>]

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 <[e-mail]> wrote:

>
> Hi Dan,
>
> > On 27 Feb 2020, at 21:31, Dan Romascanu <[e-mail]> wrote:
> >
> > Thanks Ragnar, for the quick answer.
> >
> > See in-line.
> >
> > Regards,
> >
> > Dan
> >
> >
> > On Thu, Feb 27, 2020 at 6:56 PM Ragnar Sundblad <[e-mail]> wrote:
> >
> > Hi Dan,
> >
> > Thank you for reviewing!
> >
> > On 26 Feb 2020, at 11:06, Dan Romascanu via Datatracker <
> [e-mail]> 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
> >
>
>