Ballot for draft-mm-netconf-time-capability
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
No longer see a reason to hold this up for the discussion which went fine with respect to the registry policy change.
I share Barry's concern and am also interested in the experimental aspects. How would netconf evaluate the experiment? I did find the draft well written and addressing a good set of problems.
FWIW, I support Barry's DISCUSS and (as Ben) would like to see something about the experiment expectations.
The registration policy for the NETCONF Capability URNs registry is Standards Action, and this document, with Experimental status, does not meet the requirement that the registration come from a Standards Track RFC. This document cannot make that registration. After discussion about whether the IESG should make an exception in this case and allow the registration, I agree that it's the right thing to do for this document, so I've cleared my DISCUSS ballot on that point. But at the same time, it seems that the registration policy is too strict, and should be IETF Review, which allows the NETCONF working group to make the decision by getting IETF consensus on the registration -- there's no need to specifically require a Standards Track RFC. To that end, I've submitted an Internet draft, draft-leiba-netmod-regpolicy-update, which I ask the Network Operations AD to sponsor, in coordination with the NETCONF working group.
It would be helpful to see a few words about the nature of the experiment, even if that is just something to the effect of "get deployment experience to decide if this is really a good idea". Or more to the point, is there an expectation that we will learn something from this, and perhaps consider it for standards track in the future?
- There was not sufficient support to adopt draft-mm-netconf-time-capability in NETCONF. Nevertheless, I'm happy to see some feedback on this draft during the IETF LC It seems that Joel and I missed Barry's point (https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/#barry-leiba) though. - "Typical synchronization protocols, such as the Network Time Protocol ([NTP], [RFC5907]) provide the means to verify that a clock is synchronized to a time reference by querying its Management Information Base (MIB)." Provide a reference to the YANG model as well: https://tools.ietf.org/html/rfc7317 | +--rw ntp! | +--rw enabled? boolean | +--rw server* [name] | +--rw name string | +--rw (transport) | | +--:(udp) | | +--rw udp | | +--rw address inet:host | | +--rw port? inet:port-number | +--rw association-type? enumeration | +--rw iburst? boolean | +--rw prefer? boolean
3.7 could really do with an example and is underspecified (where does it say what the digits represent?)