Ballot for charter-ietf-netconf
Block
Yes
No Objection
No Record
Summary: Has 3 BLOCKs. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Is this charter ready for external review?"
There are no milestones.
The intended publication status for the potential work items is missing. AFAIK, in the list of "responsibilities" of the WG, all listed items are for maintenance (see COMMENTS below), but `zero-touch provisioning and the related call home functions.` is probably brand new. Will there be an informational requirements I-D and a proposed standard "solution" ?
Suggest to work on the following comments: Should "maintenance and extensions" be added to `The network management protocol NETCONF` ? What is 'parity' in `The NETCONF working group should maintain parity ` ? I guess "features" but let's be specific. s/NETCONF related specifications/NETCONF-related specifications/ ? What is `data model-driven protocols` ? Is it on purpose that `data models` is used rather than "YANG data models" ?
Hi all, Please find below some comments about the proposed charter: # Parity CURRENT: The NETCONF working group should maintain parity between the NETCONF and RESTCONF protocols. # What are the concrete implications of this change on the work to be done in NETCONF? # Is this about systematically defining (requiring) duplicated functionality for both NETCONF/RESTCONF? Is that justified given that these protocols are used today in distinct deployment contexts/layers? # To what extent this change impact the design spirt of RESTCONF? Specifically: RFC8040 says the following: RESTCONF does not need to mirror the full functionality of the NETCONF protocol, but it does need to be compatible with NETCONF. RESTCONF achieves this by implementing a subset of the interaction capabilities provided by the NETCONF protocol -- for instance, by eliminating datastores and explicit locking.
# Stale text OLD: The NETCONF Working Group, previously named after the NETCONF protocol, now renamed as the NETwork CONFiguration Working Group, NEW: The NETwork CONFiguration (NETCONF) Working Group, # As parity is put forward, it is weird that only NETCONF is listed here: CURRENT: The NETCONF protocol is data modeling language independent, but YANG (RFC 7950) is the recommended NETCONF data modeling language, which introduces advanced language features for configuration management. Maybe tweak this to say NETCONF/RESTCONF are YANG-based network management protocols. Cheers, Med
I'm unsure what is intended by "The transports and encodings used by the data model-driven protocols", as currently specified. This doesn't seem like it is defining new transport protocols, at least I am hoping that this is a mapping to IETF Standard Protocols, not the creation of new "transports".
Please add milestones. The current charter doesn't have them either.