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

[Brian Haberman <[e-mail]>]

Hi Megan,
      I approve.

Thanks,
Brian

On 10/25/22 4:03 PM, Megan Ferguson wrote:
> Hi Brian,
> 
> Thank you for your response and guidance. We have updated our files as requested.  Please review these changes carefully and let us know if further updates are necessary.
> 
>    The files have been posted here (please refresh):
>     https://www.rfc-editor.org/authors/rfc9327.txt
>     https://www.rfc-editor.org/authors/rfc9327.pdf
>     https://www.rfc-editor.org/authors/rfc9327.html
>     https://www.rfc-editor.org/authors/rfc9327.xml
> 
>    The relevant diff files have been posted here (please refresh):
>     https://www.rfc-editor.org/authors/rfc9327-diff.html (comprehensive diff)
>     https://www.rfc-editor.org/authors/rfc9327-rfcdiff.html (comprehensive rfcdiff)
>     https://www.rfc-editor.org/authors/rfc9327-auth48diff.html (last version to this one)
> 
>    The AUTH48 status page for this document is available here:
>     http://www.rfc-editor.org/auth48/rfc9327
> 
> Thank you.
> 
> RFC Editor/mf
> 
> 
>> On Oct 22, 2022, at 3:26 PM, Brian Haberman <[e-mail]> wrote:
>>
>> 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
>