[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Gen-art review of draft-ietf-netconf-beep-08.txt
Not sure how much of this (if any) will make it into a DISCUSS,
but since (I believe) Eliot is in Europ, I decided to forward
rigth away, so Eliot can check and respond. Pls copy IESG
on your response (unless you just want to check with the WG
first). I did not analyze these comments yet myself, they
just came in.
Bert
-----Original Message-----
From: Elwyn Davies [mailto:elwynd@dial.pipex.com]
Sent: Wednesday, March 01, 2006 12:05
To: gen-art@ietf.org
Cc: Mary Barnes; Wijnen, Bert (Bert)
Subject: Gen-art review of draft-ietf-netconf-beep-08.txt
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/ (?)
--
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/>