[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NetConf should fully exploit BEEP's rich features
Hi,
I have a few comments below on the Netconf protocol
(Draft-ietf-netconf-prot-00) and its mapping to BEEP
(draft-lear-netconfbeep-00).
Netconf is defined as a high-level set of protocol messages in XML, and an
underlying binding (e.g. the Netconf-over-BEEP application protocol) which
is responsible for the safe delivery of messages between Netconf peers.
I realise that Netconf can flow over other bindings (e.g. SOAP over HTTP,
SSH, custom) and believe it should try to exploit the features of each
binding as much as possible.
Eamon O'Tuathail
Clipcode
============================
Draft-ietf-netconf-prot-00 in "Section 2: Transport Protocol Requirements"
uses the term "transport" - why?
Is the binding beneath NetConf merely providing a service of transporting of
octets, or more? It is obviously providing extra services such as message
framing, connection setup semantics, authentication, error handling, etc.,
hence it should be called an application protocol.
Proposal: Change this section's title to: "Section 2: Application Protocol
Requirements", and where ever references are made to "transport protocol"
elsewhere in the documents, change these to "application protocol".
============================
Draft-ietf-netconf-prot-00 defines an RPC mechanism - why? (Section 3)
BEEP already supports a wide range of native message exchange patterns (so
does SOAP). Surely NetConf could be carried directly in the binding's
underlying message exchange patterns where possible.
Why not put the current contents of a NetConf <RPC> message directly inside
a BEEP MSG message, and do away with the RPC wrapper from the NetConf
Protocol all together? Similar for other NetConf <RPC-xxx> messages:
NetConf-RPC BEEP
----------------------------------------
<RPC> MSG
<RPC-REPLY> RPY
<RPC-PROGRESS> ANS
<RPC-ABORT> ERR
<RPC-ERROR> ERR
SOAP has its own RPC mechanisms and these could easily be used for
NetConf-in-SOAP binding. SSH does not have message exchange patterns, so
yes, here an RPC mechanism is needed.
Proposal: Moving Section 3. "RPC Model" out of Draft-ietf-netconf-prot-00
and putting it into the Netconf-over-SSH binding when this appears. It will
radically simplify the design. State that the provision of message exchange
patterns is a job for the underlying binding. Also state that message
correlation (e.g. the "message-id" field in the current NetConf <RPC>
structure) now is moved to the binding (e.g. BEEP's messages have a
message-id already; SOAP has its own way of doing message correlation).
============================
Draft-ietf-netconf-prot-00 defines a way of ending sessions - why? (Section
5.6)
BEEP and the session architecture that some people wish to layer above SOAP
- have native ways to stop sessions.
Proposal - state it is up to the binding to end the session (Section 5.6 of
Draft-ietf-netconf-prot-00 could be moved to the SSH binding, where it would
be needed).
============================
A mandatory binding needs to be selected.
Proposal: Pick draft-lear-netconfbeep-00.
As NetConf requires multichannelled, peer-to-peer, secure sessions, BEEP is
a natural fit, and requires little additional work - if one were to mandate
NetConf-over-SOAP-over-HTTP then a range of additonal Web service specs [an
entire stack!] would also be needed (WS-Security, WS-SecureConversation,
WS-ReliableMessaging, WS-Trust, etc., etc.) and many of these are not yet
standardized, and are a much bulkier way of doing what is natural in BEEP.
Also, as Reliable SysLog is recommended for logging, it is likely that
complaint devices will already have the BEEP protocol inplace, so Netconf
over BEEP would be easy to add. Finally, even though
SOAP-over-HTTP-over-port80 is alluring because admittedly, it is everywhere
- it is recommended against in the the IETF's own best current practices
(BCP 56) -
"On the use of HTTP as a Substrate" (by Keith Moore]
ftp://ftp.rfc-editor.org/in-notes/bcp/bcp56.txt
I specifically refer you to section 3:
"Issues Regarding Reuse of Port 80
IANA has reserved TCP port number 80 for use by HTTP. It would not
be appropriate for a substantially new service, even one which uses
HTTP as a substrate, to usurp port 80 from its traditional use. A
new use of HTTP might be considered a "substantially new service",
thus requiring a new port, if any of the following are true:
o The "new service" and traditional HTTP service are likely to
reference different sets of data, even when they both operate on
the same host.
o There is a good reason for the "new service" to be implemented by
a separate server process, or separate code, than traditional HTTP
service on the same host, at least on some platforms.
o There is a good reason to want to easily distinguish the traffic
of the "new service" from traditional HTTP, e.g., for the purposes
of firewall access control or traffic analysis.
o If none of the above are true, it is arguable that the new use of
HTTP is an "extension" to traditional HTTP, rather than a "new
service". Extensions to HTTP which share data with traditional
HTTP services should probably define new HTTP methods to describe
those extensions, rather than using separate ports. If separate
ports are used, there is no way for a client to know whether they
are separate services or different ways of accessing the same
underlying service."
So, if NetConf is to support the IETF's own security recommendations for
layering non-hypertext services above HTTP, it would have to have HTTP on a
port other that port 80 - in which case I believe any support for
NetConf-over-SOAP-over-HTTP would be wiped out.
--
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/>