Re: FW: Gen-art review of draft-ietf-netconf-beep-08.txt

[Eliot Lear <lear@cisco.com>]

Elwyn,

Thank you for your review.  Please find my responses below.
> 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.
>   

In the community we find ourselves, manager and agent are well
understood terms.  Anyone who does not understand them is unlikely to
implement the protocol.  If there is a bug, it is in the base
specification in the use of the terms client and server, as they can be
overloaded beyond recognition.

> 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.
>   
Apparently it did not sufficiently confuse you.  You understood what we
meant.
> The security considerations section specifies requirements and 
> operations rather than just discussing the threats and their mitigation.
>   

The security considerations section should be viewed in the context of
the base protocol.  I will not reiterate everything said there.

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

I have proposed a change to the mapping to address this point, but
ultimately it has boiled down to this: a manager knows its a manager and
an agent knows its an agent.  As it says in the draft at the end of
section 2.1:

  We now distinguish between manager  and agent, and it is assumed that
each knows its role in the
  conversation.

I would still prefer to have agent and manager profile roles, but that
was not the working group's choice.
>
> 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).
>   
Yes.  I would be happy to change the text to this if there are no
objections.
> 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.
>   
This is in the context of the SASL and TLS profiles.  Profiles in BEEP
are only advertised in the <greeting> section.  The reader is assumed to
be familiar with RFCs 3080 and 3081.
> 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.
>   

Unless there is a specific security concern, I would rather not further
block this draft.
> Certificate management:
> I was wondering whether some of the material from s5.2 of RFC3259 
> regardsing serverName etc could be usefully repeated here?
>   

Could you please be more specific as to how?
> 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.
>   
I would be happy to change the text to indicate that new capabilities
that make use of additional channels will require an update to this
mapping specification.
> s2.4, Locks:
> A pointer to the relevant section of ref [1] talking about locks would 
> be helpful
>   
The reader is presumed to be familiar with the core specification.
> 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.  
I would be happy to move this text forward to discussion of the two
profiles.
> It should probably make it clear that TLS is recommended 
> rather than mandatory.
>   
I believe that is already clear as my use of "ifs" in this document
exceeded my "if" quota ;-)
>
> 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.
>   
If there is one thing more you or others could check I wish it would be
this.  I believe I was careful to count characters in each example,.
> s1.1: s/transportlayer/transport layer/
>   

> s1.1: Expand CLI acronym.
>
>   
I believe this is a well understood acronym.
> s2.2, para 1: s/new channel/a new channel/
>
> s2.3: s/<rpc> tag/<rpc> element/ (?)
>   

Thank you again,

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