Re: [auth48] AUTH48: RFC-to-be 9327 <draft-ietf-ntp-mode-6-cmds-11> for your review

[Brian Haberman <[e-mail]>]

I approve the publication of this draft... Please see inline responses.

On 10/21/22 11:04 PM, [e-mail] wrote:
> Brian,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] Would updating the document title to include the abbreviation for Network Time Protocol Version 4 be helpful?
> 
> Original:
> Control Messages Protocol for Use with Network Time Protocol Version 4
> 
> Perhaps:
> Control Messages Protocol for Use with Network Time Protocol Version
> 4 (NTPv4)
> -->
> 

NTPv4 does not get used at all in the body of the document, so I don't 
see a need to make this addition to the title.

> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>       title) for use on https://www.rfc-editor.org/search. -->
> 

NTP, mode 6, mode 7

> 
> 3) <!-- [rfced] We note that in-text citations were sometimes read as
>       part of the sentence and sometimes used as a silent reference.
>       As https://www.rfc-editor.org/styleguide/part2/ recommends these
>       be used consistently, we will update as seen in the example
>       below unless we hear objection.
> 
> Original:
> RFC 1305 [RFC1305] described a set of control messages for use
> within the Network Time Protocol (NTP) when a comprehensive network management
> solution was not available.
> 
> Perhaps:
> [RFC1305] described a set of control messages for use within the
> Network Time Protocol (NTP) when a comprehensive network management solution
> was not available.
> -->
> 

No objection.

> 
> 4) <!-- [rfced] FYI - We've added a Terminology section and normative
>       reference entries to match the use of BCP 14 keywords throughout
>       the document. Please let us know of any objections.
> -->	
> 

No objection.

> 
> 5) <!--[rfced] We note that RFC 2460 has been obsoleted by RFC 8200.  As
>       this document is "Historic", please let us know which course of
>       action is correct.  Is the mention something that only exists in
>       RFC 2460?  Or should the reader be pointed to the current
>       version?
> 
> a) Update mentions of RFC 2460 to instead point to RFC 8200.
> 
> b) Update the text to mention that RFC 2460 has been obsoleted by RFC 8200, such
>   as:
> 
> ..and 1280 octets for IPv6 (see [RFC2460], which has since been obsoleted by [RF
> C8200]).
> 
> For either a) or b), we would add a corresponding reference entry for RFC 8200.
> -->
> 

All references to RFC 2460 can be replaced by RFC 8200.

> 
> 6) <!-- [rfced] FYI: We've added titles to tables throughout the
>       document. Please let us know of any objections or changes that
>       need to be made.
> -->
> 

No objection.

> 
> 7) <!-- [rfced] What is "one" referring to in this sentence?
> 
> Original:
> As in the read status command, the association identifier is used to
> identify which one, zero for the system clock and nonzero for a peer clock.
> 
> Perhaps:
> As in the read status command, the association identifier is used to
> identify the correct variable for each clock: zero for the system clock and nonzero for a peer clock.
> -->	
> 

I agree with the proposed re-write for clarity.

> 
> 8)  <!--[rfced] Please review our update to use a list for the following text.
> 
> Original:
> 
> Internet addresses are represented as follows: IPv4 addresses are
> written in the form [n.n.n.n], where n is in decimal notation and the
> brackets are optional; IPv6 addresses are formulated based on the
> guidelines defined in [RFC5952].  Timestamps, including reference,
> originate, receive and transmit values, as well as the logical clock,
> are represented in units of seconds and fractions, preferably in
> hexadecimal notation.  Delay, offset, dispersion and distance values
> are represented in units of milliseconds and fractions, preferably in
> decimal notation.  All other values are represented as-is, preferably
> in decimal notation.
> 
> Current:
>   Representations of note are as follows:
> 
>     *  IPv4 internet addresses are written in the form [n.n.n.n], where n
>        is in decimal notation and the brackets are optional
> 
>     *  IPv6 internet addresses are formulated based on the guidelines
>        defined in [RFC5952].
> 
>     *  Timestamps (including reference, originate, receive, and transmit
>        values) and the logical clock are represented in units of seconds
>        and fractions, preferably in hexadecimal notation.
> 
>     *  Delay, offset, dispersion, and distance values are represented in
>        units of milliseconds and fractions, preferably in decimal
>        notation.
> 
>     *  All other values are represented as is, preferably in decimal
>        notation.
> -->
> 

The bulleted list is fine.

> 
> 9) <!--[rfced] Please review the updates to the following text to ensure
>       we've retained your intended meaning.  Perhaps further rephrasing
>       such as "...or is comprised of the seven characters" might be
>       easier to read?
> 
> Original:
> If the command data is empty or the seven characters "ifstats", the
> associated statistics, status and counters for each local address are
> returned.  If the command data is the characters "addr_restrictions" then the
> set of IPv4 remote address restrictions followed by the set of IPv6 remote
> address restrictions (access control lists) are returned.
> 
> Current:
> If the command data is empty or is the seven characters "ifstats", the
> associated statistics, status, and counters for each local address are
> returned.  If the command data is the characters "addr_restrictions",
> then the set of IPv4 remote address restrictions followed by the set
> of IPv6 remote address restrictions (access control lists) are
> returned.
> -->
> 

This update is fine.

> 
> 10) <!--[rfced] Please review our update to the list style in the Security Considerations section and let us know any objections.-->
> 

No objection.

> 
> 11) <!--[rfced] Would a clarification of this text be helpful to readers?
>       We see past draft versions with D. Mills and B. Haberman, but not
>       T. Plunkett.
> 
> Original:
> Tim Plunkett created the original version of this document.-->
> 

The original acknowledgements section is correct.

> 
> 12) <!-- [rfced] We had the following questions regarding terminology that appeared throughout the document.
> 	
> a) Please review the way bit names and abbreviations are capped,
> quoted, in parentheses, and the placement of the abbreviation (i.e.,
> should it be More Bit (M) or More (M) Bit)?
> 
> These are a few examples of inconsistencies/uses:
> 
> Response Bit (R) vs. response (R) bit vs. "R" bit vs R bit
> E (error) bit vs. "E" bit
> More Bit (M) vs. More Bit vs. more data (M) bit vs. more-data (M) bit

The original text in the draft is correct. It is consistent with the 
original definitions described in RFC 1305.

> 
> b) Throughout the text, the following terminology appears to be used
> inconsistently. Please review these occurrences and let us know if/how
> they may be made consistent.
> 

The following clarifications (except for one) come directly from RFC 1305...

> opcode vs. OpCode

opcode

> Association ID vs. association identifier

Association ID

> NTP mode 6 vs. NTP Mode 6

NTP mode 6

> NTP Mode 6 control messages vs. NTP mode 6 control messages vs. NTP Control Message vs. control messages (mode 6)

NTP control messages... as this document talks about both mode 6 and mode 7

> System Status Word vs. system status word

system status word

> Read Clock Variables command vs. read clock variables command

read clock variables command

> Write Clock Variables command vs. write clock variables command

write clock variables command

> Remote Facility vs. remote facility

Remote Facility

> Request Code vs. request code

request code

> 
> 
> -->
> 
> 
> 13) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide
>       <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed. For example, please consider whether the following should be updated: sanity and whitespace.
> 

"sanity" can be changed to "logical"
"whitespace" can be changed to "space characters"

> In addition, please consider whether "traditional*" should be updated
> for clarity.  While the NIST website
> <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
> indicates that this term is potentially biased, it is also ambiguous.
> "Tradition" is a subjective term, as it is not the same for everyone.
> -->
> 

"Traditionally" can be dropped from the sentence.

Regards,
Brian

> 
> Thank you.
> 
> RFC Editor/mc/mf
> 
> *****IMPORTANT*****
> 
> Updated 2022/10/21
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
> 
> Planning your review
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>     Please review and resolve any questions raised by the RFC Editor
>     that have been included in the XML file as comments marked as
>     follows:
> 
>     <!-- [rfced] ... -->
> 
>     These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors
> 
>     Please ensure that you review any changes submitted by your
>     coauthors.  We assume that if you do not speak up that you
>     agree to changes submitted by your coauthors.
> 
> *  Content
> 
>     Please review the full content of the document, as this cannot
>     change once the RFC is published.  Please pay particular attention to:
>     - IANA considerations updates (if applicable)
>     - contact information
>     - references
> 
> *  Copyright notices and legends
> 
>     Please review the copyright notice and legends as defined in
>     RFC 5378 and the Trust Legal Provisions
>     (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>     Please review the markup in the XML file to ensure that elements of
>     content are correctly tagged.  For example, ensure that <sourcecode>
>     and <artwork> are set correctly.  See details at
>     <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>     Please review the PDF, HTML, and TXT files to ensure that the
>     formatted output, as generated from the markup in the XML file, is
>     reasonable.  Please note that the TXT will have formatting
>     limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
> 
>     *  your coauthors
>     
>     *  [e-mail] (the RPC team)
> 
>     *  other document participants, depending on the stream (e.g.,
>        IETF Stream participants are your working group chairs, the
>        responsible ADs, and the document shepherd).
>       
>     *  [e-mail], which is a new archival mailing list
>        to preserve AUTH48 conversations; it is not an active discussion
>        list:
>       
>       *  More info:
>          https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>       
>       *  The archive itself:
>          https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>       *  Note: If only absolutely necessary, you may temporarily opt out
>          of the archiving of messages (e.g., to discuss a sensitive matter).
>          If needed, please add a note at the top of the message that you
>          have dropped the address. When the discussion is concluded,
>          [e-mail] will be re-added to the CC list and
>          its addition will be noted at the top of the message.
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
>   — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files
> -----
> 
> The files are available here:
>     https://www.rfc-editor.org/authors/rfc9327.xml
>     https://www.rfc-editor.org/authors/rfc9327.html
>     https://www.rfc-editor.org/authors/rfc9327.pdf
>     https://www.rfc-editor.org/authors/rfc9327.txt
> 
> Diff file of the text:
>     https://www.rfc-editor.org/authors/rfc9327-diff.html
>     https://www.rfc-editor.org/authors/rfc9327-rfcdiff.html (side by side)
> 
> Diff of the XML:
>     https://www.rfc-editor.org/authors/rfc9327-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own
> diff files of the XML.
> 
> Initial XMLv3 created using XMLv2 as input:
>     https://www.rfc-editor.org/authors/rfc9327.original.v2v3.xml
> 
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>     https://www.rfc-editor.org/authors/rfc9327.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>     https://www.rfc-editor.org/auth48/rfc9327
> 
> Please let us know if you have any questions.
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9327 (draft-ietf-ntp-mode-6-cmds-11)
> 
> Title            : Control Messages Protocol for Use with Network Time Protocol Version 4
> Author(s)        : B. Haberman, Ed.
> WG Chair(s)      : Karen O'Donoghue, Dieter Sibold
> 
> Area Director(s) : Erik Kline, Éric Vyncke
> 
>