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

Re: DISCUSS: draft-ietf-netconf-beep

Yes but, there remains an inconsistency with a solid
requirement of the protocol spec. I don't see how you
can expect the IESG to approve in the same meeting a draft
that says you MUST do something and another draft that
says you don't need to. Would you rather I put a DISCUSS
on the protocol spec?

(I assume the terminology issue will get fixed and isn't
contentious.)

    Brian


Eliot Lear wrote:

Brian,

As Andy and I responded to Elwyn, this was discussed within the working
group.  The consensus was at the time that the client knows its a client
and the server knows its a server so this isn't really a problem.  I was
in the minority at the time.  My preference would be two separate BEEP
profiles, and this was in fact the case in an earlier version of the
document, as I recall.

Eliot
ps: whatever tool you're using to generate this email is generating
illegal destination addresses in the "To" field.


Brian Carpenter wrote:


Discuss:
(Based on Gen-ART review by Elwyn Davies)

The base NETCONF protocol spec talks about 'client/server' instead of 'manager/agent'. This document uses 'manager/agent' but needs to be
consistent with the base spec.

The base NETCONF protocol spec requires (in section 2):


  The transport protocol MUST provide a mechanism to indicate the
  session type (client or server) to the NETCONF protocol layer.


So where does the BEEP mapping do this? If that isn't defined,
it's a bug.










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