Subject: Re: [Netconf] Netconf Digest, Vol 88, Issue 2

From: jose Hernandez <[email-masked]>
Date: Mon, 1 Jun 2015 23:52:26 -0700

Glad you could identify the issue so it was the poor man who had you
working on it all night lmfao
 On Jun 1, 2015 9:48 PM, <[email-masked]> wrote:

> Send Netconf mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/netconf
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Netconf digest..."
>
>
> Today's Topics:
>
>    1. Re: WG Last Call for draft-ietf-netconf-call-home-04 and
>       draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and
>       server-model-06 available - All Open issues closed (Kent Watsen)
>    2. server-model #54: move idle-timeout from global
>       "session-options" to the "listen" tree? (Kent Watsen)
>    3. Re: WG Last Call for draft-ietf-netconf-call-home-04 and
>       draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and
>       server-model-06 available - All Open issues closed
>       (Juergen Schoenwaelder)
>    4. Re: How to augment RFC6470 to supply detail configuration
>       change information (Mandy Liu)
>    5. Re: How to augment RFC6470 to supply detail configuration
>       change information (Juergen Schoenwaelder)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 1 Jun 2015 22:51:36 +0000
> From: Kent Watsen <[email-masked]>
> To: Juergen Schoenwaelder <[email-masked]>,
>         "[email-masked]" <[email-masked]>
> Subject: Re: [Netconf] WG Last Call for
>         draft-ietf-netconf-call-home-04 and
> draft-ietf-netconf-server-model-06
>         WAS:FW: call-home-04 and server-model-06 available - All Open
> issues
>         closed
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Hi Juergen,
>
>
> On 3/19/15, 9:26 PM, "Kent Watsen" <[email-masked]> wrote:
>
> >>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder"
> >><[email-masked]> wrote:
> >>
> >>
> >>* sec 3: Are certificates sometimes represented as strings and
> >>  sometimes represented as binary?
> >
> >That's an oversight, they should all be binary.
>
>
> I was just looking to make this change and realized that I misspoke
> before.  The reason why one of the certificates is a string (not binary)
> is because it's intended to be a poor-man's leafref.   Recall before we
> had a read-only list of certs and a real leafref, but we subsequently took
> out the read-only list and now the description says this:
>
>     "An unordered list of certificates the TLS server can pick
>      from when sending its Server Certificate message.  The value
>      of the string is the unique identifier for a certificate
>      configured on the system.  How valid values are discovered
>      is outside the scope of this module, but they are envisioned
>      to be the keys for a list of certificates provided
>      by another YANG module";
>
>
>
> Makes sense?
>
> Thanks,
> Kent
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 2 Jun 2015 00:38:22 +0000
> From: Kent Watsen <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [Netconf] server-model #54: move idle-timeout from global
>         "session-options" to the "listen" tree?
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
>
> [This is a new issue]
>
> Currently, "idle-timeout" is configured in the global "session-options"
> tree, which applies to all connections, both listen and call-home. But it's
> unclear if idle-timeout makes sense for call home connections, and hence
> should be moved to being only under the listen tree.  Keep in mind that
> there are two types of call home connections: persistent and periodic.  The
> following describes the effect of idle-timeout on each.
>
> For persistent connections, it doesn't makes sense to me that the server
> would ever idle-timeout a connection. This perspective is bolstered by
> persistent connections having keep-alives, so the server can detect when a
> client connection has been lost and it needs to initiate a new one. An
> idle-timeout here would be unhelpful.
>
> For periodic connections, the idle-timeout is way too course (default 1
> hour). We use to have a "linger-timeout" for this purpose (default 30
> secs), but a side meeting in Dallas concluded that it was unneeded, as the
> client would close the connection as and when it was ready. Still, the
> intent is that the connection wouldn't stay open anywhere close to the
> periodic interval (default 5 mins). An idle-timeout here is nearly useless.
>
> So, if unhelpful for persistent connections and nearly useless for
> periodic connections, perhaps we should just move idle-timeout to the
> listen tree?  What do you think?
>
> Thanks,
> Kent
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/netconf/attachments/20150602/16e4ca74/attachment.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 2 Jun 2015 07:43:35 +0200
> From: Juergen Schoenwaelder <[email-masked]>
> To: Kent Watsen <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [Netconf] WG Last Call for
>         draft-ietf-netconf-call-home-04 and
> draft-ietf-netconf-server-model-06
>         WAS:FW: call-home-04 and server-model-06 available - All Open
> issues
>         closed
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Jun 01, 2015 at 10:51:36PM +0000, Kent Watsen wrote:
> >
> > Hi Juergen,
> >
> >
> > On 3/19/15, 9:26 PM, "Kent Watsen" <[email-masked]> wrote:
> >
> > >>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder"
> > >><[email-masked]> wrote:
> > >>
> > >>
> > >>* sec 3: Are certificates sometimes represented as strings and
> > >>  sometimes represented as binary?
> > >
> > >That's an oversight, they should all be binary.
> >
> >
> > I was just looking to make this change and realized that I misspoke
> > before.  The reason why one of the certificates is a string (not binary)
> > is because it's intended to be a poor-man's leafref.   Recall before we
> > had a read-only list of certs and a real leafref, but we subsequently
> took
> > out the read-only list and now the description says this:
> >
> >     "An unordered list of certificates the TLS server can pick
> >      from when sending its Server Certificate message.  The value
> >      of the string is the unique identifier for a certificate
> >      configured on the system.  How valid values are discovered
> >      is outside the scope of this module, but they are envisioned
> >      to be the keys for a list of certificates provided
> >      by another YANG module";
> >
> > Makes sense?
> >
>
> OK. What about the other then?
>
> It would IMHO be nice to have a keychain YANG model so that we could
> have a common way to deal with security credentials. I am struggling
> with the need to refer to certificates and other credentials in the
> LMAP YANG data model and I would love to be able to simply refer to a
> keychain data model instead of creating another ad-hoc solution.
>
> /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/>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 2 Jun 2015 06:22:25 +0000
> From: Mandy Liu <[email-masked]>
> To: Juergen Schoenwaelder <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Athanasios
>         Kyparlis <[email-masked]>, Robert Ottinger
>         <[email-masked]>, "[email-masked]" <
> [email-masked]>,
>         Kai Lin <[email-masked]>
> Subject: Re: [Netconf] How to augment RFC6470 to supply detail
>         configuration change information
> Message-ID:
>         <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Ok, thanks! Got your point.
> But here I want to use "data" to address the changed configuration data in
> the notification. Although "data" is in the notification, but because it is
> used to address the configuration data seems it still conflicts with the
> statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml"
> statement not be used to represent configuration data. "
>
> list edit {
>      leaf target {
>          type instance-identifier;
>         description
>         .....
>      }
>      leaf operation {
>          type nc:edit-operation-type;
>         description
>              .....
>      }
>      anyxml data;
>  }
>
> Regards,
> Mandy
>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Monday, June 01, 2015 5:55 PM
> To: Mandy Liu
> Cc: [email-masked]; Kai Lin; Robert Ottinger; [email-masked];
> Athanasios Kyparlis
> Subject: Re: [Netconf] How to augment RFC6470 to supply detail
> configuration change information
>
> Let me try to say it differently: Using anyxml in a notification does not
> cause a conflict with this statement in section 7.10 of RFC 6020:
>
>    Since the use of anyxml limits the manipulation of the content, it is
>    RECOMMENDED that the "anyxml" statement not be used to represent
>    configuration data.
>
> Note that configuration data is defined as follows:
>
>    o  configuration data: The set of writable data that is required to
>       transform a system from its initial default state into its current
>       state [RFC4741].
>
> Notification content is not configuration data.
>
> /js
>
> On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote:
> > Sorry, I don't get your point. But hopefully I addressed my question
> more clearly this time.
> >
> > The configuration change notification is generated when the NETCONF
> server detects that the <running> or <startup> configuration datastore has
> been changed by a management session. The notification summarizes the
> "edits" that have been detected. "  The structure of the "edit" is
> addressed in RFC6470 as below. What I want is to add the another leaf to
> address the "target" is changed to what. But because the "target" may be a
> container, a list, a leaf or a leaf-reference, etc. It could be any node of
> the tree. So a common format for addressing the "target" is changed to what
> is needed.
> > list edit {
> >     leaf target {
> >         type instance-identifier;
> >        description
> >        .....
> >     }
> >     leaf operation {
> >         type nc:edit-operation-type;
> >        description
> >             .....
> >     }
> > }
> >
> > Thanks,
> > Mandy
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:[email-masked]]
> > Sent: Monday, June 01, 2015 3:26 PM
> > To: Mandy Liu
> > Cc: [email-masked]; Kai Lin; Robert Ottinger;
> > [email-masked]; Athanasios Kyparlis
> > Subject: Re: [Netconf] How to augment RFC6470 to supply detail
> > configuration change information
> >
> > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote:
> >
> > > [...] So we need to find a common format for the "content" to
> > > accommodate different types of "target". what I can imagine is
> > > anyxml could be used. But seems it is not a good choice. Because
> > > based on RFC6020, it is not recommended to be used on configuration
> data.
> >
> > Since you plan to augment a notification, this won't be config true data
> (this is what the statement in RFC 6020 really hints at). See also the
> definition of 'configuration data' in section 3 of RFC 6020.
> >
> > /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/>
>
> --
> 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/>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 2 Jun 2015 08:47:44 +0200
> From: Juergen Schoenwaelder <[email-masked]>
> To: Mandy Liu <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Athanasios
>         Kyparlis <[email-masked]>, Robert Ottinger
>         <[email-masked]>, "[email-masked]" <
> [email-masked]>,
>         Kai Lin <[email-masked]>
> Subject: Re: [Netconf] How to augment RFC6470 to supply detail
>         configuration change information
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> But it is not the writable configuration data but more a copy of the
> configuration data that got changed. Anyway, if you want to insist
> that this is a violation of section 7.10 of RFC6020, then don't do
> it. I do not believe it is a violation of section 7.10 of RFC6020.
>
> /js
>
> On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote:
> > Ok, thanks! Got your point.
> > But here I want to use "data" to address the changed configuration data
> in the notification. Although "data" is in the notification, but because it
> is used to address the configuration data seems it still conflicts with the
> statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml"
> statement not be used to represent configuration data. "
> >
> > list edit {
> >      leaf target {
> >          type instance-identifier;
> >         description
> >         .....
> >      }
> >      leaf operation {
> >          type nc:edit-operation-type;
> >         description
> >              .....
> >      }
> >      anyxml data;
> >  }
> >
> > Regards,
> > Mandy
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:[email-masked]
> ]
> > Sent: Monday, June 01, 2015 5:55 PM
> > To: Mandy Liu
> > Cc: [email-masked]; Kai Lin; Robert Ottinger; [email-masked];
> Athanasios Kyparlis
> > Subject: Re: [Netconf] How to augment RFC6470 to supply detail
> configuration change information
> >
> > Let me try to say it differently: Using anyxml in a notification does
> not cause a conflict with this statement in section 7.10 of RFC 6020:
> >
> >    Since the use of anyxml limits the manipulation of the content, it is
> >    RECOMMENDED that the "anyxml" statement not be used to represent
> >    configuration data.
> >
> > Note that configuration data is defined as follows:
> >
> >    o  configuration data: The set of writable data that is required to
> >       transform a system from its initial default state into its current
> >       state [RFC4741].
> >
> > Notification content is not configuration data.
> >
> > /js
> >
> > On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote:
> > > Sorry, I don't get your point. But hopefully I addressed my question
> more clearly this time.
> > >
> > > The configuration change notification is generated when the NETCONF
> server detects that the <running> or <startup> configuration datastore has
> been changed by a management session. The notification summarizes the
> "edits" that have been detected. "  The structure of the "edit" is
> addressed in RFC6470 as below. What I want is to add the another leaf to
> address the "target" is changed to what. But because the "target" may be a
> container, a list, a leaf or a leaf-reference, etc. It could be any node of
> the tree. So a common format for addressing the "target" is changed to what
> is needed.
> > > list edit {
> > >     leaf target {
> > >         type instance-identifier;
> > >        description
> > >        .....
> > >     }
> > >     leaf operation {
> > >         type nc:edit-operation-type;
> > >        description
> > >             .....
> > >     }
> > > }
> > >
> > > Thanks,
> > > Mandy
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder
> > > [mailto:[email-masked]]
> > > Sent: Monday, June 01, 2015 3:26 PM
> > > To: Mandy Liu
> > > Cc: [email-masked]; Kai Lin; Robert Ottinger;
> > > [email-masked]; Athanasios Kyparlis
> > > Subject: Re: [Netconf] How to augment RFC6470 to supply detail
> > > configuration change information
> > >
> > > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote:
> > >
> > > > [...] So we need to find a common format for the "content" to
> > > > accommodate different types of "target". what I can imagine is
> > > > anyxml could be used. But seems it is not a good choice. Because
> > > > based on RFC6020, it is not recommended to be used on configuration
> data.
> > >
> > > Since you plan to augment a notification, this won't be config true
> data (this is what the statement in RFC 6020 really hints at). See also the
> definition of 'configuration data' in section 3 of RFC 6020.
> > >
> > > /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/>
> >
> > --
> > 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/>
>
> --
> 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/>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> ------------------------------
>
> End of Netconf Digest, Vol 88, Issue 2
> **************************************
>