[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: last call comments on the mapping documents

Juergen,

Just to be clear:

a) This document uses the "application protocol" terminology which I
   dislike (see also my comments on the NETCONF protocol definition).

b) Section 1.1:

            This "bidirectionality" allows for either side to play
    the role of the manager with no protocol changes.  Either side can
    open a channel. Either size could initiate an RPC.

   I think the text confuses BEEP's capability to initiate a session
   from either side with the manager/agent roles actually being used.
   Perhaps the text simply wanted to say:

This "bidirectionality" allows for either side to open a channel.

   The rationale here is that NETCONF clearly assumes manager/agent
   roles and it is rather clear who initiates NETCONF transactions.


I've changed the text here to say as follows:

  This "bidirectionality allows either manager or agent to initiate a
  connection.


c) Section 1.1:

    This is
    particularly important to support operational models that involve
    small devices connecting to a manager, and those devices that must
    reverse the management connection in the face of firewalls and NATs.

   I suggest to remove the work "small" as it does not really add
   value - I might actually have a big device that prefers to take the
   initiative (and how decides what small is anyway?).

Ok, I've removed the word small, as it clearly didn't impart what I was thinking, which is large numbers of intermittantly connected devices. New text will read as follows:

    This is particularly important to support large number of
    intermittantly connected devices, as well as those
    devices that must reverse the management connection in the face of
    firewalls and NATs.






d) Section 1.1:

    The SASL profile used by BEEP allows for a simple and direct mapping
    to the existing security model for CLI, while TLS provides a strong
    well tested encryption mechanism with either server or server and
    client-side authentication.

   I learned in the ISMS WG that SASL over TLS is not necessarily
   secure. Has beep fixed this problem or do we better explain the
   issue here and/or in the security considerations section?

Can you please elaborate? I can envision problems where if client-side certificates are in use and EXTERNAL SASL was in play. Is that what you are referring to? Wes would you care to comment?


e) Section 2.1: Is the "should" in this section actually a SHOULD? 

It's a SHOULD.


f) Section 2.2:

    The manager now establishes an NETCONF a new channel.

   Replace with:

The manager now establishes a new channel. 

Ok.


g) Section 2.3:

   I suggest to write NETCONF XML elements exactly as defined in the
   NETCONF specification. Thus, <RPC> should be written in lowercase
   as <rpc>.


That was the intent.  Thanks.



h) Section 2.3:

There is an odd line break in the last sentence of this section.

Probably a tool issue. I'll check it. 

i) Section 2.5:

    There are two commands in the BEEP profile.  <rpc> and <rpc-reply>.

   I am not a BEEP expert, but I am wondering how the <hello> messages
   are mapped to BEEP. Should the DTD not specify something for them?


Yep.

Note that I did not check the DTD as I am not a BEEP expert. Perhaps /mtr should take a look at it. Note that there are some minor
indentation oddities in the DTD part. 

Good idea.


j) What is really missing in the whole document is an example. Ideally,
one would simply use the example contained in the ssh mapping document and show the same example in the BEEP mapping. This would
add quite much clarity and allows people to better understand how
NETCONF over BEEP messages will actually look like on the wire.

Yes. I am going to add some examples, specifically as relates to SASL, <hello>, and perhaps a simple operation.


k) Section 4:

   I think it is important to tell IANA precisely that a port number
   for NETCONF over BEEP/TCP is requested. Or do we assume that all
   NETCONF over xxxx/TCP mappings share the same port number?

Absolutely not! I have already filled out a template and will modify the IANA considerations accordingly.


In summary, I think the BEEP mapping document still needs some work.
Especially an example is missing in my view and the DTD stuff probably
needs a bit more work and proof checking.


Ok.  Draft to follow.

Thanks,

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