Re: [auth48] AUTH48: RFC-to-be 9249 <draft-ietf-ntp-yang-data-model-17> for your review

[Dhruv Dhody <[e-mail]>]

Hi Megan,

Thanks for the editing. Please find my answers inline -


On Tue, Jun 21, 2022 at 6:28 PM Megan Ferguson <[e-mail]> wrote:

> Authors,
>
> We don’t believe we’ve heard back from you regarding this document’s
> readiness for publication.
>
> Please review both the AUTH48 announcement message and document-specific
> questions below and let
> us know if we can be of service during your AUTH48 review.
>
> Thank you.
>
> RFC Editor/mf
>
>
> > On Jun 10, 2022, at 3:07 PM, [e-mail] wrote:
> >
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> >
> > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->
> >


[Dhruv]: NTPv4, NTPv3


>
> >
> > 2) <!--[rfced] Is this YANG data model configuring NTP v3 itself?  Please
> > note that a similar sentence exists in the Introduction that
> > should also be changed if an update is necessary.
> >
> > Current:
> > It can also be used to configure version 3.
> >
> > Perhaps:
> > It can also be used to configure implementations using version 3.
> > -->
> >


[Dhruv]: I think we should avoid using "implementations". The abstract
could be -

   This document defines a YANG data model that can be used to
   configure and manage Network Time Protocol (NTP) version 4.  It can
   also be used to configure and manage version 3.  The data model
   includes configuration data and state data.


> >
> > 3) <!--[rfced] FYI, we have updated the first sentence of the Abstract
> and
> > Introduction.  Please review and let us know any concerns.
> >
> > Original (Abstract):
> >   This document defines a YANG data model for Network Time Protocol
> >   (NTP) version 4 implementations.
> >
> > Current:
> >   This document defines a YANG data model for implementations of the
> >   Network Time Protocol (NTP) version 4.
> >
> >
> > Original (Intro):
> >   This document defines a YANG [RFC7950] data model for Network Time
> >   Protocol [RFC5905] implementations.
> >
> > Current:
> >   This document defines a YANG data model [RFC7950] for
> >   implementations of the Network Time Protocol version 4 [RFC5905].
> > -->
> >


[Dhruv]: To avoid using the word implementation, the introduction can be
changed to  -

   This document defines a YANG data model [RFC7950] that can be used
   to configure and manage Network Time Protocol version 4 [RFC5905].
   Note that the model could also be used to configure and manage
   NTPv3 [RFC1305] (see Section 7).

Let's make a similar change inside the YANG module in the description
clause.


>
> >
> > 4) <!--[rfced] Regarding Tables 3, 4, and 5, for the ease of the reader,
> would
> > you like to add text within each empty table cell (such as "[no
> equivalent]")
> > or add a sentence before each table to be specific about the meaning of
> > an empty cell? We are referring to these cells:
> >
> > Table 3:
> >      |                           | ntpEntStatusActiveRefSourceName |
> >
> > Table 4:
> >   |                                       |      ntpAssocAddress      |
> >
> > Table 5:
> >
> >    |                               |          server/name           |
> > -->
> >


[Dhruv]: The empty cell on left actually means that the clock-refid
corresponds to both ntpEntStatusActiveRefSourceId and
ntpEntStatusActiveRefSourceName.
Similarly, address corresponds to ntpAssocAddressType and ntpAssocAddress.

I don't think we can do a "merge cells" on the left? Maybe we put MIB
objects together in one row then! What would be the best practice here?



>
> >
> > 5) <!--[rfced] The following sentence is problematic in a few ways:
> >
> > Original:
> >   The access rules in this section refers to the on-the-wire access
> >   control to the NTP service and completely independent of any
> >   management API access control, e.g., NETCONF Access Control Model
> >   (NACM) ([RFC8341]).
> >
> > a) There is a subject/verb agreement issue between "access rules" and
> "refers".
> >
> > b) What is the subject of "completely independent of any management
> > API access control": is text missing there?  Please rephrase.
> >
> > Perhaps:
> >   The access rules in this section refer to the on-the-wire access
> >   control to the NTP service and are completely independent of any
> >   management API access control, e.g., NETCONF Access Control Model
> >   (NACM) [RFC8341].
> > -->
> >


[Dhruv]: Your rephrasing is perfect.

>
> >
> > 6) <!--[rfced] May we make this change so that the first bulleted item
> > is more similar to those that follow?  Note - this change would also
> > solve an issue based on the first clause not having a subject but
> > the second clause using "it".
> >
> > Original:
> >   *  Peer: Permit others to synchronize their time with the NTP entity
> >      or it can synchronize its time with others.  NTP control queries
> >      are also accepted.
> >
> > Perhaps:
> >   * Peer: Permit others to synchronize their time with the NTP entity
> >     or vice versa.  NTP control queries are also accepted.
> >
> > Note also that a similar edit could be made to the description clause
> that follows:
> >
> > Original:
> >         "Permit others to synchronize their time with this NTP
> >          entity or it can synchronize its time with others.
> >
> > Perhaps:
> >         "Permit others to synchronize their time with this NTP
> >          entity or vice versa.
> > -->
> >


[Dhruv]: Your rephrasing is perfect.



>
> >
> > 7) <!--[rfced] We had the following questions about text that appears
> >     inside the YANG module.
> >
> > a) We lowercased "Indicates" twice in text like the following.  Please
> > let us know any objections.
> >
> > Original:
> >          description
> >            "The signed time offset to the current selected reference
> >             time source, e.g., '0.032ms' or '1.232ms'.  The negative
> >             value Indicates that the local clock is behind the
> >             current selected reference time source.";
> >
> >


[Dhruv]: Ack



>
> > b) Please review the use of "dispersion" in the following text.
> > (Is it accurate to say "dispersion between"?)
> >
> > Original:
> >          description
> >            "The dispersion between the local clock
> >             and the root clock, e.g., '6.927ms'.";
> >
> > For comparison, in RFC 5905, it says:
> >   Root Dispersion (rootdisp): Total dispersion to the reference clock,
> >   in NTP short format.
> >
> >


[Dhruv]: Better to align with 5905 and use "to" instead of "between".



>
> > c) Please confirm that Peer should be capitalized in the following
> > text.  We guess this is referring to the access mode, but don't see
> > any other instances of a capitalized "Peer" in the document.  However,
> > we do see the use of lowercase peer in quotes (see below).  Please
> > review and let us know if any updates should be made.
> >
> > Original:
> >        }
> >        container ntp-statistics {
> >          description
> >            "Per Peer packet send and receive statistics";
> >          uses statistics {
> >            description
> >              "NTP send and receive packet statistics";
> >          }
> >
> >
> > Perhaps:
> >           "Per-peer statistics on packets sent and received";
> > ...
> >           "NTP statistics on packets sent and received";
> >


[Dhruv]: You can make Peer to lowercase.
There is no specific reason to highlight "Per-peer", thus I prefer the 2nd
suggestion.



>
> >
> > Original:
> >   This example describes how to configure access mode "peer" associated
> >   with ACL 2000 -
> >
> > Perhaps:
> >   This example describes how to configure "peer-access-mode" associated
> >   with ACL 2000 -
> >
> >


[Dhruv]: Please go ahead with this change.



>
> >
> > d) Please clarify this list (note that similar text occurs multiple
> > times in the YANG module).
> >
> > Original:
> >         Discontinuities in the value of this counter can occur
> >         upon cold start or reinitialization of the NTP entity, the
> >         management system and at other times.
> >
> > Perhaps:
> >         Discontinuities in the value of this counter can occur
> >         upon cold start, reinitialization of the NTP entity or the
> >         management system, and at other times.
> >


[Dhruv]: Your rephrasing is correct.



>
> > e) Please review the use of "(mode 6)" in the text that follows.  We
> > note that 1) the text above it is very similar but does not mark
> > "(mode 6)" 2) the previous 5 modes used "mode" in their names (for
> > example, "server authentication mode (mode 4)", and 3) that
> > "multicast-client" operates very similarly in the sentence, but has no
> > mode designation.  Please review and let us know if/how we should
> > update.
> >
> > Original:
> >
> >     identity broadcast-server {
> >       base association-mode;
> >       description
> >         "Use broadcast server mode (mode 5).
> >          This mode defines that its either working
> >          as broadcast-server or multicast-server.";
> >     }
> >
> >     identity broadcast-client {
> >       base association-mode;
> >       description
> >
> >         "This mode defines that its either working
> >          as broadcast-client (mode 6) or multicast-client.";
> > -->
> >


[Dhruv]: Multicast-server and multicast-client do not get specific mode
assigned as per - https://datatracker.ietf.org/doc/html/rfc5905#section-3
and repurpose the mode 5 and 6 and description is aligned to that! No
update is needed.



> >
> > 8) <!--[rfced] In the YANG module, is it intentional that the
> > "contact" only includes the editors of the RFC? If so, that's fine.
> > If not, may we update it to list each individual who is listed in
> > the header of the RFC?
> > -->
> >


[Dhruv]: No preference, you can follow whatever is the best current
practice.

>
> >
> > 9) <!--[rfced] Please review comments left by authors in the XML and let
> > us know if any further action is necessary or if these comments may be
> > deleted.-->
> >
> >


[Dhruv]: can be deleted.



>
> > 10) <!--[rfced] Please review the use of "clock current state" in the
> > following text:
> >
> > Original:
> >   This example describes how to get clock current state -
> >
> > Perhaps:
> >   This example describes how to get current clock state -
> > -->
> >

[Dhruv]: Make sense.



>
> >
> > 11) <!--[rfced] FYI - we have moved several references from the
> > "Informative References" section to the "Normative References"
> > section per the guidance at
> > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines.
> > -->
> >


[Dhruv]: ok



>
> >
> > 12) <!--[rfced] May we update the [SHS] reference entry to match what was
> > used in RFC 9216 (2015 version instead of 2012)?
> >
> > Currently:
> >   [SHS]      NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March
> >              2012, <https://nvlpubs.nist.gov/nistpubs/fips/
> >              nist.fips.180-4.pdf>.
> > RFC 9216:
> >   [SHA]      National Institute of Standards and Technology (NIST),
> >              "Secure Hash Standard (SHS)", FIPS PUB 180-4,
> >              DOI 10.6028/NIST.FIPS.180-4, August 2015,
> >              <https://doi.org/10.6028/NIST.FIPS.180-4>.
> > -->
> >


[Dhruv]: Ok

>
> >
> > 13) <!-- [rfced] Throughout the text, we had the following questions
> about terminology.  Please review and let us know how you would like to
> proceed.
> >
> > a) How may we expand "KISS"? We note that RFC 5905 uses lowercase
> > "kiss code".
> >
> > Original:
> > It could be an IPv4 address or first 32 bits of the MD5 hash of the
> > IPv6 address or a string for the Reference Identifier and KISS codes.
> >


[Dhruv]: You can make it lowercase and follow RFC 5905.



>
> > b) The following terms appear to be used inconsistently.  Please review
> and let us know if/how these terms should be made uniform.
> >
> > key-id vs. key id vs. keyid
>
[Dhruv]: keyid

> > access-mode vs. access mode
>
[Dhruv]:  access-mode

> > local-mode vs. local mode
>
[Dhruv]:  local-mode

> > Authentication Key vs. authentication key

[Dhruv]: authentication key

>
> > Association vs. association
>
[Dhruv]:  association

> >
> > c) We see variations in hyphenation in the following related terms.
> >
> > unicast server vs. unicast-server
> >


[Dhruv]: unicast server

>
> > (see also broadcast and multicast forms as well as client, for example
> > multicast client vs. multicast-client)
>

[Dhruv]: Inside the YANG the list name is multicast-client, but otherwise
it is okay to use mulicast client.

I have verified the diff and all rendering of the RFCs. Please not my
approval for the AUTH48.

Thanks!
Dhruv

> -->
> >
> >
> > Thank you.
> >
> > RFC Editor/mf/ar
> >
> >
> > On Jun 10, 2022, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2022/06/10
> >
> > 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://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
> >
> > *  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 CC’ed on this message need to see your approval.
> >
> >
> > Files
> > -----
> >
> > The files are available here:
> >  https://www.rfc-editor.org/authors/rfc9249.xml
> >  https://www.rfc-editor.org/authors/rfc9249.html
> >  https://www.rfc-editor.org/authors/rfc9249.pdf
> >  https://www.rfc-editor.org/authors/rfc9249.txt
> >
> > Diff file of the text:
> >  https://www.rfc-editor.org/authors/rfc9249-diff.html
> >  https://www.rfc-editor.org/authors/rfc9249-rfcdiff.html (side by side)
> >
> > Diff of the XML:
> >  https://www.rfc-editor.org/authors/rfc9249-xmldiff1.html
> >
> > The following file is provided to facilitate creation of your own
> > diff file of the XML.
> >
> > Initial XMLv3 created using XMLv2 as input:
> >  https://www.rfc-editor.org/authors/rfc9249.original.v2v3.xml
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >  https://www.rfc-editor.org/auth48/rfc9249
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9249 (draft-ietf-ntp-yang-data-model-17)
> >
> > Title            : A YANG Data Model for NTP
> > Author(s)        : N. Wu, D. Dhody, Ed., A. Sinha, Ed., A. Kumar S N, Y.
> Zhao
> > WG Chair(s)      : Karen O'Donoghue, Dieter Sibold
> >
> > Area Director(s) : Erik Kline, Éric Vyncke
> >
>
>