[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Updated WG Issues List
Netconf Issues
*** Updated 3/11/04
*** Look for lines beginning with an asterisk '*' for new status
*** Issues remaining in the closed state with no
*** change in action have been removed
Status = 1 of (Closed, Proposed Consensus, Proposal, Open)
----------------------------------------------------------
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>
<kill-session>
<commit>
<discard-changes>
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
* Closed: The ]]^^]] 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?
* Closed: 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?
* Closed:
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.3) SOAP header usage
Open: Need to document which SOAP header attributes are mandatory
or recommended for NETCONF over SOAP implementations
* Proposal:
* Current NETCONF over SOAP document documents the headers
* that are needed for conformance
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:
* Closed:
- 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
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
* Closed: defer support
10.2.1) Configuration type
How to tell if this is a config dB or a config file?
Proposed consensus: N/A, see 10.2
* Closed: N/A, see 10.2
10.2.2) Capabilities exchange
Need capabilities for named-db and named-file
Proposal: non-issue, see 10.2
* Closed: 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?
Proposed consensus: N/A, see 10.2
* Closed: 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
Proposed consensus: N/A, see 10.2
* Closed: non-issue, see 10.2
10.3) <candidate> Configuration
10.3.1) Global vs. Per-Session candidates
Proposed consensus:
* Closed:
- 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) Confirmed commit
Proposed consensus:
* Open:
- 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
* - rollback is an important feature and the WG will try again
* to resolve any remaining issues so confirmed commit can be
* supported
11.1.2) URI vs. URN
[From Juergen S.]
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:
* Proposed Consensus:
Use URNs instead or URIs to identify namespaces
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:
* Closed:
- 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:
* Closed:
- remove this capability
- The application mapping documents should clarify the
transport-specific details to distinguish session type
for dual role entities
11.2.11) #user-file capability
Proposed consensus: deferred, see 10.2
* Closed, see 10.2
11.2.12) #xpath capability
Proposed consensus: deferred, see 14.1.1
* Closed: deferred, see 14.1.1
11.2.13) #rollback capability
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.
* Proposed Consensus:
* - there is strong interest in supporting this feature
* - in the interest of clarity, there will be 2 separate
* capabilities for confirmed-commit and rollback-on-error.
* Also, rollback-on-error can apply whether the target
* is the candidate or running config.
* - The proposal above will be reworded and resubmitted to the WG.
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.
* Open: need to define protocol error codes and a container
* for data-model specific error info. Only netconf protocol
* errors will be documented.
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
* Closed: Add the enums 'create' and 'modify' to the 'operation'
* attribute for the <edit-config> operation
13.3.2) No <error-option> for rollback-on-error
Proposal: Add this enum, see 11.2.13
* Proposed consensus: not needed unless #rollback accepted, see 11.2.13
13.5) <create-config>
Is this operation needed for user-named configs?
Proposed consensus: defer, see 10.2
* Closed: defer, see 10.2
13.8) <get-all>
Should a 'get-all' operation be used or should 'get-state'
be used?
Closed: change get-state to get
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.
* Closed: A session ID of zero is reserved to indicate that a
* non-NETCONF session is holding the lock.
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: 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.
* Closed: remove this parameter and always discard-changes
* in the candidate config if the session does not release the
* lock cleanly
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
* Open: This has been requested as a possible solution to reduce
* the size of a <rpc-reply> for a <get> operation on very large
* devices. The WG will investigate this and other methods to
* make the get operation more usable on large configurations.
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: 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)
* Open: see 14.1.3
--
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/>