Re: [Netmod-ver-dt] Version selection

["Reshad Rahman (rrahman)" <[e-mail]>]

Thanks Joe.

From: "Joe Clarke (jclarke)" <[e-mail]>
Date: Wednesday, October 23, 2019 at 4:50 PM
To: "Reshad Rahman (rrahman)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Netmod-ver-dt] Version selection



  1.  NETCONF experts please take a look at the NETCONF update.

Not saying I’m an expert, but the RPC looks funny to me.  Why can’t the package by CDATA?  How will you define an element for each and every package?  That is, should the RPC look more like:
<RR> Good point, right now it’s only for 1 top-level package. And yes what you have below is better than what I sent.

<rpc message-id="101"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
          <select-package>
            <yang-package-version>
              example-ietf-routing@1.3.1
            </yang-package-version>
          </select-package>
        </rpc>

Also, I don’t see the RPC defined in the included YANG module.  Are you waiting for feedback before doing that?
<RR>Yes and I ran out of time ☺

One other thing I noticed is that you say the following in Section 5.1.2:

Used by a client to select a YANG package version which
   has been advertised by the server via the mechanism described above
   in Section 5.1.1.  The YANG package version is selected for the
   lifetime of the NETCONF session, unless a different version of the
   YANG package is subsequently selected via this operation.

Then later:

Negative response: An <rpc-error> element is included in the <rpc-
   reply> if the request cannot be completed for any reason.  A <select-
   package> operation can fail for a number of reasons, such as the YANG
   package version is not supported by the server, or a different
   version of the YANG package has already been selected by another
   client.

How can a different client affect the current client’s session?  Meaning, if you and I are two clients both operation on the same server and you first set your package version, and then I set mine, why would mine fail simply because you set yours?

Now, it may be that only one version of a package can be used at a time across the entire server, but then that would break the per-session semantics.
<RR> Yes this is for the case where either a) package version can be selected once and after that is sticky OR b) different versions cannot be supported concurrently.


  1.
  2.  I’ve used @ as the separator for YANG package and version, e.g. example-ietf-routing@1.3.1<mailto:example-ietf-routing@1.3.1>, this is because @  cannot be in the revision-label and looks like it can’t be in the package-name either (pkg-identifier is of type yang:yang-identifier)

I’m fine with this notation.  I assume that whatever is in the “version” field of the package header would be used here?
<RR> Yes, this should be mentioned in the draft.



  1.
  2.  Joe had raised the issue of default package version if none is selected. Any suggestions on how to advertise the default version(s) in capabilities, what about @D after the revision-label e.g. “example-ietf-routing@1.3.1<mailto:example-ietf-routing@1.3.1>@D”? Rob, I don’t think your YL extensions has default for YANG package versions right now?

Make it bold in the capabilities list? :-D

Could another delimiter be used after the version like ‘;’ and then you can have:

?list=example-ietf-routing@1.1.0,example-ietf-routing@2.0.0;default

Right now, we’ll have to make sure ‘,’ doesn’t exist in a revision-label.
<RR> Works for me.

Regards,
Reshad.

Joe