Subject: [Netconf] netconf server listening endpoints

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jul 2014 11:00:55 +0200

Hi,

draft-ietf-netconf-server-model-01 uses this model for listening
endpoints:

         +--rw listen
            +--rw ssh {ssh-listen}?
            |  +--rw (one-or-many)?
            |     +--:(one-port)
            |     |  +--rw port?        inet:port-number
            |     +--:(many-ports)
            |        +--rw interface* [address]
            |           +--rw address    inet:host
            |           +--rw port?      inet:port-number
            +--rw tls {tls-listen}?
               +--rw (one-or-many)?
                  +--:(one-port)
                  |  +--rw port?        inet:port-number
                  +--:(many-ports)
                     +--rw interface* [address]
                        +--rw address    inet:host
                        +--rw port?      inet:port-number

In other data models, we used a pattern that looks like this:

   +--rw listen* [name]
      +--rw name        string
      +--rw (transport)
         +--:(ssh) {ssh-listen}?
            +--rw ssh
               +--rw address    inet:ip-address
               +--rw port?      inet:port-number   
         +--:(tls) {tls-listen}?
            +--rw tls
               +--rw address    inet:ip-address
               +--rw port?      inet:port-number   

The main differences are:

 - There is no shortcut for configuring just a different port. In
   fact, the semantics of this in the I-D are not clear; if I set the
   port to 1234, does it mean I am listening on this port on all
   interfaces for all versions of IP supported?

 - Every configured transport endpoint gets keyed by an artificial
   key. This allows for extensions, e.g., to support VRFs, without
   having to replace the definition. The solution in the I-D also has
   the problem that I can't listen on multiple ports on the same IP
   address since the interface list is keyed by address.

/js

PS: The Tree Diagram text should explain the notation of features.

-- 
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: Kent Watsen <[email-masked]>
Date: Thu, 10 Jul 2014 02:10:37 +0000

The "one-or-many" was discussed during the meeting in London (I think
Martin skeptically said it was interesting), but no follow-up discussion
on list and thus it's still in the current version.

BY way of explanation, let me throw out that I came up with this construct
hoping to optimize what I perceived to be a common case of just needing to
just configure a port value, while also needing to configure more than one
specific interface/address.  Perhaps its not common and worse, as you note
below, the alternate choice doesn't support multiple ports on the same IP
address (though why this would be needed I'm unsure).  Lastly, I think you
rightly point out that it bucks tradition - I didn't do this
intentionally, I was just doing what I though made sense to me.

That said, I wonder if there is any merit to discussing if we can do
better.  Especially in the area of enabling a service on more than one
specific interface/address, something not supported at all by the current
strategy?

Thanks,
Kent

On 7/9/14, 5:00 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Jul 2014 14:13:26 +0200

> specific interface/address, something not supported at all by the current

The 'listen' node in my proposal is a list and hence you can of course
listen on more than one specific interface/address.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Jul 2014 22:31:30 +0000

Hi Juergen,

> PS: The Tree Diagram text should explain the notation of features.

The text describing tree diagram notation is in section 1.2, which does
seem far removed from the sections depicting tree diagrams.  What makes
sense to me is to add a reference to section 1.2 from these sections -
makes sense?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jul 2014 11:43:06 +0200

> sense to me is to add a reference to section 1.2 from these sections -

Perhaps it helps but in any case, this does not resolve the issue that
the feature notation (e.g., {ssh-call-home}?) is not defined in the
text in section 1.2.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Jul 2014 16:16:00 +0000

>the feature notation (e.g., {ssh-call-home}?) is not defined in the

I had copy/pasted this text out of another current draft, I'd assumed it
was correct.  Is there a definitive boilerplate that should be used?
Looking at `pyang`, I get:

$ pyang --tree-help

Each node is printed as:

<status> <flags> <name> <opts> <type> <if-features>

  <status> is one of:
    +  for current
    x  for deprecated
    o  for obsolete

  <flags> is one of:
    rw  for configuration data
    ro  for non-configuration data
    -x  for rpcs
    -n  for notifications

  <name> is the name of the node
    (<name>) means that the node is a choice node
   :(<name>) means that the node is a case node

   If the node is augmented into the tree from another module, its
   name is printed as <prefix>:<name>.

  <opts> is one of:
    ?  for an optional leaf or choice
    !  for a presence container
    *  for a leaf-list or list
    [<keys>] for a list's keys

  <type> is the name of the type for leafs and leaf-lists

  <if-features> is the list of features this node depends on, printed
    within curly brackets and a question mark "{...}?"

This seems OK to me.   Alternatively, maybe we should formally define tree
notation in a RFC? 

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jul 2014 20:51:57 +0200

On Thu, Jul 17, 2014 at 04:16:00PM +0000, Kent Watsen wrote:
> was correct.

It might be correct in that context (if the tree diagrams do not show
features).

> Is there a definitive boilerplate that should be used?

Nope.

> Looking at `pyang`, I get:

But not good boilerplate.
 
> This seems OK to me.  Alternatively, maybe we should formally define
> tree notation in a RFC?

Not sure for 'formally' means but yes the boilerplate can be revised
(and perhaps Andy can edit a common complete version of the
boilerplate into the guidelines document).

/js