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

Thank you for the work on this document and for addressing my DISCUSS and COMMENTs.

Francesca

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.

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.

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.

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 ?

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

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