2.4.11 Network Configuration (netconf)


In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.ops.ietf.org/netconf/ -- Addiotional NETCONF Web Page
NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-28

Chair(s):
Simon Leinen <simon@switch.ch>
Andy Bierman <abierman@cisco.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Technical Advisor(s):
Wesley Hardaker <hardaker@tislabs.com>
Mailing Lists:
General Discussion: netconf@ops.ietf.org
To Subscribe: netconf-request@ops.ietf.org
In Body: in msg body: subscribe
Archive: http://ops.ietf.org/lists/netconf
Description of Working Group:
Wes Hardaker is Technical Advisor for Security Matters

Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanims or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses.

The Netconf Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics:

- Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications

The Netconf protocol will use XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. XML also supports hierarchical data structures.

The Netconf protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the Netconf protocol, such as:

- identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines

It should be possible to transport the Netconf protocol using several different protocols. The group will select at least one suitable transport mechanism, and define a mapping for the selected protocol(s).

The initial work will be restricted to the following items:

- Netconf Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements.

- Netconf over Specification, which defines how the Netconf protocol is used with the transport protocol selected by the group, and how it meets the security and transport layer requirements of the Netconf Protocol Specification.. There will be a document of this type for each selected transport protocol.

The working group will take the XMLCONF Configuration Protocol as a starting point.

Goals and Milestones:
Done  Working Group formed
Done  Submit initial Netconf Protocol draft
Done  Submit initial Netconf over (transport-TBD) draft
Dec 03  Begin Working Group Last Call for the Netconf Protocol draft
Jan 04  Begin Working Group Last Call for the Netconf over (transport-TBD) draft
Mar 04  Submit final version of the Netconf Protocol draft to the IESG
Apr 04  Submit final version of the Netconf over (transport-TBD) draft to the IESG
Internet-Drafts:
  • - draft-ietf-netconf-prot-01.txt
  • - draft-ietf-netconf-beep-00.txt
  • - draft-ietf-netconf-soap-00.txt
  • - draft-ietf-netconf-ssh-00.txt
  • No Request For Comments

    Current Meeting Report

    Network Configuration WG (NETCONF) Meeting Minutes


    OPS Area Network Configuration WG (NETCONF) Meeting Minutes IETF #58 Note takers: Gregory M. Lebovitz, Steve Ulrich, Simon Leinen, Andy Bierman

    The NETCONF WG met for two two-hour sessions in Minneapolis.

    Monday November 10, 2003 : 1530 - 1730

    Agenda Bashing

    The agenda was accepted as proposed.


    NETCONF over BEEP

    Eliot Lear presented draft-ietf-netconf-beep-00.txt. This mapping used to be part of the base NETCONF draft (draft-ietf-netconf-proto-00.txt), but has been separated out into its own document.

    Advantages of BEEP as a substrate for NETCONF include:

    • Good framing for XML
    • Good peer to peer characteristics. Either side can initiate connection or transaction
      Directionality is considered important because TCP goes easily through NAT and firewall devices, but SNMP makes this difficult. BEEP natural for many peer to peer use cases.
    • BEEP includes SASL and TLS profiles. SASL permits integration with existing authentication protocols.

    Possible objections to BEEP:

    • It's not SOAP/HTTP
    • May be more complex than desired.

    Left to do:

    • channel issues
    • SOAP over BEEP

    Q&A

    Andy Bierman: There's too strong an assumption that reliable syslog (RFC3195) is the only way to do notifications. Suggests to add a note that new notification syntaxes can be added in the future. Pending proposal from Weijing


    NETCONF over SSH

    Margaret Wasserman presented draft-ietf-netconf-ssh-00.txt. Several things have changed since last meeting. There is now support for notifications, sent on same connection.

    Advantages

    • good for integrating with scripts and security
    • already trusted and used by operators
    • incremental change to use SSH

    Framing

    • EOM - if unterminated comment then directive will be missed

    Issues: Should we add multi-channel support at all?

    Connections could be bound together with a session ID, but there is some concern over complexity and security

    Is BEEP vs. SSH visible to operators?

    • Big operators write their own applications
    • Medium operators buy tools
    • Small operators want free tools.

    Q&A

    Andy Bierman: How does the high-level NETCONF application know which substrate-dependent features are available?

    Glenn Waters: We need only one substrate

    Rob Enns: We had negative implementation experience with SSH, in particular concerning XML framing, leaking of error messages intended for humans etc.

    Margaret Wasserman: Supporting multiple transports complexifies the base protocol.

    Margaret: Why do operators like SSH?

    Because they know it and it fits into existing provisioning and security models.

    Eliot Lear: How many operators are in the room? (about 15). Some questions for operators:

    • Is compatibility with existing toolset a big deal for you?
    • Is compatibility with existing authorization a big deal?

    Dave Plonka: Key distribution is already there. I'd like to see the other protocols talk about bootstrapping the authentication/authorization issue.

    Someone from a big carrier: We wouldn't care about the protocol if the element management vendors would better support our needs.

    Glenn Waters: BEEP is not as widely available as e.g. SSH

    How would high-level app code know that some proto-ops (or mgmt channel features) are not available?

    A: We talked about channels having this capability. The channels capability is not functional with SSH (rpc-progress and rpc-abort). Those channels are out-of-band.

    Should an end-of-message directive <?eom?> be used to provide message framing? The issue is that if you get anything malformed, there is no easy way to say end that one and get back some error. In BEEP, if there is a framing error, the whole connection is dropped, so we could use it here. The problem is knowing when you have a framing error. Really want framing to be outside the XML. Or can come up with something outside legal XML (like &&).

    Request for clarification: at one time we were talking about setting up multiple ssh connections and binding them together to form channels. Has that been dropped?

    A: Yes, for now.


    NETCONF over SOAP

    Ted Goddard presented draft-ietf-netconf-soap-00.txt. Under this mapping, the manager initiates connection to agent.

    Multiple SOAP/HTTP connections with the same credentials and session ID in request-URI constitute a session. Multiple connections are needed for things like aborting operations. This leads to some security and complexity concerns.

    Where SOAP is not strong at all is for asynchronous notifications, because of HTTP's very distinct client/server roles. This does not fit with notification coming from server, in this case the agent. How can this be solved? No notifications over SOAP/HTTP, instead use reliable syslog. Notifications are contained in HTTP requests to the server. It is not clear if SOAP based tools would support notifications.

    WSDL is used to describe a NETCONF SOAP interface, which enables use of code generation tools. XSD and WSDL should be hosted by IANA.org.

    Application scenarios: Configuration, not monitoring -

    • Customized management application, typically graphical, for a specific kind of device
    • Enterprise/desktop management application
      Typically implemented in .NET or Java
      (SOAP libraries exist for most languages)

    Implementation issues: Need SOAP client and server stacks. The NETCONF SOAP binding is designed for code re-use with other transports. Requires document/literal SOAP encoding, not generic encoding - a little more work here. Embedded SOAP static footprint 100k + application

    Q&A

    Eugene Golovinsky: Since this uses WSDL, why don't we just call it Web Services?

    A: yes.

    Can the SOAP binding be made reversible? Let's say the agent is on other side of the firewall and needs to contact the manager.

    A: Yes, the agent can do a get request and pull the commands from the server.

    Is the use of multiple TCP connections per session problematic? Some devices may not be able to handle multiple TCP connections.

    Async notification done by polling? Doesn t seem scalable.

    BCP 56 describes issues when using HTTP as a substrate. Only the security area of the draft uses BCP 56. The next version of the document should take these issues into account. There is some concern that NETCONF should not run over TCP port 80.

    A: It seems like SOAP/HTTP violates much of the intention of BCP 56; however, it is very popular and viable, so I m not sure what to do. Inherent messaging weaknesses. Pls review more and follow recommendations for how to do XML exchanges.

    Using port 80 or different?

    A: usually goes over 80, but could specify it as unique. Currently this is the implementer's choice. We will need to define a port as the standard, be it 80 or other.

    Randy Bush: Section 3.6 discusses use of Proxies. My experience with this kind of things in other protocols is that proxies only complicates things by an order of magnitude. Please remove them for now.

    With proxies, the connection could get torn down w/o you knowing about it. If the proxy is gone, can you dictate the connections stays alive? Otherwise you have to do time-based or human-based clean up.

    Not sure we can do away with idea of proxies. They sit in the middle of the network. We can't change them not being there. And if they aren't, then non-port-80 HTTP looking protos are sniffed out by stateful FW things. We need to admit they are there, and act accordingly.

    Andy Bierman: proxies are designed to sit in the network and just work. They shouldn't be our problem.

    Wes Hardaker points out a possible security problem with multiple channels/connections within a session: If you have multiple channels with different security properties, then you could end up sending data through the management channel and returning through the other channel, at a lower crypto level. You might want to add text that requires the same security level for all bound channels.

    A: Agreed.

    Andy Bierman: Consider SOAP over BEEP (better for NETCONF than HTTP). Is the SOAP community going to adopt this mapping soon? Is the SOAP usage defined in netconf-soap-00 reasonable or will existing tools expect more features to be used?


    Discussion of Mandatory Substrate Selection

    The only reason for using SOAP is that it is useful for some application developers and their choice of toolsets.

    Randy Bush: In order to make a selection, you need very clear and detailed requirements, from operators, security experts, etc.

    Request for having only one mandatory. Others can exist, with supporting text, but only one will be mandatory.

    Andy Bierman: Opinions that SSH is best have diminished, mostly because of framing issues. Insiders at Cisco have tried SSH, and finally went away from it.

    Randy Bush, with AD hat on. You can have 95 protocols if you want, but only one mandatory. I don t care which one. But one is necessary in order to have users/vendors be able to interoperate

    Picking up implementations intended for use by humans (like SSH or Telnet) has issues. Example: error messages that were intended for humans leak and now you have to figure out if it is part of data or not. Find something that is industrial strength, bullet proof, etc. But keep another lying around for easy scripting and lower requirements for robustness.

    Randy Bush, as operator. I want SSH because of fear of the unknown, and because I already have a lot of SSH around, and I know it. Operators are not adventurous types.

    Wes Hardaker. Noone has come forth and said, one of these transports will not work for me.

    Andy Bierman: Notifications don t work well over HTTP. You have to poll from them.

    Wes Hardaker: And they don t work well over SSH either. Looks like we are looking toward BEEP

    Wes Hardaker, as operator. I have SSH already. Keys deployed, etc.

    Would operators be aware of whether it was BEEP or SSH?

    Randy: the large operators are rolling their own, so they would know. The middle folks are rolling over and dying. The smaller ones are buying off the shelf, and they would not know the difference.

    Question to operators: is compatibility w/ existing tool set more important?

    Carrier1: think about bootstrapping. We have keys rolled out for the elements now. We have ACLs configured already to allow the SSH through. Would we need to create new ACLs for BEEP? Need new app layer passwords? Easier to use the SSH already there, from bootstrap perspective.

    Carrier2: if the vendors were to implement element management systems that worked well with their elements, we wouldn t care. But due to their lack of an object-oriented system that works well, we have to build our expect/Tk scripting tools.

    Glenn Waters: BEEP not as widely available as SSH. SSH is in anything, Perl, Python, C, etc. in any language.

    Should we optimize the protocol for which transport it is on, or keep the same for each application mapping?

    Andy Bierman: makes the choice easier if only use one way.

    Margaret Wasserman: but if the transport has some feature, we should use it, no? Why live to the least common denominator?

    Application Mapping Comparison

    FeatureBEEPSOAPSSH
    Agent inits connectionYNY
    Multiple Channels per conn+YNN
    Supports <rpc-progress>YY*Y*
    Supports <rpc-abort>YY*Y*
    Supports notificationsYY*Y**
    Use exiting key envNNY

    + per transport connection. SSH can support multiple channels, so we could change the document today make it a multiple channel documents.

    * requires multiple transport connections

    ** Notifications are mixed w/ responses

    Enterprise folks aren't interested in cut and paste and Perl.

    Library for BEEP for C, C++, TCL, Perl, JAVA, etc. The only thing really missing is cut and paste and expect-style scripts. Typically you'll see the name of the data and the data. But in XML format, that stuff no longer works. Data and the Tag for the data may not be easily located with regular expressions in expect scripts.

    R: These are not widely used compared to SOAP. On the roadshow (NANOG) we wanted to know why people weren't using SNMP. Answer was lack of toolsets. If we create something that doesn't get many tools around it, they will not use it again, like SNMP for configuration.

    Tools: a developer for another WG has done XML over BEEP. Tools are there. The SOAP/HTTP issues.

    Randy Bush: we are going to run around in circles here. Get detailed requirements. Get the audiences: Operators, vendors, people who know transport issues, etc.

    Framing. If going to give a multi-megabyte config to a router, difficult to compute the total length before start sending.

    A: can say "more coming" in BEEP.

    BEEP is built as libraries. The other tools for SSH and SOAP/HTTP are not as well structured.

    Requirements for debugging are very different than those of configuration. Config must be reliable, very solid, etc. Debugging req s might be lower threshold.

    Andy Bierman: What about multiple operation channels? We have all these not-quite-requirements for channels now. But it may be nice to have in the future for extensibility.

    Andy Bierman: Propose to move on and discuss operational model. If we make decisions on some of those areas, may help make the requirements more clear for application/transport mapping.


    Operational model

    Channels

    Andy Bierman: Should a mapping be allowed to leave out protocol features?
    How important is rpc-process? rpc-abort can be approximated by closing the session, but no such workaround for rpc-progress.

    Modularization of channel definition:

    • Protocol document should talk about conceptual channels
    • Substrate mapping document should explain what these are mapped to.

    Application mapping resolutions

    • channel capability indicates mgmt channel
    • notification capability indicates notification channel
    • decided to send a message to NANOG mailing list to get some feedback on the use of channels

    Pick one mandatory to implement - important for interoperability

    Long discussion over comparision of application mapping costs/benefits.

    Resolution: need to clearly identify functional requirements and use cases for each one. No decision made on mandatory-to-implement mapping.

    Sessions

    If agent initiates session then how does it know which user identity to use during login?

    reverse connection model uses different security model

    • SSL server cert
    • username/password

    Capabilities

    Capability representation - URI/URI+Version/Naming authority+name+version?

    Ted Goddard: If possible, should use URLs that point to actual schema definitions.

    There is some concern over too many capabilities.

    • try to limit the number of standard capabilities

    Notifications

    Notification element didn't make it into the protocol document

    Q&A

    Prefer to buy rather than build, when available. RFC 3195 is there now.

    I think you'd be insane not to allow flexibility for future. Like the IDS format stuff. Propose to allow 3195 as one of the options, but not the only way.

    Andy Bierman: How to import their data model? what if 3195 gets revised?

    Response: There is no data model in RFC 3195. Either cooked or raw mode.

    Suggest taking out the one line in the doc that prescribes RFC 3195. Agreement on this point from chair. For now, line will be removed. Either you follow RFC 3195 or you don't. Either is fine, but we need to be clear.


    Wednesday November 12, 1300-1500

    Notifications (continued)

    Weijing Chen: Notifications are specified in our draft.

    Eliot: We're looking at notifications related to configuration in particular.

    Andy Bierman: Take it to the mailing list. Weijing could make a propsal for WG defined notification structure.

    Otherwise don't use; RFC 3195 does not need this top level element

    Attendee a: points out that 3195 references BEEP channel as mechanism.

    Attendee b: points out that syslog connection would be required 24x7

    Eliot Lear: some mediation element provides filtered notification to NETCONF aware element

    Weijing Chen: comments re: 3195 tying to beep and pointing to SOAP and other transports.

    Eliot Lear: suggestion for punting on notification and let other folks work on the issue or alternatively making it an option

    Weijing Chen: Points to a discontinuity in XML wrapping.

    Attendee c: points out that charter states requirements for transport independent protocol as well as asynchronous operation.

    The inability to separate notification from transport provides a challenge.

    Taken to the list

    Channels

    management
    optional (based on capability) all or nothing support if implemented.
    operational
    mandatory
    notification
    optional if supported

    List the advantages of multiple channels, and ask operators whether those are worthwhile to them.

    • <rpc-abort> (terminate operation without losing lock)
    • <rpc-progress>
    • Notifications

    David Perkins: Is there anyone for whom the addition of channels would make matters worse?

    Randy Bush </ad>: complicates things and narrows choices, doesn't need channels. This is NETCONF - configuration specific, not out to replace SNMP notifications, traps, etc.

    Andy Bierman: It adds complexity to the spec, to implementations...

    Randy Bush: Complicates protocol, limits our options.

    Bert Wijnen: Having everything as capabilities makes usage more complex.

    Wes Hardaker: People aren't sure whether they need them [channels] until they have been able to work with implementations.

    Randy Bush: I like doing things in lockstep: I have changed configuration in the device - then I want to check whether it had the intended effect. I don't want to replace notifications and traps. Network configurations (NETCONF) is fully synchronous.

    Eliot Lear: question to operators - where do they stand relative to channels?

    Simon Leinen: A single channel is adequate. The interactive element is nice but not core to the configuration capability.

    Weijing Chen suggests dropping channels.

    Action on Eliot to send mail to NANOG regarding applicability and use of channels and follow up to list.

    Sessions (dependent on channels)

    Multiple transport connections for one session, or have all channels in a single transport connection.

    Andy Bierman: punt this issue until we understand what to do w/channels?

    edit session - management of volatile session properties,

    Do we need <edit-session> to change per-session state/configuration?

    Randy Presuhn: An example would be to enable/disable XML pretty-printing.

    Andy Bierman: ssh session management (minor -> to list)

    punt for now

    Inconsistency in SSH draft: <kill-session> requires session ID, Andy would propose to use session ID=0 to kill current session, but this is incompatible with current protocol draft.

    Capabilities

    Capability representation:

    Proposal: Go back to original idea of just using a URI.

    Version ID at the end or in the middle? Do we even want to standardize these URIs?

    No objections to using style B. So we'll say we're going to use style B.

    comments re: style A vs. style B

    Capabilities Negotiation

    Ted Goddard: Capability negotiation is the only thing that doesn't fit into the RPC form. Having it as a regular RPC would make the SOAP mapping easier.

    Randy Presuhn: Another reason to treat capabilities exchange as another RPC: It doesn't really change what you should accept, it is advice from your partner as to what you should send. Having capabilities as an RPC is an elegant idea.

    Some comments regarding the ability to change capabilities over the course of the session

    Weijing: Dynamic capability notifications

    Andy Bierman: It would make use of the protocol easier if capabilities would remain static for a session. Discussion to solidify this to be taken to the list.

    Manager/agent capabilities - preventing deadlocks on startup.

    missing capabilities

    Andy Bierman went through list of current capabilities as well as a few ones that could be added, soliciting comments.

    There were no objections to having the following as capabilities:

    • <user-db>
    • <user-file>

    User-defined databases and files.

    <xpath> - propose to leave them out.

    Weijing Chen: what protocol elements are impacted by these "missing capabilities"?

    Andy Bierman: Come back to this later, I have other slides.

    Locks

    Wes Hardaker had brought up a potential DOS issue, when you grant a global lock and a user with local privileges locks out access to the entire database.

    Wes Hardaker: It's an important issue in my mind, because it is a DOS attack that cannot be fixed.

    <steal-lock>

    No objections to adding a lock-stealing operation (may be an optional attribute to the <lock> operation.

    • steal-lock must imply kill-session on the lock holder
    • not sure if this operation is really needed

    Configuration Files

    underlying assumption that there's a configuration database that is NETCONF aware/capable

    Limited set of protocol operations allowed on files:

    • <copy-config>
    • <delete-config>
    • <lock>
    • <unlock>

    Query for more file operations - no response from group

    Solicitation for comments re: user named databases - taken to the list for further feedback

    User-Named Databases

    Do we need <create-config>?

    Some database people don't like implicit creation.

    Text vs. XML Format

    solicitation for comments re: text mode vs. text wrapper

    Add a new "<text>" element rather than have the (text/xml vs text/plain) parameter?

    Ted Goddard: You could use another tag, for example <example:cli>.

    Rob Enns: Or you add <get-text-config> in addition to <get-config>.

    Phil Shafer: It is important to keep the possibility of retrieving text-based configuration. People will use this to archive configurations etc., and text mode remains easier for people to deal with.

    Attendee X: suggests that API hooks be provided to let folks get config info into their systems.

    Attendee Y: points to the importance of having text mode available, points to config archival/diff/retrieval.

    Weijing: The format is really decided by the schema. One could use a special text-oriented schema, maybe with just one element.

    Wes Hardaker raised concerns about applying consistent access control to XML and text modes. Can't specify mechanisms for text content since there will not be a well-defined schema.

    Rob Enns: Having the format= attribute makes it easier to use XML-based access control.

    Phil Shafer: Access control for modifications via XML should match access control through CLI.

    Andy Bierman: Those may not always be linked so closely.

    Randy Presuhn: Text and XML versions may either not be directly related, or there may be a mapping through e.g. XSLT.

    Keep the param only for copy-config because this feature of providing XML or text output is meant to apply to the entire configuration, not complex data selection found in edit-config and get-config.

    There were also concerns that there may not be a complete mapping between XML and text representations of a data model. The device may return an rpc-error if a copy-config cannot be completely generated for a particular format.

    no clear consensus reach on this item - taken to the list

    <candidate> Configuration

    Should there be per-session candidate configurations?

    <commit>

    Provides implicit rollback. Protocol should have an explicit rollback. Andy Bierman: This is one of the features that customers actually have asked us for.

    Ted: What if you don't have enough storage space for a configuration to roll back to?

    Andy Bierman: Then you don't advertise the capability.

    John Schnizlein: Would this be a global or a per-session rollback?

    Andy Bierman: Global. It takes out the last committed change.

    John/Wes: This is non-transparent and dangerous.

    Andy Bierman: Rollback-on-error doesn't have the same problem, does it?

    Wes Hardaker: Rollbacks could actually undo changes that the user shouldn't be able to undo.

    Andy Bierman: Ok, I understand. But I still think rollback-on-error doesn't have these problems.

    Protocol Operations

    <edit-config>

    There's no explicit "add" operation (only merge, replace and delete). An "add" (or "create") would fail if the thing that's being added already exists.

    No objection to adding this.

    rollback-on-error

    no formal param for txt or xml encoding

    <get-state>

    Decided to have <get-all> instead.

    Action: Add text to the draft explaining the issues to the draft

    Rob Enns doesn't like the name <get-all>

    Rüdiger: Agree, you cannot clearly separate "state" (non-configuration) and configuration data. So having <get-all> and <get-config> is fine.

    Wes Hardaker: get-all would have filtering mechanisms

    Andy Bierman: doesn't concur re: get-config and get-all

    john: query re: the need to have 1 massive operation vs. 2 smaller operations

    Wes Hardaker: points that the single operation provides a match between the configuration and the state of the device and provides a binding between the 2.

    john: wants the text to reflect Wes' reasoning to provide the rationale (binding the 2 elements together)

    Notes on Data Modeling Issues

    Glenn Waters

    Modeling and the Protocol

    How should documents be named
    XPATH, XML Query?

    Granularity
    Can we pull back just a set of attributes, or do we pull back entire documents

    Should the actual implemented model be available through the protcol?
    could be a URI or an XSD xferred via the protocol

    Andy Bierman: feels that "document naming" is a bit misleading given that element may have nested structure.

    Modeling requirements

    Change control rules

    Managing standards based objects vs. vendor objects, version numbers, etc.

    XSD doesn't support InetAddress etc. Extensibility How are objects augmented? Modeling Conventions We have 50 pages of rules for SMI now, so we will probably need 50 pages of rules for XML. XSD annotation clause Guidelines for using namespaces data type restrictions? guidelines on how namespaces are used

    Andy Bierman: points to the chicken/egg issue of defining rules for schema when the protocol is under development

    Modelling Language

    XSD of course - it is very popular, and there is an abundance of tools. But...

    • Can't combine read-only and read-write in a single XSD
      - requires two models
    • Requires that configuration and state models are separate (assuming that XSD is used to validate documents).
    • appInfo is the only standard way to extend XSD: Tools will not understand the NETCONF appInfo tags.
    • XSD is not human-friendly.

    Next Steps

    Anyone want to help out on this?

    Wes Hardaker: thanks for the work being done.

    Andy Bierman: new mailing list for the data modelling?


    SYMPLE - scripting protocol & architecture for managing devices

    Sandeep Adwankar presented draft-adwankar-netconf-symple-00.txt.

    synclet - based on SyncML

    Folks are encouraged to read the draft and make comments on the list.

    Attendee: request for a comparison between SNMPCONF, SYMPLE and NETCONF.


    2003/12/15 0:11:20
    Simon Leinen <simon@switch.ch>

    Slides

    Agenda
    NETCONF over BEEP mapping
    NETCONF Over SOAP
    Data Modeling
    SYMPLE Scripting Protocol and architecture for seamless management of XML based mobile devices and SNMP based devices