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

[Erik Kline <[e-mail]>]

If everyone is fine with s/key-id/keyid/g, then I'm okay with all these
changes.  Thanks!

(Random observation: I cannot figure when a trailing full stop (".") needs
to be added to a description field and when it can be dropped.  I couldn't
detect any pattern.)

On Fri, Jun 24, 2022 at 11:02 PM Dhruv Dhody <[e-mail]> wrote:

> Hi Megan,
>
> On Sat, Jun 25, 2022 at 3:07 AM Megan Ferguson <[e-mail]> wrote:
>
>> Hi Dhruv,
>>
>> Apologies for the missed announcement message: this is a known tech issue
>> on our end.
>>
>> Thank you for the reply.  Prior to marking you as “Approved” on the
>> AUTH48 status page,
>> please review our updates and confirm we have interpreted your guidance
>> correctly.
>> Specifically, please review our updates to the table formatting and the
>> updates to the
>> Abstract/Introduction that also affect the YANG module.
>>
>>
> The update to the tables looks good.
>
> One change in the YANG module description. Since you added "version 4",
> perhaps we should also include the statement on v3.
> CURRENT:
>      description
>        "This document defines a YANG data model that can be used
>       to configure and manage  Network Time Protocol (NTP) version 4.
> PROPOSE:
>      description
>        "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.
> END
>
> In the YANG model, I suggest making this update in the reference clause.
> OLD
>        reference
>          "FIPS 180-4: Secure Hash Standard (SHS)";
> NEW
>        reference
>          "SHS: Secure Hash Standard (SHS) (FIPS PUB 180-4)";
>  END
>
> There are 5 instances!
>
> All other changes look good. Please note my approval for publication!
>
> Thanks!
> Dhruv
>
>
>
>>   The files have been posted here:
>>    https://www.rfc-editor.org/authors/rfc9249.txt
>>    https://www.rfc-editor.org/authors/rfc9249.pdf
>>    https://www.rfc-editor.org/authors/rfc9249.html
>>    https://www.rfc-editor.org/authors/rfc9249.xml
>>
>>   The relevant diff files have been posted here:
>>    https://www.rfc-editor.org/authors/rfc9249-diff.html (cumulative
>> htmlwdiff)
>>    https://www.rfc-editor.org/authors/rfc9249-rfcdiff.html (cumulative
>> diff side-by-side)
>>    https://www.rfc-editor.org/authors/rfc9249-auth48diff.html (htmlwdiff
>> of AUTH48 changes only)
>>
>> The AUTH48 status page for this document is viewable at
>> https://www.rfc-editor.org/auth48/rfc9249.
>>
>> Thank you.
>>
>> RFC Editor/mf
>>
>>
>> > On Jun 22, 2022, at 8:50 AM, Dhruv Dhody <[e-mail]> wrote:
>> >
>> > 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
>> > >
>> >
>>
>>