abierman-netconf-mar04 1 NETCONF WG 59th IETF Seoul, Korea March 3, 2003 March 4, 2003

abierman-netconf-mar04 2 NETCONF WG Details l Mailing List »Discussion: »Subscribe: –‘subscribe’ in the message body »Archive: l WG Chairs »Simon Leinen »Andy Bierman l WG Charter Page » l WG Home Page » l WG Issues List »

abierman-netconf-mar04 3 NETCONF Drafts l WG Internet Drafts: »NETCONF Configuration Protocol –draft-ietf-netconf-prot-02.txt »BEEP Application Protocol Mapping for NETCONF –draft-ietf-netconf-beep-00.txt »NETCONF Over SOAP –draft-ietf-netconf-soap-01.txt »Using the NETCONF Configuration Protocol over Secure Shell (SSH) –draft-ietf-netconf-ssh-00.txt

abierman-netconf-mar04 4 NETCONF WG Agenda l Status Reports on NETCONF related activity »RIPE47 meeting (Simon Leinen) »NANOG30 meeting (Eliot Lear) »Netconf Data Model work (Sharon Chisholm) l Document Updates »NETCONF Configuration Protocol (Rob Enns) »NETCONF Over SOAP l Resolution of Hottest Issue List Items »The full issue list can be found at: l Conformance Issues »WG Document MUSTs, SHOULDs, MAYs »Mandatory-to-implement application substrate

abierman-netconf-mar04 5 Resolution of Hottest Issue List Items l 1.4) Dual-role implmenetations l 1.5) Validation conformance l 5.1) End of message directive l 5.2) SSH Port Assignment l 7.1) Need to compile a list of criteria then prioritize the list l 7.1a) Mandatory-to-implement application substrate l 8.1) (Operation set) l 8.1a) l ) Confirmed commit l ) URI vs. URN l ) Rollback capability l 12.6) l ) Error codes l 13.3) l ) Error handling for lock l any) any other issues on the list people want to discuss

abierman-netconf-mar ) Dual role implementations l A single host should be capable of concurrently supporting NETCONF sessions originating and terminating on that host l Proposed consensus: »Require the application substrate documents to define how session roles are established at connection setup time »Remove the #manager and #agent capabilities

abierman-netconf-mar ) Validation conformance l The protocol document is fairly vague on what an agent does for, test-option==test-then-set or for the operation. l Proposal: »Clarify the document text on "syntax check" –At a minimum, the data type and any restrictions (sub-range, pattern, list of enums, etc.) matches the expected syntax –At a maximum, verifies that an instance document conforms to an indicated XSD (checking any possible syntax requirement expressible in an XSD) »Future data model work can further clarify requirements for referential integrity checks

abierman-netconf-mar ) End of message directive l Should an end-of-message directive be used to provide an easier message framing mechanism than parsing the entire XML instance document to find the proper end tag? l After lots of discussion, there seems to be consensus that we should: »have a NETCONF-specific framing mechanism for SSH »select a sequence that is not legal in a CDATA section and not rely on a low probability of the sequence occurring accidentally l Proposed consensus »The string "]]>]]>" will be used as the EOM marker

abierman-netconf-mar ) SSH port assignment l 5.2.1) Default Port Number »A default server port assignment is needed for NETCONF over SSH. »Should this be the SSH port? A new port number from IANA? »Proposed consensus: –Get a new port assignment from IANA l 5.2.2) Port number configuration »The server port assignment is usually configurable. How much effort should the WG put into standardized configuration of this port assignment? »Proposed consensus: –Document will say the implementations SHOULD allow the server port assignment to be configurable in some manner. Any further specification is future work.

abierman-netconf-mar ) Need to compile a list of criteria… l Choice of mandatory to implement application substrate l Proposed consensus: »Operator requirements should be considered the highest priority »Implementation costs for developers are likely to be close enough for each choice that this cannot be used as the deciding factor »Operator preference is clearly SSH

abierman-netconf-mar a) Mandatory-to-implement choice l Need to select the mandatory-to-implement application substrate for NETCONF l Proposed consensus »Manager and agent MUST implement SSH »Manager and Agent MAY implement BEEP »Manager and Agent MAY implement SOAP

abierman-netconf-mar ) (Operation set) l There is some concern that the operation set is too configuration specific (e.g., explicit commands edit-config, get-config) »Proposal is to make commands generic (e.g.,, ) and make the target part of the parameter set l Concerns: »NETCONF is chartered to focus on configuration, so explicit commands are not unreasonable »The WG discussed this issue in detail at the interim meeting and made a deliberate decision to favor interoperability and inhibit vendor extensibility to the protocol operations »The parameters (syntax and semantics) will not be the same for all possible targets »Many combinations of operation and target to not make sense (e.g. copy state) l Proposed consensus: »Leave operation set as-is

abierman-netconf-mar a) l There is no explicit mechanism to edit non-configuration data, other than directly using the wrapper »The WG removed this operation because of lack of consensus on all the details »The wrapper can be used for "exec" commands such as rebooting a module, clearing a serial line, removing an entry from the ARP cache l Proposed consensus: »Any additional support for will be deferred to a future release

abierman-netconf-mar ) Confirmed commit l ) Confirmed commit »This feature has to be decoupled from the #candidate capability because it is an implicit rollback »The #rollback capability has to be defined and documented or this feature has to be removed l Proposed consensus: »Remove the confirmed commit feature, since rollback is not fully defined yet

abierman-netconf-mar ) URI vs. URN l We should use URNs for identifying namespaces. There is already a registration mechanisms in place for URN protocol parameters (RFC 3553). l Proposed consensus: »Consider using URNs instead of URIs »Need details and examples

abierman-netconf-mar ) Rollback capability l Rollback (revert the running configuration to a previous known state) is a desired feature »Not weel defined at this time »Interactions with locking not well defined l Proposed consensus: »Do not add any rollback functionality to the protocol at this time

abierman-netconf-mar ) l Some details need to be clarified: »Set of proper elements –Semantics, syntax, mandatory/optional »Need capability to include error indications at netconf protocol and application layers –General application errors and data-model specific errors »Inclusion of multiple rpc-error elements per rpc-reply »Associating specific user data in a config block with a specific rpc- error –Use of edit-path vs. containment hierarchy l Proposed consensus: »Clarify existing fields and provide standard content »Provide application and data model error "containers" which can contain non-standard messages and other information

abierman-netconf-mar ) Error codes l Need a set of standard error indications »Look at other schemes for error reporting, such as SNMP, HTTP »Look at the IANAItuProbableCause in the ALARM-MIB l Must have reasonable error set defined to finish 1.0 l Action item: »Andy (and maybe others?) to propose suggested standard errors to the mailing list

abierman-netconf-mar ) l The set of operation attribute values for edit-config should be improved to allow for explicit create and modify operations l Proposed consensus: »operation: (create | modify | merge | replace | delete) [default: merge] »Create will fail if the indicated config data already exists »Modify will fail if the indicated config data does not exist »Merge and replace will cause an implicit create if the indicated config data does not exist –Merge X with nothing or replace nothing with X works out the same »Delete will fail if the indicated config data does not exist l Text regarding mixing different operation values is too restrictive »Change MUST to MAY or remove text altogether

abierman-netconf-mar ) Error handling for l Need to clarify error handling and requirements for the lock operation l Proposed consensus: »Locking applies to all access mechanisms (e.g., SNMP, CLI, NETCONF, etc.) »Implementations may choose to hide locking from CLI users, but the CLI sub-system must still use the locking mechanism »The discard-changes parameter added to the lock operation should be removed (agent always discards changes to the candidate if they are abandoned by the session) »The session-id zero will be used in an "lock failed" rpc-error to indicate that the lock is owned by a non-NETCONF entity