Subject: Re: latest beep draft

From: "Arvind Jamwal" <[email-masked]>
Date: Fri, 1 Apr 2005 00:33:14 -0800

Sure, <session-id> would do the trick but I hate the idea of having xml
elements with overloaded meanings.

Also, I was wondering how you will define a common XML schema for the hello
message?
For the agent, <session-id> element is required and for the manager it is an
error to include it.

Having a role element will help.

-Arvind

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: <[email-masked]>
Cc: "'Eliot Lear'" <[email-masked]>; <[email-masked]>; "'netconf'"
<[email-masked]>
Sent: Thursday, March 31, 2005 12:30 PM
Subject: Re: latest beep draft

> Arvind Jamwal wrote:
>
> >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?
> >
> >
> 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
>
> >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
> >
> >Eliot Lear wrote:
> >
> >
> >
> >>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...
> >>
> >>
> >
> >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
> >
> >
> >
> >>Eliot
> >>
> >>Steven Berl (sberl) wrote:
> >>
> >>
> >>
> >>>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:
> >>>>
> >>>> - 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/>

--
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: "Arvind Jamwal" <[email-masked]>
Date: Mon, 4 Apr 2005 12:43:46 -0700

Hi Andy,

To make my point clear...

If we were to use just the <session-id>, then the schema for hello message
will have to be:

     <!--
       <hello> element
       -->
     <xs:complexType name="helloType">
       <xs:sequence>
         <xs:element ref="capability"/>
         <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
       </xs:sequence>
     </xs:complexType>
     <xs:element name="hello" type="helloType"/>

  With the above schema constraint, the node has no way to guess if
  the session-id was omitted by error or by intention (becasue the peer is a
manager).

  But, with the following schema constraint, the node will always know the
peer's role (manager/agent)
  and can give an error if <session-id> was omitted for the agent role.

     <!--
       <hello> element
       -->
     <xs:complexType name="helloType">
       <xs:sequence>
         <xs:element ref="capability"/>
         <xs:element ref="role" minOccurs="1" maxOccurs="1"/>
         <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
       </xs:sequence>
     </xs:complexType>
     <xs:element name="hello" type="helloType"/>

Thoughts?
-Arvind

----- Original Message -----
From: "Arvind Jamwal" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "'Eliot Lear'" <[email-masked]>; <[email-masked]>; "'netconf'"
<[email-masked]>
Sent: Friday, April 01, 2005 1:33 AM
Subject: Re: latest beep draft

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Apr 2005 16:11:28 -0700

>  the session-id was omitted by error or by intention (becasue the peer is a
I don't care that much one way or another.  If the WG wants to add this,
then the WG should speak up.

I don't think this is a very important corner case, since it's based on 
mis-implementation.
We are talking about a fundamental piece of data (session-id).  If an 
agent sends
a hello message that says "I'm an agent" but omits the session-id, then 
the protocol
specification has not been followed and the implementation is broken -- 
it doesn't
matter if the <role> element is there or not.

Andy

>>Also, I was wondering how you will define a common XML schema for the
>>    
>>
>hello
>  
>
>>message?
>>For the agent, <session-id> element is required and for the manager it is
>>    
>>
>an
>  
>
>>error to include it.
>>

---

From: "Arvind Jamwal" <[email-masked]>
Date: Mon, 4 Apr 2005 16:29:03 -0700

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, April 04, 2005 4:11 PM
To: Arvind Jamwal
Cc: 'Eliot Lear'; [email-masked]; 'netconf'
Subject: Re: latest beep draft

Arvind Jamwal wrote:

>If we were to use just the <session-id>, then the schema for hello 
>message will have to be:
>
>     <!--
>       <hello> element
>       -->
>  the session-id was omitted by error or by intention (becasue the peer 
>is a manager).
>  
>

I don't think this is a very important corner case, since it's based on
mis-implementation.
We are talking about a fundamental piece of data (session-id).  If an agent
sends a hello message that says "I'm an agent" 

How does the hello message say that?

but omits the session-id, then the protocol specification has not been
followed and the implementation is broken -- it doesn't matter if the <role>
element is there or not.

By omitting the session-id, it is on the contrary saying - "I am a manager".
An error condition conveys an opposite message....that is my whole concern.
And there is no way to catch this error or broken implementation of the
peer, except for maybe timing out.

Andy

>  But, with the following schema constraint, the node will always know 
>the peer's role (manager/agent)
>>Sure, <session-id> would do the trick but I hate the idea of having 
>>xml elements with overloaded meanings.
>>
>>>>On Behalf Of Andy Bierman
>>>>>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
>>>>>
>>>>neither send it or both send it, then the session should be shut 
>>>>down immediately.
>>>>
>>>>Andy
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Eliot
>>>>>
>>>>>>Not sure if it is too late for comments on this doc, but here it 
>>>>>>is anyway.
>>>>>>
>>>>>>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.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Apr 2005 19:25:54 -0700

>peer, except for maybe timing out.
I think you are making my point.
The agent always sends a session-id in its hello message.
The manager never sends a session-id in its hello message.
Anything else is broken.  The addition of a 'role' element has
no impact on the problem. (Simple boolean logic).   In fact, anything you
can possibly add can be mis-implemented in such a way as to not fix this 
minor problem.

A corner-case deadlock could exist where a dual-role entity connects to 
another
dual-role entity and both of them are waiting for the other to send
their hello message to decide if they should respond as an agent or a 
manager.
The 'role' element doesn't help here.  The solution is to force the 
connection
initiator to pick a role and send the appropriate hello.  The SW that is 
initiating
the connection better know why, and it can pick agent or manager.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Apr 2005 09:03:24 +0200

> then the WG should speak up.

I think it is simply important that the elements of procedure are clearly 
stated somewhere what expected behaviour is. Right now, the ID says:

   A server
   sending the <hello> element MUST include a <session-id> element
   containing the session ID for this NETCONF session.

Perhaps it helps to add a sentence stating that a client who does not
receive a <session-id> and a server receiving a <session-id> must not
continue and close the underlying transport or something like that.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany