A YANG Data Model for NTP
draft-ietf-ntp-yang-data-model-17

[Ballot comment]
Thanks for all the updates, resolving my Discuss and Comment points!

Just a couple last notes:

- as the RFC 8177 functionality is not used,
we should remove it from the table where it's referenced and then
garbage-collect the references entry itself.

- I don't think FIPS 180-4 is a good reference for the truncated HMAC-SHA1-12.
Perhaps an older version would have covered it, though (I didn't check)?

Changed document external resources from:

yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ntp@2022-02-10.yang (Yang catalog entry for ietf-ntp@2022-02-10.yang)
yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-ntp@2022-02-10.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-ntp-yang-data-model)

to:

yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ntp.yang (Yang catalog entry for ietf-ntp.yang)
yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-ntp.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-ntp-yang-data-model)

Changed document external resources from:

yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ntp@2020-07-13.yang (Yang catalog entry for ietf-ntp@2020-07-13.yang)
yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-ntp@2020-07-13.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-ntp-yang-data-model)

to:

yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ntp@2022-02-10.yang (Yang catalog entry for ietf-ntp@2022-02-10.yang)
yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-ntp@2022-02-10.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-ntp-yang-data-model)

[Ballot comment]
Thank you for the work put into this document. With the update of the normative references, I have cleared my blocking DISCUSS (kept it in the notes for archival only).

Special thanks for Dieter Sibold as the document shepherd write-up includes text about the WG consensus.

Please find below one blocking DISCUSS point (but really trivial and easy to address), some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== previous DISCUSS (kept only for archive)

-- Section 13.1 --
As RFC 7317 is imported by the YANG module, it must be a normative reference.

== COMMENTS ==

Should the NTP version(s) be mentioned in the abstract ?

-- Section 1 --
The text appears to indicate that the associations can be configured while the tree diagram indicateds tha associations are read-only. Should the associations text moved to the section 1.1 (i.e., operational states) ?

-- Section 1.5 --
Using a table for listing references is unusual. Is there a reason why this form is used ?

-- Section 8 --
Should there be more constraints on "ntp-version" ? I.e., a minimum of 3 ?

[Ballot comment]
Hi,

Thank you for this document.  It is always nice to see another YANG model being standardized.  I would also like to thank both Andy, for his YANG Doctor review, and Tom for his help on reviewing and improving the YANG model.

I have only a few questions/comments on the draft itself.

Section 5 talks about Access Rules, and I didn't know whether it might be helpful to indicate that this section is referring only to on-the-wire peer access control, and is independent of any management API access control, that could be enabled by, e.g., NACM (8341)?

It is good to report the NTP statistics, but it might also be helpful to define an action to allow clients to reset those statistics, although this could be deferred to a future revision.

Finally, I note that there was another NTP related draft on the telechat this week, (draft-ietf-ntp-interleaved-modes-05), that suggests that "interleaved symmetric mode" should be configured.  Does this YANG model cover configuring that option, or would this be regarded as future work?

Regards,
Rob

[Ballot discuss]
Does the 'poll' leaf contain a value measured in seconds as currently
stated, or a log2 seconds value (what the "8-bit signed integer" of that
name in RFC 5905 holds)?  If the former, it should be a wider type than
uint8 in order to be able to represent the full set of values.

Let's also take another look at the use of nacm:default-deny-all for
sensitive authentication-related nodes.  My understanding is that
typically we only block of the actual secret key material in this way
and let the associated metadata (key names, algorithms, etc.) be
retrieved.  The current module may have default-deny-all in more places
than is needed, and we show an example of retrieving key information
that ought to have been denied by this ACL.

It seems that the current module does not use RFC 8177 key-chain
functionality (despite listing RFC 8177 as a reference).  It seems that
best practices for cryptographic configuration would be to use the
key-chain functionality, though I may be misunderstanding things.

[Ballot comment]
I support Francesca's Discuss.

We describe a couple of reported values as an "offset"; it would be good
to be very clear about what the sign of this value indicates (i.e., if
the value is positive, which timestamp is nominally after the other).

Section 3

We list a mapping of YANG nodes and MIB objects, but will the respective
data types be trivially relatable?

Section 6

This would be a great place to mention that nacm:default-deny-all is
used to prevent retrieval of the actual key information after it is set.

Section 7

I confess that I rather expected some note that NTPv3 (or at least RFC
1305) is classified as obsolete.

Section 8

  identity uc-server {
    if-feature "unicast-configuration";
    base unicast-configuration-type;
    description
      "Use client association mode. This device
      will not provide synchronization to the
      configured NTP server.";

A little jarring to have the node name be "server" but the description
say "client".  Perhaps some more explanation could be given?

  identity clock-not-set {
    base ntp-sync-state;
    description
      "Indicates the clock is not updated.";

The closest analogue to this that I could find in RFC 5905 is "#define
NSET            0      /* clock never set */", and there seems to be a
significant difference between "not" and "never", so I'm not sure if
this is correct.

  identity hmac-sha-1-12 {
    base crypto-algorithm;
    description
      "The HMAC-SHA1-12 algorithm.";

While HMAC-SHA1 is not known to be broken, the truncated authentication
tag is perhaps not up to best current practices and in some situations
there is some value in being able to say that SHA-1 is entirely unused.
Did we consider gating this algorithm behind "if-feature deprecated" as
well?

  identity hmac-sha-1 {
    base crypto-algorithm;
    description
      "HMAC-SHA-1 authentication algorithm.";

(only half of the above concerns would apply here, of course)

  grouping key {
    description
      "The key.";
    nacm:default-deny-all;
    choice key-string-style {
      description
        "Key string styles";
      case keystring {
        leaf keystring {
          type string;
          description
            "Key string in ASCII format.";

There is perhaps some argument that ASCII key strings should be gated by
"deprecated" as well...

  grouping authentication-key {
    description
      "To define an authentication key for a Network Time
      Protocol (NTP) time source.";
    nacm:default-deny-all;

(Per the Discuss) why does the key metadata like key-id and algorithm
need to be default-deny-all?  Typically in YANG modules we only apply
this strict restriction to the actual secret key data but not the
metadata.

    leaf istrusted {
      type boolean;
      description
        "Key-id is trusted or not";
    }

Where are the semantics of "is trusted" specified?  The reference for
the overall grouping, §7.3 of RFC 5905, does not use the word "trust" or
any words with that stem.

  grouping authentication {
    description
      "Authentication.";
    choice authentication-type {
      description
        "Type of authentication.";
      case symmetric-key {

We currently only have the one case listed.  Is the work in progress for
other authentication types that would give motivation for providing this
extension point?

  identity aes-cmac {
    base crypto-algorithm;
    description
      "The AES-CMAC algorithm - required by
      RFC 8573 for MAC for the NTP";
    reference
      "RFC 4493: The AES-CMAC Algorithm";

I suspect that RFC 8573 is a more useful reference for the semantics of
this YANG element than RFC 4493 is.

  grouping common-attributes {
    description
      "NTP common attributes for configuration.";
    leaf minpoll {
      type int8;
      default "6";
      description
        "The minimum poll interval used in this association.";
      reference
        "RFC 5905: Network Time Protocol Version 4: Protocol and
        Algorithms Specification, Section 7.2";
    }
    leaf maxpoll {
      type int8;
      default "10";
      description
        "The maximum poll interval used in this association.";
      reference
        "RFC 5905: Network Time Protocol Version 4: Protocol and
        Algorithms Specification, Section 7.2";

The referenced section seems to define MINPOLL and MAXPOLL as 4 and 17,
respectively.  I assume that the different default values given here
were discussed in the WG.

    leaf port {
      if-feature "ntp-port";
      type inet:port-number {
        range "123 | 1025..max";

It's not entirely clear that prohibiting the use of non-123 "system
ports" is needed at the YANG level.  (Seems to occur more than once.)

        leaf access-mode {
          type identityref {
            base access-mode;
          }

          description
            "NTP access mode. The definition of each possible value:
            peer: Both time request and control query can be
            performed.
            server: Enables the server access and query.
            synchronization: Enables the server access only.
            query: Enables control query only.";

It feels a little unusual to duplicate the description of the various
access-mode-derived YANG identities in the description here.

    container clock-state {
      config false;

We had a comment "/* Configuration data nodes */" above the toplevel ntp
presence-container, which contains this clock-state container.  So
perhaps it is appropriate to have another comment here demarcating the
transition away from configuration nodes?

        leaf clock-state {
          [...]
          description
            "The state of system clock. The definition of each
            possible value is:
            synchronized: Indicates local clock is synchronized.
            unsynchronized: Indicates local clock is not
            synchronized.";

[same comment about identities/descriptions]

      leaf reach {
        type uint8;
        description
          "The reachability of the configured
          server or peer.";
        reference
          "RFC 5905: Network Time Protocol Version 4: Protocol and
          Algorithms Specification, Section 9.2 and 13";
      }
      leaf unreach {
        type uint8;
        description
          "The unreachability of the configured
          server or peer.";
        reference
          "RFC 5905: Network Time Protocol Version 4: Protocol and
          Algorithms Specification, Section 9.2 and 13";

These two nodes hold qualitatively different values, yet we use
essentially the same language to describe them.  This seems needlessly
confusing.  ('reach' is an 8-bit shift register that tracks packet
generation and receipt, whereas 'unreach' is a count of how long the
'reach' value has been zero.)  I think we should use more detailed
descriptions, and probably provide the units (seconds) for 'unreach' as
well.

      leaf now {
        type uint32;
        units "seconds";
        description
          "The time since the last NTP packet was
          received or last synchronized.";

The standalone word "now" doesn't appear in RFC 5905 in any location
that this might be referring to.  I'm pretty confused at how what is
described here relates to the protocol specification and why it is of
interest to expose in the data model.

      leaf dispersion {
        [...]
        reference
          "RFC 5905: Network Time Protocol Version 4: Protocol and
          Algorithms Specification, Section 10";

For the "root-dispersion" leaf earlier, we listed as references Sections
4 and 7.3 of RFC 5095; Section 10 seems a bit more helpful as it goes
into how the value is actually calculated and used.  I wonder if it
makes sense to reference section 10 as well as 4 and 7.3 for
"root-dispersion".

          description
            "Configuration of broadcast-client.";
          reference
            "RFC 5905: Network Time Protocol Version 4: Protocol and
            Algorithms Specification, Section 3.1";
        }

Why are there no leafs within the broadcast-client container?  Is there
really no configuration at all (authentication?  port?) and no state to

Section 9.3

Thank you for providing an example using strong cryptographic
authentication!

However (per the discuss), I'm not sure how the example of retrieving
the authentication-related configuration is consistent with the
nacm:default-deny-all ACL that is applied to "grouping key", and we
probably shouldn't be indicating that retrieving active keys is an
example of something that people should do.

Section 11

      /ntp/authentication/authentication-keys - The entries in the list
      includes all the NTP authentication keys.  This information is
      sensitive and can be exploited and thus unauthorized access to
      this needs to be curtailed.

Typically we would mention that due to the sensitivity the
nacm:default-deny-all policy is applied, to prevent their being read
out.  (Roman's suggestions are also good.)

In a similar vein to Roman's comments, it seems that changing the
/ntp/interfaces configuration could lead to performing time
synchronization over untrusted external interfaces and not performing
time synchronization over trusted internal interfaces, which can be
security-relevant.

Section 13.1

It's not clear to me that RFC 5907 needs to be classified as normative,
since all we say about it is that a mapping is possible between subsets
of the MIB and the YANG.

Likewise, RFCs 6241, 6242, and 8040 are just examples of how the YANG
module could be used/accessed, and are not required in order to
implement any part of the YANG module.


NITS

I'm leaving out a number of things that I expect the RFC Editor staff to
find.

Section 1

  interface parameters.  It also provides information about running
  state of NTP implementations.

Pedantically, I would say that the data model "provides access to
information" about the running state; the data model itself is an
abstract thing that is disconnected from what happens operationally.

Section 2

I think the line for /ntp/interfaces got inadvertently removed from the
abbreviated tree diagram.

Section 8

  feature deprecated {
    description
      "Support deprecated MD5-based authentication (RFC 8573) or
      SHA-1 or any other deprecated authentication.

"any other deprecated authentication mechanism"

      It is enabled to support legacy compatibility when secure
      cryptographic algorithm is not availaible to use.";

"secure cryptographic algorithms are not available to use".

    description
      "This defines NTP access modes. These identifies
      how the ACL is applied with NTP.";

s/identifies/identify/

    list associations {
      [...]
      leaf address {
        type inet:ip-address;
        description
          "The address of this association. Represents the IP
          address of a unicast/multicast/broadcast address.";

I wonder if we want to use the word "remote" or "peer" in here in some
form.

      leaf isconfigured {
        type boolean;
        description
          "Indicates if this association is configured or
          dynamically learned.";

I suggest adding "(true)" and "(false)" after "configured" and
"dynamically learned", respectively.

      list interface {
        [...]
        container broadcast-server {
          if-feature "broadcast-server";
          presence "NTP broadcast-server is configured";

Perhaps "on this interface" would make sense?

          container authentication {
            if-feature "authentication";
            description
              "Authentication used for this association.";
            uses authentication;

I think s/for this association/on this interface/ (since this is still
under "list interface").

        container broadcast-client {
          if-feature "broadcast-client";
          presence "NTP broadcast-client is configured.";

As for broadcast-server, perhaps "on this interface"?
report?

  This example describes how to get all association present in the
  system -
  [...]
 
   
     
       

192.0.2.1

          [...]

This may well just be my ignorance, but I how does one detect the
boundary between associations inside the  element?  Should
there be a containing (e.g.)  element around each one?  (I
see that there is only one in this example.)

[Ballot comment]
I support Francesca and Eric's DISCUSS positions.  I was also tempted to repeat what Zahed said but make it a DISCUSS; please reply to his comment about RFC 1305.

IMHO, it would help to break Section 10 into a different subsection for each IANA action.

[Ballot discuss]
Thank you for the work on this document.

I have a simple-to-solve DISCUSS point, and some non blocking comments.

Francesca


1. -----

        leaf clock-precision {
          type int8;
          units "Hz";

FP: I believe the units should be seconds here.

[Ballot comment]
2. -----

  typedef ntp-date-and-time {
    type union {
      type yang:date-and-time;
      type uint8;
    }
    description
      "Follows the normal date-and-time format when valid value
      exist, otherwise allows for setting special value such as
      zero.";


FP: I'd rather the document avoided the term "normal", which could be just removed. Also, could a 'reference' be added, pointing to RFC 6991?

3. -----

        "The association was configured or dynamic
        which result in clock synchronization.";

FP: This sentence doesn't parse correctly for me. Is there any text missing? Or maybe a wrong copy paste?

4. -----

      description
        "Configuration to control access to NTP service
        by using NTP access-group feature.
        The access-mode identifies how the acl is
        applied with NTP.";

FP: (here and other places) please make sure the capitalization of ACL is consistent in the descriptions and in the text of the doc.

[Ballot comment]
Thanks for the efforts on this document.

I support Éric Vyncke's discuss.

I also think adding reference to RFC 1305 in section 5 and section 6 creates a bit of confusion when this document says it defines YANG model for RFC 5905. Also it is a fact that RFC 1305 is obsoleted by RFC 5905. So is this yang model also applicable to NTPv3? if not please mention, if so please mention and consider removing references to RFC 1305.

[Ballot comment]
Thank you to Takeshi Takahashi for the SECDIR review.

** YANG.  feature deprecated.  Typo. s/availaible/available/

** YANG.  Crypto algorithms. AES-CMAC has a reference but the others don’t.  Consider adding them.

** Section 9.1. Typo. s/would used the an/would use an/

** Section 11.

A few clarifying items on describing the sensitivity of nodes:

For writable nodes:
-- /ntp/authentication/authentication-keys:  The entries in the list includes all the NTP authentication keys.  Altering this list could cause a disruption for clients and peers (for servers); or prevent a client from accessing a server.

For readable notes:

-- /ntp/authentication/authentication-keys. Recommend being clearer on the risk:

s/can be exploited/can be exploited to permit unauthorized access to the NTP service/

-- /ntp/authentication and /ntp/access-rules - The entries in the list include the authentication and access control configurations.  Exposure of these nodes could reveal network topology or trust relationship.

[Ballot discuss]
Thank you for the work put into this document.

Special thanks for Dieter Sibold as the document shepherd write-up includes text about the WG consensus.

Please find below one blocking DISCUSS point (but really trivial and easy to address), some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 13.1 --
As RFC 7317 is imported by the YANG module, it must be a normative reference.

[Ballot comment]
Should the NTP version(s) be mentioned in the abstract ?

-- Section 1 --
The text appears to indicate that the associations can be configured while the tree diagram indicateds tha associations are read-only. Should the associations text moved to the section 1.1 (i.e., operational states) ?

-- Section 1.5 --
Using a table for listing references is unusual. Is there a reason why this form is used ?

-- Section 8 --
Should there be more constraints on "ntp-version" ? I.e., a minimum of 3 ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ntp-yang-data-model-12. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-ntp
URI: urn:ietf:params:xml:ns:yang:ietf-ntp
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-ntp
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ntp
Prefix: ntp
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-12):

From: The IESG
To: IETF-Announce
CC: Dieter Sibold , draft-ietf-ntp-yang-data-model@ietf.org, dsibold.ietf@gmail.com, ek.ietf@gmail.com, ntp-chairs@ietf.org, ntp@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for NTP) to Proposed Standard


The IESG has received a request from the Network Time Protocol WG (ntp) to
consider the following document: - 'A YANG Data Model for NTP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model for Network Time Protocol
  (NTP) implementations.  The data model includes configuration data
  and state data.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ntp-yang-data-model/



No IPR declarations have been submitted directly on this I-D.

I have requested a YANG doctors review of -09 (last I saw was for -03).
Below are just a few questions and comments, but otherwise I think a
draft -10 is ready to go to IETF LC.


[[ questions ]]

[ section 7 ]

* Why does ntp-version default to "3" and not "4", given the references
  to RFC 5905?

  If the default does change from 3 to 4 then I think some of the examples
  may need updating (section 8.5 multicast client, for one).

* Can this YANG model be used to do all/most of things discussed in the
  mode 6 commands document?


[[ nits ]]

[ section 1 ]

* s/convers configuration/covers configuration/

* "parameters of per-interface" -> "per-interface parameters" ??

[ section 1.1 ]

* This sentence was a little unclear to me:

  "Additionally, the operational state also include the associations state."

  I may misunderstand, but I suggest:

  "The operational state includes NTP association state."

[ section 5 ]

* "allow such" -> "allows such"

[ section 6 ]

* "key-id is 32-bits unsigned integer" ->
  "key-id is a 32-bit unsigned integer"

[ section 7 ]

* "Enables the full access authority" -> "Enables full access authority"

* "Enables the server access and query" ->
  "Enables server access and control queries" perhaps?

* "Enables the server to access" -> "Enables basic server access" ?

[ section 8.1 ]

* s/2001:DB8::1/2001:db8::1/

  RFC 5952 section 4.3 specified lowercase hexadecimals.

This is the publication request and document shepherd write up for:

A YANG Data Model for NTP
draft-ietf-ntp-yang-data-model-09

Prepared by: Dieter Sibold,  11 August 2020 

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

This is a YANG data model for NTP. As such it provides configuration of NTP instances and provides information of about running state of NTP implementations

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines a YANG data model for Network Time Protocol (NTP) implementations.  The data model includes configuration data and state data.

Working Group Summary:

The document has working group consensus for publication. It has been reviewed by several WG participants since its initial adoption as a working group item. It has received review from YANG experts.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No

Document Quality:

This document has been reviewed and revised several times during its development. Version 03 have been submitted for a YANGDOCTOR Early review. The overall result was "Almost Ready". The findings of the review have been considered by the authors and incorporated into subsequent versions of the draft.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


There are no existing implementations of this YANG module. According to the authors implementations are currently planned. A YANGDOCTORS review was requested prior to WGLC in order to enhance the review process with the opinion of an YANG expert.

Personnel:

Dieter Sibold is acting as the Document Shepherd.  Erik Kline is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the final document and feels this document is more than ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd is comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There are no IPR filings on this document. The document shepherd has received confirmation from all the authors that they are in full conformance with the provisions of BCP78 and BCP79 with respect to IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no IPR disclosures for this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents consensus of the working group. Note that the members of the working group are not YANG experts. For that reason the YANGDOCTORS Early review was requested.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The Document shepherd run ID nits. Findings: there are currently six warnings about weird spacings. These can be fixed during subsequent iterations of the document.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The version 03 of the document has been submitted for YANGDOCTORS Early Review. It past the review with the result "Almost Ready". The review may be accessed via: https://datatracker.ietf.org/doc/review-ietf-ntp-yang-data-model-03-yangdoctors-early-bierman-2018-10-08/
Issues revealed by this review have been addressed by the authors.

(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative and informative references.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are completed.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downrefs.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requires the registration of a URI in the "IETF XML Registry". Additionally, it registers a YANG module in the "YANG Module Names" registry. All the actions specified are consistent with the document and reasonably specified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The documents contains a YANG module. This was successfully validated by datatracker's automatic YANG Validation.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document contains the YANG module "ietf-ntp". This module have been successfully validated by the pyang tool at 2020-07-13. See: https://datatracker.ietf.org/doc/draft-ietf-ntp-yang-data-model/
Compliance to RFC8342: The YANG module comply with RFC8342.

This is the publication request and document shepherd write up for:

A YANG Data Model for NTP
draft-ietf-ntp-yang-data-model-09

Prepared by: Dieter Sibold,  11 August 2020 

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

This is a YANG data model for NTP. As such it provides configuration of NTP instances and provides information of about running state of NTP implementations

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines a YANG data model for Network Time Protocol (NTP) implementations.  The data model includes configuration data and state data.

Working Group Summary:

The document has working group consensus for publication. It has been reviewed by several WG participants since its initial adoption as a working group item. It has received review from YANG experts.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No

Document Quality:

This document has been reviewed and revised several times during its development. Version 03 have been submitted for a YANGDOCTOR Early review. The overall result was "Almost Ready". The findings of the review have been considered by the authors and incorporated into subsequent versions of the draft.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


There are no existing implementations of this YANG module. According to the authors implementations are currently planned. A YANGDOCTORS review was requested prior to WGLC in order to enhance the review process with the opinion of an YANG expert.

Personnel:

Dieter Sibold is acting as the Document Shepherd.  Erik Kline is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the final document and feels this document is more than ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd is comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There are no IPR filings on this document. The document shepherd has received confirmation from all the authors that they are in full conformance with the provisions of BCP78 and BCP79 with respect to IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no IPR disclosures for this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents consensus of the working group. Note that the members of the working group are not YANG experts. For that reason the YANGDOCTORS Early review was requested.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The Document shepherd run ID nits. Findings: there are currently six warnings about weird spacings. These can be fixed during subsequent iterations of the document.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The version 03 of the document has been submitted for YANGDOCTORS Early Review. It past the review with the result "Almost Ready". The review may be accessed via: https://datatracker.ietf.org/doc/review-ietf-ntp-yang-data-model-03-yangdoctors-early-bierman-2018-10-08/
Issues revealed by this review have been addressed by the authors.

(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative and informative references.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are completed.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downrefs.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requires the registration of a URI in the "IETF XML Registry". Additionally, it registers a YANG module in the "YANG Module Names" registry. All the actions specified are consistent with the document and reasonably specified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The documents contains a YANG module. This was successfully validated by datatracker's automatic YANG Validation.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document contains the YANG module "ietf-ntp". This module have been successfully validated by the pyang tool at 2020-07-13. See: https://datatracker.ietf.org/doc/draft-ietf-ntp-yang-data-model/
Compliance to RFC8342: The YANG module comply with RFC8342.