[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Begin WG Last Call: NETCONF Issue List
Hi,
First I want to thank Phil (for his ever onward mail) and Steve
(for his WEB page http://www.nextbeacon.com/netconf/), for
helping the WG resolve a long list of issues. Now we need
to finish the drafts, so we're having a 3 week Last Call
on the open issues and proposed resolutions below.
Netconf Issue Status
---------------------
Status = 1 of (Closed, Proposed Consensus, Proposal, Open)
Closed:
WG consensus has been reached on the issue
Proposed Consensus:
The WG Chairs believe the WG majority want to resolve
the issue as described, but the WG consensus has not
been confirmed yet
Proposal: One or more solution proposals exist, which
are being considered by the WG
Open: Issue has been identified, but no solution proposals
are available yet
Last Call Details
------------------
The WG members are requested to review the status details
in this email and post comments (in agreement or not)
to the WG mailing list <netconf@ops.ietf.org> by
February 26, 2004.
Please post new messages to the list, one email per topic,
topic ID in the Subject, instead of replying to this email.
Please concentrate on issues in the Open and Proposal states,
although comments on any issue (even issues marked Closed)
are welcome during this Last Call.
thanks,
Andy
----------------------------------------------------------
1) Conformance
1.1) Feature subset consistency
Should the protocol be tailored (optimized) for each application
mapping or should it be kept the same for each application mapping?
Closed: no, have one common protocol instead
1.2) Feature subsetting discovery
How does the high-level NETCONF application code know that some
proto-ops (or management channel features) are not available?
Closed: use capabilities exchange
1.3) Base Protocol Operations
What protocol operations should be in the base set?
Proposed consensus:
<get-config>
<edit-config>
<copy-config>
<delete-config>
<lock>
<unlock>
<get-all> (NAME CHANGED, WAS get-state)
<kill-session>
<commit>
<discard-changes>
2) Notifications
2.1) Should the NETCONF protocol support notifications?
Proposed consensus: not in version 1.0
2.2) Proposal
<existing proposal, using use Reliable Syslog (RFC 3195)>
Proposed consensus: reject proposal, see 2.1
2.3) Notification types
Should NETCONF define specific notification formats?
If so, should RFC 3195 (Reliable syslog) be supported?
Should other notification schemes be defined?
Proposed consensus: no to all, see 2.1
2.4) <notification> wrapper
Choose 1 of:
- Should the protocol define a top-level protocol-operation
element to indicate any type of notification?
- Should the specification for each type of notification
supported indicate the XML encoding for a notification.
Proposed consensus: defer issue until notification support
is added, see 2.1
2.5) <matching> parameter
Remove <matching> parameter because it is not documented and
therefore not interoperable.
Proposed consensus: non-issue until notification support
is added, see 2.1
2.6) Reliable syslog
2.6.1) Should RFC 3195 (Reliable syslog) be specified as
the only supported notification type in NETCONF v1.0?
2.6.2) Should each application mapping specify how RFC
3195 is supported and encoded?
Proposed consensus: non-issue until notification support
is added, see 2.1
2.7) Other Notification types
Proposed consensus: non-issue until notification support
is added, see 2.1
3) Channels
Should channels be utilized in the netconf protocol?
Proposed Consensus: no, remove channels
3.1) Should channels be utilized in the netconf protocol?
<3 channel types proposal>
Proposed Consensus: reject proposal
3.2) Multiple Operations channels
Proposed consensus: non-issue, see 3
3.3) Content Restriction for Channels
Proposed consensus: non-issue, see 3
4) Beep Issues
4.1) Multiple <RPY> messages
Why would a single <rpc> (MSG) which in turn causes a single
<rpc-reply> result in multiple RPY messages?
Closed: 1 reply per request;
clarification needed to BEEP, sec. 2.2
4.2) Notification types
<reliable syslog>
Proposed consensus: non-issue, see 2.1
5) SSH Issues
5.1) End of message directive
Should an end-of-message directive <?eom?> be used to
provide an easier message framing mechanism than parsing
the entire XML instance document to find the proper end tag?
Proposed consensus:
- Some sort of framing sequence is needed
- Considered <?eom?> and &&
Since this character sequence might appear in a CDATA section
it should be something not likely to occur
- The <?eom?> framing sequence will be used. It should be
added to the NETCONF over SSH document.
6) Soap Issues
6.1) SOAP Proxy
Closed: remove all text about proxy support
6.2) SOAP over BEEP
Closed: not under consideration for NETCONF 1.0
6.3) SOAP header usage
Open: Need to document which SOAP header attributes are mandatory
or recommended for NETCONF over SOAP implementations
7) Criteria to choose a Mandatory application mapping
7.1) Need to compile a list of criteria then prioritize the list.
Proposal:
- reach stable snapshot state with netconf drafts, without
making the mandatory-to-implement choice yet
- allow some developers to implement the stable snapshot
for 1-3 of the application mappings
- bugfix the drafts in the meantime, as errors are discovered
- in 4-6 months,
- developers will give the WG implementation reports
- based on this implementation experience, the WG will
choose a mandatory-to-implement
- the WG will choose a mandatory-to-implement within 4-6 months
even if implementation reports are not available
8) Sessions
8.1) Should netconf support multiple transport connections per session?
Proposed consensus: non-issue, see 3
9) Security
9.1) DoS attack using global <lock>
Proposed consensus: Just document this scenario in the Security
Considerations section
9.2) <steal-lock>
Proposed consensus: do not add a <steal-lock> command
9.3) Authorization Control Model
9.3.1) Authorization control for protocol operation based access
Proposed consensus: Not in scope, let a different WG effort
define a comprehensive authorization model
9.3.2) Authorization control for High-level RPC calls
Proposed consensus: Not in scope, let a different WG effort
define a comprehensive authorization model
9.4) Partial locks
Closed: no partial database locking support in version 1.0
9.4.1) Partial lock proposal
Closed: proposal rejected
10) Configuration Databases and Files
10.1) Allowed protocol operations
10.1.1) Databases
Closed: Configuration databases can be used with all
protocol operations.
10.1.2) Files
Closed: Configuration files can be used with the following
protocol operations:
- copy-config
- delete-config
- lock
- unlock
10.2) User named databases
Proposal: Defer support for user named databases and files
to a future release. There is a work-around available
in the protocol operations -- some can take a 'file'
type URL as an argument, to identify a local user-named
config file or database
10.2.1) Configuration type
How to tell if this is a config dB or a config file?
Proposal: non-issue, see 10.2
10.2.2) Capabilities exchange
Need capabilities for named-db and named-file
Proposal: non-issue, see 10.2
10.2.3) Create-config
Is a <create-config> operation needed for named configurations?
If so, can <copy-config> be used to create a named configuration?
Proposal: non-issue, see 10.2
10.2.4) Configuration attributes data model
Need a data model to determine the list of named configurations
and their properties
Proposal: non-issue, see 10.2
10.3) <candidate> Configuration
10.3.1) Global vs. Per-Session candidates
Proposal: Add an argument to the #candidate capability to
indicate 'global' or 'session' candidate config type.
Add text to clarify requirements for both types.
10.3.2) (NEW) Confirmed commit
10.4) <running> Configuration
Closed: There is only one running configuration
10.5) <startup> Configuration
Can the target <startup> be deleted or just emptied of commands?
Closed: just emptied of commands
11) Capabilities
11.1) Capabilities representation
How should a capability be represented in the <hello> exchange
during session startup?
Closed: Use a URI only. A standard data model may be created
in the future to provide details about each capability
11.1.1) Naming Proposal:
Put the version ID last, but before the capability
name if present:
http://ietf.org/netconf/base/1.0
http://ietf.org/netconf/base/1.0#agent
Closed: accepted; make this change in all documents
11.2) Standard Capabilities: Which capabilities are needed and for
each one, how do we specify its parameters
11.2.1) #manager capability
Proposed Consensus: accepted, add clarifying text to address
dual-role entities:
- only 1 of the 2 NETCONF peers are allowed to advertise
both #agent and #manager (on the same session).
- The application mapping documents should clarify the
transport-specific details to distinguish session type
for dual role entities
11.2.2) #agent capability
Proposed Consensus: Accepted, see 11.2.1
11.2.3) #writable-running capability
Closed: accepted
11.2.4) #candidate capability
Closed: accepted (except see 10.3.1)
11.2.5) #validate capability
Closed: accepted
11.2.6) #startup capability
Closed: accepted
11.2.7) #management capability
Proposed consensus: rejected, see 3
11.2.8) #notification capability
Proposed consensus: rejected, see 2.1
11.2.9) #url capability
Closed: accepted
11.2.10) #user-db capability
Proposal: deferred, see 10.2
11.2.11) #user-file capability
Proposal: deferred, see 10.2
11.2.12) #xpath capability
Proposal: deferred, see 14.1.1
11.2.13) #rollback capability
Open: 2 people have action item to write up proposal for
a simple rollback capability. Specific requirements
need to be explained.
11.3) Capabilities exchange
11.3.1) Session ID
Should <session-id> be returned in session startup somehow,
as part of the capabilities exchange?
Proposed consensus: not needed, see 3
12) RPC Operations
12.1) <rpc-abort>
Should <rpc-abort> be supported in different ways, depending
on the application mapping, or should it simply be an XML
operation passed to the agent?
Proposed consensus: remove, not needed (see 3)
12.2) <rpc-abort-reply>
Proposed consensus: remove, not needed (see 3)
12.3) <rpc-progress>
12.3.1) Extra <rpc-progress> messages
Proposed consensus: non-issue, remove, not needed (see 3)
12.4) <rpc>
Closed: no issues
12.5) <rpc-reply>
Closed: no issues
12.6) <rpc-error>
Open: Need to finalize all fields in the <rpc-error> element
and improve documentation
12.6.1) Error codes
Open: need to define <rpc-error> content for standard errors
- 5 layers
- application mapping
- netconf protocol
- RPC layer
- protocol operation
- data model specific
The WG needs to document all but the data model specific
error responses. All the rest, except application mapping
errors should be documented in the netconf protocol I-D.
13) Protocol Operations
13.1) <edit-session>
Is a special <edit-session> operation needed?
Closed: no, wait until session-specific parameters needed
13.1.1) Proposal: defer till later
Closed, accepted, see 13.1
13.2) <kill-session>
How should kill-session be used to close a session with SSH
as the application mapping?
Closed: not required (just close the transport connection)
13.2.1) <kill-session> Proposal:
Use session-id == zero to indicate kill the current session
Closed: rejected, see 13.2
13.3) <edit-config>
13.3.1) No operator for 'add' (create)
Proposal: Extend the 'operation' attribute for the <edit-config>
command to include the 'create' operation. Developers have
asked for this to prevent race conditions in which 2 operators
try to create the same instance of a resource (e.g. loopback
interface). SNMP has this capability (RowStatus). We need
to be able to tell the agent "create this instance only if
it doesn't already exist".
13.3.2) No <error-option> for rollback-on-error
Open: not needed unless #rollback accepted, see 11.2.13
13.3.3) No format parameter for text or XML encoding
Proposed consensus: remove the format parameter.
Use namespaces to identify text/xml format distinctions .
13.4) <get-config>
Closed: no issues raised
13.5) <create-config>
Is this operation needed for user-named configs?
Proposal: defer, see 10.2
13.6) <delete-config>
Closed: no issues raised
13.7) <copy-config>
13.7.1) format parameter
Proposed consensus: remove format parameter, see 13.3.3
13.8) <get-all>
Should a 'get-all' operation be used or should 'get-state'
be used?
Closed: change get-state to get-all
13.9) <open-notification>
Proposed consensus: remove, notifications deferred, see 2.1
13.10) <close-notification>
Proposed consensus: remove, notifications deferred, see 2.1
13.11) <notification>
Proposed consensus: do not add, notifications deferred, see 2.1
13.12) <lock>
13.12.1) Multiple concurrent locks
Closed: only one lock can be obtained per call
13.12.2) <target> Clarification
Target parameter says it is optional; should say
default <running>
Closed: agreed, document needs to be corrected
13.12.3) Error handling
Negative response says session-id of lock owner will be returned;
how will actually be done (specific element)
Closed: negative response should indicate lock owner
in a standard element -- this needs to be added to the
protocol document.
What error response is given if a <lock> fails because a
non-NETCONF entity holds the lock?
Open: needs to be defined, see 12.6.1
13.13) <unlock>
Closed: no issues raised
13.14) <steal-lock>
Closed: duplicate of 9.2
13.15) <commit>
13.15.1) Early termination
What happens if session is terminated before the 2nd <commit>
is received? Or after 2nd commit processed but <rpc-reply>
received by the manager?
Closed: if confirming commit doesn't happen, the device
should rollback to the previous configuration
13.15.2) Implicit Rollback
This provides an implicit rollback. The protocol should have
an explicit rollback that works the same whether #candidate or
#writable-running is supported
Proposal: Decouple #rollback capability (called revert)
and the #candidate capability. They are not related.
Need to clarify that confirmed commit if #rollback in
general is accepted (see 11.2.13), or remove confirmed
commit from version 1.0.
13.16) <discard-changes>
13.16.1) Clarifications [PROT]
Says content 'automatic' is allowed for the <discard-changes>
operation. This is not actually documented.
Closed: accepted, protocol document needs to be updated
13.17) Other Protocol Issues
13.17.1) last-known-good config
Closed: no support will be added for this feature in version 1.0
13.17.2) remote configurations
Can any operations besides <copy-config> apply to remote
configurations?
Closed: no, remote configurations should be manipulated remotely
(outside the netconf server)
14) Data Retrieval
14.1) Subset specification
14.1.1) XPath
Proposed consensus: defer until a later release
14.1.2) Element subtree filtering
Need to fully document how the agent handles filter requests
Open: Element subtree filtering is in the spec now,
but this issues has an impact on data modeling, and
is most likely specific to the data model.
- this functionality needs to be properly documented in
normative text, or the feature removed from 1.0
14.1.3) subset by name
Closed: data model specific, defer to a different WG effort
14.1.4) Subset by parameter value
Closed: data model specific, defer to a different WG effort
14.1.5) Retrieval options
1) Selected subset
2) Instance identifiers of selected subset
3) N nest levels of selected subset
4) Select all children of specific start point
5) Select all siblings (and their children of a specific
start point
Closed: Support (4) and perhaps (5)
15) Data Model
15.1) Text vs. XML <format> parameter
15.1.1) Access control
Need to understand how element sub-tree filtering and access
control are affected by text mode
Proposed consensus: non-issue, see 13.3.3
15.1.2) Data format conversion
Proposed consensus: non-issue, see 13.3.3
15.1.2.1) Proposal: Data format conversion
Proposed consensus: non-issue, see 13.3.3
15.2) Data Naming Protocol Impact
Does choice of data naming actually impact the protocol?
Closed: should not guess, wait until another WG effort
addresses data modelling issues. May need to update
protocol document later.
16) Multi-device transactions
16.1) Distributed unit of work identifier
Closed: <rpc> attributes are echoed on <rpc-reply>
so this is really up to the app
--
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/>