NETCONF WG minutes for IETF #60

[Andy Bierman <abierman@cisco.com>]

OPS Area
NETCONF WG Meeting Minutes
IETF #60
August 5, 2004
Minutes by Sharon Chisolm, Eliot Lear, and Andy Bierman

Chairs
------

Andy Bierman <abierman@cisco.com>
Simon Leinen <simon@switch.ch>

Review Material
---------------

NETCONF Configuration Protocol
<draft-ietf-netconf-prot-03.txt>

BEEP Application Protocol Mapping for NETCONF
<draft-ietf-netconf-beep-01.txt>

NETCONF Over SOAP
<draft-ietf-netconf-soap-02.txt>

Using the NETCONF Configuration Protocol over Secure Shell (SSH)
<draft-ietf-netconf-ssh-01.txt>

Agenda
------

  - Report on NETMOD BOF (Sharon Chisholm, 15 min)
  - Security Issues  (Wes Hardaker, 15 min)
  - Discussion of WG Documents (50 min)
  - Next Steps (10 min)

Minutes
-------

0) Agenda bashing

There was some minor agenda bashing, and as a result, 
the Security Issues discussion was held first.  

1) Netconf Protocol: Security Considerations

Wes Hardaker presented some issues related to authentication and 
access control.  Refer to the slides and the jabber logs for
more details.

1.1) Access Control Requirements

There is language in the protocol document that implies (or requires)
that the access control must be the same for CLI and NETCONF.  
The Editor needs to clarify the relevant text.  The WG must decide 
how strong a requirement is needed (MUST be the same, SHOULD be the
same, MUST be mappable, etc.,).

1.2) Global Locking

A lesser-privileged user can obtain a lock and hold it, which
can be a denial-of-service attack against higher-priveleged
users.  The WG has already discussed this issue in the past
and decided that partial locking requires canonical object
and instance naming across all access modes (SNMP, CLI, etc.),
and this is an issue the NETMOD WG should address.

1.3) Netconf Protocol Chaining

Some NETCONF protocol operations work on remote datasets
(e.g., copy-config and URL based edit-config).
This is not a new issue, but the Editors need to make sure
acceptable protocol type values (e.g., ftp, http) for URL 
based operations are documented in the Security Considerations
section.

1.4) Exposure Through Error Messages

There is a concern that error messages produced for
operations such as <validate> should not expose any
configuration details for portions of the data model
that the user invoking the operation does not have
access rights to view.

1.5) NETCONF Usage Proposal 

There was a proposal that "Netconf 1.0 MUST NOT be used in 
restricted-role environments".  The WG did not agree to this 
proposal.  Security considerations should explain the potential
risks for various types of usage.  Granular locking will be
considered in the future.

2) NETMOD BOF Report

Sharon Chisholm presented a summary of the NETCONF Data
Modelling BOF (NETMOD). Refer to the slides and the jabber 
logs for more details.

NETMOD web page is http://standards.nortelnetworks.com/netconf
Mailing list is netconfmodel@lyris.nortelnetworks.com
to subscribe, lyris@lists.nortelnetworks.com

The NETCONF WG is not chartered to standardize a data modelling
language or domain-specific data models.  The proposed NETMOD WG
charter would address this "content" layer.  Some of the issues
in the problem statement:
  - what are common ways of specifying compliance?
  - backwards compatibility
  - how do we deal with access control?
  - how do we describe relationships?

The NETMOD WG will look at W3C XML schema
two initial drafts
one is SMI for NETCONF
some sort of meta model or abstract data model will drive

There were four presentations and lots of discussion at the
NETMOD BOF.  Refer to the proceedings for details.
There is strong interest in leveraging existing technologies,
but not so much agreement on which technologies.  Some evaluation 
needs to be done in this area.  The group refined the proposed
charter text and also discussed the need for volunteers in various
areas of expertise.  People interested in participating should
contact Sharon Chisholm (see NETMOD WEB page above).

There is some potential impact on the NETCONF protocol document,
related to the NETMOD work:
  - Removal of Section 7 of the protocol draft
    (move the XML usage restrictions into another place)
  - syntactic naming and identification
  - move netconf-state data model to a different document
    To put this stuff in the protocol draft would be presumptuous,
    but would otherwise delay the protocol

The WG needs to decide what changes to make to the protocol draft
related to the proposed NETMOD work.  It is proposed that these
sections are not removed.  Instead, a warning in each section 
will be added to explain that a NETCONF data modelling standard
document is expected to supercede this text at some time in the
future.

3) Protocol Document Open Issues

Andy Bierman presented a list of open issues with the
NETCONF protocol document.  Refer to the slides and the 
jabber logs for more details.

3.1) Retrieval filtering

The group discussed the need for a mandatory-to-implement 
retrieval filtering mechanism.   The WG is considering
either "subtree filtering" (currently in the protocol 
specification examples) and "Xpath subset" (currently in 
an email proposal).  The operator requirements document
requires the ability to manage both full and partial 
configuration files, so some choice has to be made.

The group discussed the pros and cons of each approach (again), 
and then made some decisions:
  - full (but optional) implementation of Xpath will be 
    supported in NETCONF, indicated by the #xpath capability
  - the "subtree filtering" will be the mandatory-to-implement
    retrieval filtering mechanism 
      (show of hands: none - 0; subtree 18 - 20; XPATH subset 4)

3.2) Rollback

The WG agreed to address rollback and retrieval filtering at IETF 59.
There is a need to sometimes undo edits or commits to the running 
configuration.  The email proposal from Andy Bierman was explained
(see slides for details) and discussed by the group.  

The rollback proposal includes an optional "per session ring buffer", 
although each private snapshot (ring buffer entry) is a copy of the 
entire <running> configuration.  The <rollback> operation restores the
entire <running> configuration to previous state.  This is not a 
per-session restore operation.  

The group discussed issues related to locking, shared databases, 
transactions, access control, error reporting, and feature complexity.  
Afterwards, some decisions were made:
  - The rollback feature will not be added to the protocol document
    (show of hands: yes - 10; no  - 6;
     No consensus to change the document - leave it out)
  - The issue will go back to the WG mailing list for new proposals.
    (However, time is running out on additions; the document updates
     will not be held up for this feature.)


3.3) Default Edit Operation

The protocol draft does not properly support scoped edit-config 
operations, because "merge" is always the default edit operation.
The possible values for a default operation are "merge", "none",
and "replace".

Sometimes the default operation needs to be "none":
 - modify a node in the data model without touching any of its 
   ancestors
 - tells the agent that I better find an exact match or 
   this operation should fail

Sometimes the default operation needs to be "replace":
   - useful for loading previously saved configuration data 
     as an opaque XML block

The email proposal from Andy Bierman was discussed (see slides
for details).  This includes a new parameter for the <edit-config>
operation that specifies the default operation in the event
the "operation" attribute is not present within a data model 
element.  The group then made some decisions:
  - the <edit-config> operation will be changed to support
    a user-specified default operation
  - the new <edit-config> parameter will be called "operation"
  - the document needs to be clarified to indicate exactly
    how the default operation is applied to the <config> parameter,
    and how the "operation" attribute within a data model element
    overrides the default operation.

3.4) Default Configuration Target

The XSD does not support different default values, depending
on the presence of the #candidate capability.  Therefore,
instead of <running> as a default value, affected operations
(e.g., <lock>) should have no default specified.  There were
no objections to this change.

4) Application Mapping Documents: Open Issues

Andy Bierman presented a list of open issues with the
application mapping documents.  Refer to the slides and the 
jabber logs for more details.

4.1) General Issues

The titles of the application mapping documents need to be
more consistent.  The authors will work out the details
between themselves and propose new document titles (2 of the 3
will need to change).  The new document titles will be
proposed to the WG.  Also, all acronyms need to be spelled
out in the titles (e.g., SOAP).

4.2) NETCONF over SOAP 

There is concern that this document is too HTTP-centric.
The intent is that the document define how NETCONF maps to SOAP,
and different SOAP documents define how SOAP maps to the substrate 
protocol (e.g., HTTP, BEEP).  There is interest is running NETCONF 
over SOAP over BEEP, which is not directly supported by the NETCONF 
over SOAP document.

The WG discussed these issues and made some decisions:
  - The document should be made as SOAP-generic as possible
  - SOAP over BEEP should be supported 
  - Any HTTP or BEEP specific text should be identified and
    put in separate sections

5) Next Steps

The authors have been asked to produce "final updates" as soon
as possible (2 week deadline already past!).  After these
documents are posted, WG Last Calls can begin.


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>