Subject: [Netconf] Require clarification when NETCONF server receives Interleave Capability without Notification Capability

From: Rohit Pobbathi <[email-masked]>
Date: Thu, 13 Dec 2012 10:01:40 +0530

Hi,

When NETCONF server receives Interleave capability from NETCONF client
without notification capability what should be the behavior of NETCONF
server ?

Please let me know what expected behavior is.

Here are my thoughts :

                Since notification capability is not exchanged, remove
interleave capability in session supported capabilities and behave as if
normal session i.e. receive, process and respond to requests on session
without notification support.

or

                Create session and don't allow any operations i.e. dead
session because interleave capability is dependent on notification
capability.

or

      Don't create session since exchange of capabilities failed due to
notification capability dependency.

Rgds,

Rohit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Dec 2012 08:32:35 +0100

> notification capability dependency.

I think the Postel principle applies - your server should ignore it
for the sake of interoperability. It may log this though.

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Dec 2012 09:25:39 +0100 (CET)

Hi,

> without notification capability what should be the behavior of NETCONF

These capabilities are used for the *server* to inform the client
about what operations it (the server) supports.

A client that wants to create a notifcation or use interleave does not
have to advertise anything to the server.

So the server ignores these capabilities if they are sent from a
client.

/martin

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 13 Dec 2012 09:26:34 +0100

Why would the server even care about what capabilities the client 
supports (except base NETCONF capabilities which indicate protocol 
version)? A client adapts to the server, not the other way around. This 
is only true while, when it comes to interaction between a client and a 
server, everything is initiated on the client side (currently the case).

This came up during inter-ops too. I think it should be made clear 
whether the only negotiation done during hello exchange is for protocol 
version and if negotiating anything else is even standard. This is 
something individual capabilities appear to handle and since no NETCONF 
capability except base have text which would require both peers to 
advertise it, negotiating anything else is non-standard.

Note that not clarifying this could lead to server implementations which 
require that a client advertises the exact same capabilities as the 
server did. We had at least one example of such an implementation during 
inter-ops which should have raised some flags.

Jernej

Dne 13.12.2012 5:31, pis(e Rohit Pobbathi:
> interleave capability in session supported capabilities and behave as 
> if normal sessioni.e. receive, process and respond to requests on 
> session without notification support.
>
> or
>
>                 Create session and don't allow any operations i.e. 
> dead session because interleave capability is dependent on 
> notification capability.
>
>                                 or
>
>       Don't create session since exchange of capabilities failed due 
> to notification capability dependency.
>
> Rgds,
>
> Rohit
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Dec 2012 10:30:26 +0100

>> without notification capability what should be the behavior of NETCONF

Maybe it is just the usual server versus client confusion?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Dec 2012 07:18:50 -0800

> Maybe it is just the usual server versus client confusion?
Yes -- the client can send whatever capabilities it wants,
except the server only looks for base:1.0 and base:1.1.

The server cannot send just :interleave: (see 6.2 below)

6.1.  Description

   The :interleave capability indicates that the NETCONF peer supports
   the ability to interleave other NETCONF operations within a
   notification subscription.  This means the NETCONF server MUST
   receive, process, and respond to NETCONF requests on a session with
   an active notification subscription.  This capability helps
   scalability by reducing the total number of NETCONF sessions required
   by a given operator or management application.

6.2.  Dependencies

   This capability is dependent on the notification capability being
   supported.

> Lada

Andy