Subject: latest beep draft

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Mar 2005 10:23:44 +0100

I believe I have addressed issues raised in the WG last call.  Can those 
who had comments (Juergen, Wes) take a quick scan?  In particular:

  - addressed security issues regarding SASL & TLS
  - added examples - are these enough?
  - clarified use of <hello> and <greeting>

The draft is at the following URL and is still relatively short:

http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt

Eliot

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Steven Berl \(sberl\)" <[email-masked]>
Date: Tue, 29 Mar 2005 10:08:15 -0800

Not sure if it is too late for comments on this doc, but here it is anyway.

Section 2.1 last paragraph
"it is assumed that each knows its role in the conversation."

What happens when this assumption is wrong? How is it detected, and what
actions are to be taken?

If I am a manager and I receive a <rpc> from someone I thought was an agent,
what should I do? Probably close the channel. 

If 2 agents connect to each other, they can exchange <hello> messages and
then sit there forever waiting for the other to send an <rpc> of some sort.
I suppose the agents could detect this by noticing that the received <hello>
has a <session-id> element, and that only other agents send this element.
The action again should probably be to close the channel.

This situation is specific to BEEP because the SSH mapping specifies that
only managers can initiate sessions. 

-steve 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eliot Lear
> Sent: Tuesday, March 22, 2005 1:24 AM
> To: netconf
> Subject: latest beep draft
> 
> I believe I have addressed issues raised in the WG last call. 
>  Can those who had comments (Juergen, Wes) take a quick scan? 
>  In particular:
> 
> to unsubscribe send a message to [email-masked] 
> with the word 'unsubscribe' in a single line as the message text body.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Mar 2005 22:22:20 +0400

We talked about this.  A netconf manager is certainly going to know it 
is a netconf manager and a netconf agent is certainly going to know it's 
a netconf agent.  This leaves two cases:
  o where the server is also a client
  o where a client is misconfigured

I think this could be handled with a netconf capability that says 
"iam-manager" or "iam-agent", but as I recall consensus was against me. 
  Now, I could introduce that concept as an option in the <greeting> in 
the BEEP protocol mappin if there are no objections.  That would handle 
the corner case...

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Mar 2005 11:29:11 -0800

Eliot Lear wrote:

> is a netconf manager and a netconf agent is certainly going to know 
> it's a netconf agent.  This leaves two cases:
> "iam-manager" or "iam-agent", but as I recall consensus was against 
> me.  Now, I could introduce that concept as an option in the 
> <greeting> in the BEEP protocol mappin if there are no objections.  
> That would handle the corner case...

I don't want special-case handling for BEEP.
Steve already provided the answer -- only a NETCONF peer acting in the 
agent role
should send the <session-id> element in the capabilities exchange.  If 
neither send it
or both send it, then the session should be shut down immediately.

Andy

>>> From: [email-masked] [mailto:[email-masked]] 
>>> On Behalf Of Eliot Lear
>>> I believe I have addressed issues raised in the WG last call. Can 
>>> those who had comments (Juergen, Wes) take a quick scan? In particular:
>>>

---

From: "Arvind Jamwal" <[email-masked]>
Date: Thu, 31 Mar 2005 11:32:37 -0800

Hi Andy,

Would it make sense to specify the role as part of the hello message rather
than relying on the presense/absense of session-id element?

What I am proposing is the following change to the hello message:

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>
         urn:ietf:params:xml:ns:netconf:base:1.0
       </capability>
       ...
     </capabilities>
     <role>agent</role>         <------- new role element
     <session-id>4</session-id>
   </hello>

Comments?

-Arvind Jamwal 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Tuesday, March 29, 2005 11:29 AM
To: Eliot Lear
Cc: [email-masked]; 'netconf'
Subject: Re: latest beep draft

I don't want special-case handling for BEEP.
Steve already provided the answer -- only a NETCONF peer acting in the agent
role should send the <session-id> element in the capabilities exchange.  If
neither send it or both send it, then the session should be shut down
immediately.

Andy

>> What happens when this assumption is wrong? How is it detected, and 
>> what actions are to be taken?
>>
>> If I am a manager and I receive a <rpc> from someone I thought was an 
>> agent, what should I do? Probably close the channel.
>> If 2 agents connect to each other, they can exchange <hello> messages 
>> and then sit there forever waiting for the other to send an <rpc> of 
>> some sort.
>> I suppose the agents could detect this by noticing that the received 
>> <hello> has a <session-id> element, and that only other agents send 
>> this element.
>> This situation is specific to BEEP because the SSH mapping specifies 
>> that only managers can initiate sessions.
>> -steve
>>
> to unsubscribe send a message to [email-masked] with the 
> word 'unsubscribe' in a single line as the message text body.

--
to unsubscribe send a message to [email-masked] with the word
'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Mar 2005 12:30:20 -0800

>than relying on the presense/absense of session-id element?
Why?
Can you think of a reason why the <session-id> can't be used?
By design, the agent gives out the session ID.  This isn't something
that can change once decided.

The WG already decided that it would be a very rare case (e.g., 
misconfiguration)
in which an agent connects to another agent or mgr to mgr.   And if this 
ever happens,
the worst case scenario is that it uses up 1 TCP control block on an 
idle connection.
That's why the #manager and #agent capabilities were removed from an 
early draft.

Andy