Re: NetConf should fully exploit BEEP's rich features

[Eliot Lear <lear@cisco.com>]

Eamon O'Tuathail wrote:
> 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". 

I agree with this change, and there's every indication based on a note 
from the RFC Editor earlier in the year to the IETF that he would not 
let the document through without this change (the word "transport" is 
one of his nits).

> ============================
>
> 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

While these two might be fine, the other two don't map well given that 
thye have semantic meaning above the BEEP layer.

> <RPC-PROGRESS>       ANS 
> <RPC-ABORT>          ERR
> <RPC-ERROR>          ERR 

> ============================
>
> 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).  

I think this is possible.  HOwever, the problem with this, and your 
previous discussion, is that it means that the XML starts changing 
between transport bindings and I'm not sure that's such a hot idea.  It 
means that if someone is trying to debug this stuff they have to rewrap 
everything- not a simple cut and paste operation.  I also would like to 
know why you think <RPC> is expensive.

Eliot




--
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/>