Time Capability in NETCONF
RFC 7758

Note: This ballot was opened for revision 08 and is now closed.

(Joel Jaeggli) (was No Objection, Discuss, Yes) Yes

Comment (2015-11-07)
No email
send info
No longer see a reason to hold this up for the discussion which went fine with respect to the registry policy change.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2015-09-17 for -08)
No email
send info
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.

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-09-16 for -08)
No email
send info
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?

(Benoît Claise) No Objection

Comment (2015-09-17 for -08)
No email
send info
- 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

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-09-17 for -08)
No email
send info
3.7 could really do with an example and is underspecified
(where does it say what the digits represent?)

(Brian Haberman) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2015-10-12 for -08)
No email
send info
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.

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Comment (2015-09-17 for -08)
No email
send info
FWIW, I support Barry's DISCUSS and (as Ben) would like to see something about the experiment expectations.