Document: draft-ietf-netconf-beep-08.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Wednesday 3/1/2006 5:05 AM CST IESG Telechat Date: Thursday, 02 March 2006 Summary: This document is not ready for PS. There is a considerable lack of clarity in mapping the requirements and roles between the various protocols which are being combined in this protocol, and the manager/agent terminology used has been eschewed by NETCONF in favour of client/server. If used at all manager/agent terminology should be confined to the 'reversability' motivation in the introduction. The emphasis on reversability may be confusing: Checking with the NETCONF protocol, if I understand correctly, a given endpoint in a session is confined to being a client or a server. Thus although a BEEP channel is reversible the NETCONF session that runs over it is not and indeed the transport protocol has to tell NETCONF which sort of endpoint (client or server) it is. The security considerations section specifies requirements and operations rather than just discussing the threats and their mitigation. Review: Endpoint roles: There are three pairs of terms in use in the draft for the roles of the two ends of the conversation: 1. manager and agent (sort of implicitly how NETCONF would use the profile) 2. listener and initiator (BEEP) 3. client and server (TLS) The mapping between the terms in 1 and 2 is apparently explained in s2.1 but this explanation is not really a complete reflection of the situation explained in the BEEP RFC: ie the client/server terminology for the initial setup followed by the listener/initiator terminology for subsequent exchanges. In turn the mapping between 2 and 3 is not made explicit - I thought I could guess but after reflection I am not absolutely sure and it would be sensible to make it absolutely clear. However NETCONF does not talk about managers and agents but about clients and servers, and BEEP also talks about clients and servers after the channel is set up. So we really ought to be talking about four pairs of roles and how they interrelate: 1. NETCONF client and server (this is what the profile has to support) 2. BEEP listener and initiator (setting up a channel from either end) 3. BEEP client and server (mapping to NETCONF and emphasising that it is not tied to listener/initiator roles) 4. TLS client and server (not sure which way round this is supposed to map) I don't think the document overall expresses what needs to be said here and also doesn't give the semantics to express which way round the eventual NETCONF client/server connection is going to be setup. Message and object conventions: BEEP messages vs XML objects: Much as I like to see the proper pleasantries being exchanged before the manager and agent get down to business, I think that when para 1 of s2.1 says 'greetings are exchanged' I think it means '(BEEP) Greeting messages are exchanged' (2 places). In para 5 of s2.1 we then have 'in the first BEEP '. This presumably means in the first Greeting message but it could also be talking about the element in that message - this is a bit confusing unless you are very familiar with BEEP. I think it would be best to say 'in the first BEEP Greeting message' here, or alternatively 'in the element of the first BEEP Greeting message. Version of SASL PLAIN to be used: This specification refers to RFC2595 but the SASL PLAIN mechanism is currently under revision (see draft-ietf-sasl-plain-08.txt). Should this (new) specification be using the new PLAIN specification? The latter part of para 5 of s2.1 seems a bit garbled and tautologous - rework needed. Certificate management: I was wondering whether some of the material from s5.2 of RFC3259 regardsing serverName etc could be usefully repeated here? Channels: If I understand correctly, everything in s2.1 leads to the first BEEP channel (channel 0) being established between a pair of elements. I think it would be good to mention channel 0 here because otherwise it makes its first appearance in s2.4 when it is being closed. Extra channels: > > Certain NETCONF capabilities may require additional BEEP channels. > When such capabilities are defined, a BEEP mapping must be defined > as well > The phraseology used here doesn't make it very clear if this is about possible future extensions or something that already exists. If some do exist it would be good to give an example. I am not sure how the second sentence ties in with the original statement in the abstract i.e. that this document *is* the BEEP mapping for NETCONF! This probably ought to go in a separate extensibility section. s2.4, Locks: A pointer to the relevant section of ref [1] talking about locks would be helpful s3, requirements: The material after the second sentence of the second paragraph is about requirements and specification of how TLS and SASL are to be used. This doesn't belong here. It should all be specified before we get to this section. It should probably make it clear that TLS is recommended rather than mandatory. Editorial nits: [Abstract: I take it from draft-netconf-prot that NETCONF is not an acronym.] BEEP messages: It doesn't desperately matter but are the message character counts right? I wasn't sufficiently anally retentive to check them. s1.1: s/transportlayer/transport layer/ s1.1: Expand CLI acronym. s2.2, para 1: s/new channel/a new channel/ s2.3: s/ tag/ element/ (?)