Subject: [Gen-art] Gen-art review of draft-ietf-netconf-beep-08.txt

From: Elwyn Davies <[email-masked]>
Date: Wed, 01 Mar 2006 11:05:15 +0000

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-ietf-netconf-beep-08.txt
Intended Status: Proposed Standard (WG submission)
Shepherding AD: Bert Wijnen
Review Trigger: IESG Telechat 2 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 <greeting>'.  This 
presumably means in the first Greeting message but it could also be 
talking about the <greeting> 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 <greeting> 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/<rpc> tag/<rpc> element/ (?)

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art