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

[Dhruv Dhody <[e-mail]>]

Hi Erik, ALL,

On Sun, Jun 26, 2022 at 3:07 AM Erik Kline <[e-mail]> wrote:

> If everyone is fine with s/key-id/keyid/g, then I'm okay with all these
> changes.  Thanks!
>
>
When I was asked to pick between the choices, I picked the one used by RFC
5905.
Also in the YANG, we use refid already, so using keyid seemed right!




> (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.)
>
>
Ha! I see mixed patterns right from the start in RFC 6020 where YANG is
defined. Perhaps RFC Editor has a best practice?

         revision 2007-06-09 {
             description "Initial revision.";
         }

         container system {
             leaf host-name {
                 type string;
                 description "Hostname for this system";
             }


Thanks!
Dhruv

> 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
>>> > >
>>> >
>>>
>>>