[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Update: WG Last Call on Issue List
Netconf Issues
*** Updated 2/18/04
*** Look for lines beginning with an asterisk '*'
*** Comments on the updated status should be made to
*** the WG mailing list before February 27th.
Status = 1 of (Closed, Proposed Consensus, Proposal, Open)
----------------------------------------------------------
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> (NAME CHANGED, WAS get-state, then get-all)
<kill-session>
<commit>
<discard-changes>
2) Notifications
2.1) Should the NETCONF protocol support notifications?
Proposed consensus: not in version 1.0
* Closed: not supported in version 1.0
2.2) Proposal
<existing proposal, using use Reliable Syslog (RFC 3195)>
Proposed consensus: reject proposal, see 2.1
* Closed: N/A, 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
* Closed: N/A, 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
* Closed: N/A, 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
* Closed: N/A, 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
* Closed: N/A, see 2.1
2.7) Other Notification types
Proposed consensus: non-issue until notification support
is added, see 2.1
* Closed: N/A, see 2.1
3) Channels
Should channels be utilized in the netconf protocol?
Proposed Consensus: no, remove channels
* Closed: no, remove channels
3.1) Should channels be utilized in the netconf protocol?
<3 channel types proposal>
Proposed Consensus: reject proposal
* Closed: N/A, see 3
3.2) Multiple Operations channels
Proposed consensus: non-issue, see 3
* Closed: N/A, see 3
3.3) Content Restriction for Channels
Proposed consensus: non-issue, see 3
* Closed: N/A, 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
* Closed: N/A, 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.
* Closed: The <?eom?> framing sequence will be used
* 5.2) SSH Port Assignment
*
* 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
*
* 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.
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
* Proposed Consensus:
* - Operator preference is a more important factor than
* implementation costs on the device
* - No significant support for delaying this decision for 4-6 months
* - WG will attempt to select a mandatory-to-implement
* application mapping ASAP
8) Sessions
8.1) Should netconf support multiple transport connections per session?
Proposed consensus: non-issue, see 3
* Closed: N/A, see 3
9) Security
9.1) DoS attack using global <lock>
Proposed consensus: Just document this scenario in the Security
Considerations section
* Closed: document in the security considerations section
9.2) <steal-lock>
Proposed consensus: do not add a <steal-lock> command
* Closed: 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 control data model
* Closed: Not in scope
9.3.2) Authorization control for High-level RPC calls
Proposed consensus: Not in scope, let a different WG effort
define a comprehensive authorization control data model
* Closed: Not in scope
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
* (removed) - lock
* (removed) - unlock
10.2) User named databases
Proposal: Defer support for user named databases and files
to a future release. There is a workaround 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
* Proposed consensus: defer support
10.2.1) Configuration type
How to tell if this is a config dB or a config file?
Proposal: non-issue, see 10.2
* Proposed consensus: N/A, 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
* Proposed consensus: N/A, 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
* Proposed consensus: N/A, 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.
* Proposed consensus:
* - defer specific support for per-session candidate config
* until it can be fully specified.
* - make sure the NETCONF protocol design (and spec) does not
* preclude the addition of per-session candidate config later
10.3.2) (NEW) Confirmed commit
* Proposed consensus:
* - 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
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.1.2) URI vs. URN
*
* I think we should use URNs for identifying namespaces. There is
* already a registration mechanisms in place for URN protocol parameters
* (RFC 3553).
*
* Furthermore, RFC 3688 is worth to read since this provides a basis for
* registering schemas for data models (and this document also says that
* URNs are the default mechanisms for such registrations and refers to
* RFC 3553).
*
* Proposal: Use URNs instead or URIs to identify capabilities
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
* Proposed consensus:
* - remove this capability
* - 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
* Proposed consensus:
* - remove this capability
* - The application mapping documents should clarify the
* transport-specific details to distinguish session type
* for dual role entities
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
* Closed: N/A, see 3
11.2.8) #notification capability
Proposed consensus: rejected, see 2.1
* N/A, see 2.1
11.2.9) #url capability
Closed: accepted
11.2.10) #user-db capability
Proposal: deferred, see 10.2
* Proposed consensus: deferred, see 10.2
11.2.11) #user-file capability
Proposal: deferred, see 10.2
* Proposed consensus: deferred, see 10.2
11.2.12) #xpath capability
Proposal: deferred, see 14.1.1
* Proposed consensus: 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.
* Proposal:
* - A rollback returns the contents of the <running> config to
* a previous 'known start state'.
* - If #writable-running capability is supported:
* - The known start state is the start of execution of
* a <edit-config> operation
* - Rollback is only available by selecting the value
* 'rollback-on-error' as an 'error-option' on the <edit-config>
* operation
* - If #candidate capability is supported:
* - The known start state is the start of execution of
* the first <commit> operation (in a confirmed commit)
* - Rollback is only available by including the <confirmed/>
* parameter in the <commit> operation. Rollback will be
* done automatically if the second <commit> is not executed
* in the proper manner.
* - If configuration locking is not used or implemented
* properly, then it is possible for a rollback to revert
* changes that other users have made in the time interval
* since the known start state was captured. Therefore, it is
* strongly recommended that configuration locking be used
* if the rollback feature is used as well.
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
* Closed: 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)
* Closed: remove, not needed (see 3)
12.2) <rpc-abort-reply>
Proposed consensus: remove, not needed (see 3)
* Closed: 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)
* Closed: 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".
* Proposed consensus: Add the enum 'create' to the 'operation'
* attribute for the <edit-config> operation
13.3.2) No <error-option> for rollback-on-error
Open: not needed unless #rollback accepted, see 11.2.13
* Proposal: Add this enum, see 11.2.13
13.3.3) No format parameter for text or XML encoding
Proposed concensus: remove the format parameter.
Use namespaces to identify text/xml format distinctions .
* Closed: remove the format parameter, use namespaces instead
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
* Proposed consensus: 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
* Closed: remove format parameter
13.8) <get-all>
Should a 'get-all' operation be used or should 'get-state'
be used?
Closed: change get-state to get-all
* Closed: change get-state to get
13.9) <open-notification>
Proposed consensus: remove, notifications deferred, see 2.1
* Closed: N/A, see 2.1
13.10) <close-notification>
Proposed consensus: remove, notifications deferred, see 2.1
* Closed: N/A, see 2.1
13.11) <notification>
Proposed consensus: do not add, notifications deferred, see 2.1
* Closed: N/A, 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
* Proposal: A session ID of zero is reserved to indicate that a
* non-NETCONF session is holding the lock.
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.
* Proposed consensus:
* - Decouple #rollback capability (called revert) and the
* #candidate capability.
* - remove confirmed commit if rollback not accepted in general
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
* Closed: Clarify differences between discard-changes
* operation and the discard-changes option to the lock
* operation. Add clarifications to section on locking
* to indicate locking is system-wide and all non-NETCONF
* entities must integrate correctly with the locking
* mechanism, even if the locking is hidden from humans
* using the CLI.
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
* Closed: 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)
* Closed: Need clarifying text in the protocol document to
* either define exactly how this is done or say that it is
* data-model specific as to an agent does (4) or (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
* Closed: non-issue, see 13.3.3
15.1.2) Data format conversion
Proposed consensus: non-issue, see 13.3.3
* Closed: non-issue, see 13.3.3
15.1.2.1) Proposal: Data format conversion
Proposed consensus: non-issue, see 13.3.3
* Closed: 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/>