Subject: [Netconf] interoperability testing report

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Dec 2008 16:33:23 +0100

Hi,

I am attaching a draft report of the interoperability tests we have
done at Jacobs University. We plan to continue this work and we are of
course interested to get more implementations so that we get a more
complete picture. If you want to help us, please get in touch with me.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Mon, 15 Dec 2008 17:51:21 +0800

Hi Juergen,

I am curious about the treatment of the hello (or the absence).
In Section 8.1 of the RFC we see 
"
When the NETCONF session is opened, each peer
   (both client and server) MUST send a <hello> element containing a
   list of that peer's capabilities.  Each peer MUST send at least the
   base NETCONF capability, "urn:ietf:params:netconf:base:1.0".
"
The <hello> is MUST requirement. What is not clear is what needs to be
done 
if the first message received is not a HELLO. Later in the section we
are told if
the <hello> is the wrong format to hang up. I seem to recall the
standard once said 
to hangup but maybe I am recollecting an earlier draft draft.
Perhaps we need to clarify the RFC in this regards ?

James.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Saturday, December 13, 2008 2:33 AM
To: [email-masked]
Subject: [Netconf] interoperability testing report

Hi,

I am attaching a draft report of the interoperability tests we have done
at Jacobs University. We plan to continue this work and we are of course
interested to get more implementations so that we get a more complete
picture. If you want to help us, please get in touch with me.

/js

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Mon, 15 Dec 2008 17:51:21 +0800

Hi Juergen,

James.

-----Original Message-----

Hi,

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Dec 2008 11:01:10 +0100

On Mon, Dec 15, 2008 at 05:51:21PM +0800, James Balestriere (jbalestr) wrote:
 
> done if the first message received is not a HELLO.

This is just one instance of RFC 4741 not being totally clear how
errors are to be handled. Some people might say this is goodness since
a server can be lenient and deal with clients not sending a <hello>
message. Other people might claim that a client not sending <hello> is
a fatal error. Ideally, this would be worked out.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Dec 2008 11:01:10 +0100

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Dec 2008 04:03:50 -0800

> a fatal error. Ideally, this would be worked out.

It is hard to interpret 8.1, para 3 in this way.
You really have to try hard.  However, the last
sentence could be changed:  s/both cases/all cases/

It was very clearly the intent of the WG that the <hello>
MUST be sent by both peers and both peers MUST From [email-masked]  Mon Dec 15 04:04:02 2008
Date: Mon, 15 Dec 2008 04:03:50 -0800
From: Andy Bierman <[email-masked]>
To: "James Balestriere (jbalestr)" <[email-masked]>, 
 [email-masked]
Subject: Re: [Netconf] interoperability testing report
Sender: [email-masked]

> a fatal error. Ideally, this would be worked out.

It is hard to interpret 8.1, para 3 in this way.
You really have to try hard.  However, the last
sentence could be changed:  s/both cases/all cases/

It was very clearly the intent of the WG that the <hello>
MUST be sent by both peers and both peersaccept the
others base capability.  If not, the transport session MUST
be terminated instead of proceeding with session setup.

Phil is the one always reminding us that we need to future-proof
our YANG modules, yet the whole point of the <hello> exchange
MUST requirement seems to be missed by the Juniper implementation.

> /js

Andy

 MUST accept the
others base capability.  If not, the transport session MUST
be terminated instead of proceeding with session setup.

Phil is the one always reminding us that we need to future-proof
our YANG modules, yet the whole point of the <hello> exchange
MUST requirement seems to be missed by the Juniper implementation.

> /js

Andy

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Tue, 16 Dec 2008 05:23:19 +0800

Yes, it is one thing to handle errors to an identified peer, but when
you consider
the weight of the MUST requirement, without the HELLO it is hard to
determine you 
have connected to a NETCONF peer, let alone a client or server peer,  in
the first place.
Then considering Andy's point where you haven't established an overlap
of capabilities,
What is a sensible reply to send when you don't know the capabilities
and supported
schemas of the peer ?

When you consider the defined handling of the SESSION-ID whose intent
seems to be to stop 
client-client and server-server peers accidentally establishing,
I think it is a small inference to say if the peer does not identify it
role or capabilities
it should be terminated.

James.

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, December 15, 2008 11:04 PM
To: James Balestriere (jbalestr); [email-masked]
Subject: Re: [Netconf] interoperability testing report

Juergen Schoenwaelder wrote:
>> The <hello> is MUST requirement. What is not clear is what needs to 
>> be done if the first message received is not a HELLO.
> 

It is hard to interpret 8.1, para 3 in this way.
You really have to try hard.  However, the last sentence could be
changed:  s/both cases/all cases/

It was very clearly the intent of the WG that the <hello> MUST be sent
by both peers and both peers MUST accept the others base capability.  If
not, the transport session MUST be terminated instead of proceeding with
session setup.

Phil is the one always reminding us that we need to future-proof our
YANG modules, yet the whole point of the <hello> exchange MUST
requirement seems to be missed by the Juniper implementation.

Andy

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Tue, 16 Dec 2008 05:23:19 +0800

James.

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, December 15, 2008 11:04 PM
To: James Balestriere (jbalestr); [email-masked]
Subject: Re: [Netconf] interoperability testing report

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Dec 2008 13:58:31 -0800

> I think it is a small inference to say if the peer does not identify it

My main point was that it hard to change the protocol in
the future in non-backward compatible ways if the <hello>
check is skipped by the agent.  We want to force an
application to recognize that a down-rev protocol version
is needed for some agent (agent terminates session
will get its attention).  This is better than letting
the manager silently assume the agent supports the new version.

The base capability exchange needs lots of clarification
in 4741-bis.  Let's say there is a new base URI someday (2.0)?
Does each peer send all the versions they support, and
both peers figure out which is the newest version
they have in common?  Does the client sent the new URI, see if
it works, and if not, try again with the old one?
I don't think these protocol procedures are spelled out
in the current text.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Dec 2008 13:58:31 -0800

Andy