Subject: [Netconf] 5277 Backwards Compatibility: how to deliver

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 1 Dec 2016 01:27:53 +0000

Hi Mehmet,
Hi Mahesh,
Hi Benoit,

Item #6 in the NETCONF charter is: “Enhance RFC 5277 with the ability to delete subscriptions without closing the client session, to modify existing subscriptions, and to have multiple subscriptions on an established client session. These changes should not affect older clients that do not support these particular subscription requirements. The RPCs and the data models in RFC 5277 should be converted to YANG.”

Those attending the Event Notification Dezign Team today believe that it is better to Obsolete 5277 it rather than Enhance it.   The main reasons are:

·       The existing 5277 <create subscription> rpc and the new rpcs need to be in independent namespaces. Not supporting 5277 <create subscription> and a separate namespace / model will significantly simplify the new specification.

·       We can’t think of a reason why any YANG model developed for legacy 5277 namespace should be developed.  New development is more likely to focus on the new model and its new capabilities

·       Any clients & servers desiring to support the old capabilities can certainly do this.  Independent capability sets can be advertised.  Backwards compatibility is not compromised.

·       Leaving backwards compatibility to embedded server code significantly reduces new development needs.

As obsoleting 5277 with this new spec is a significant step, we wanted to get your and the community’s feedback and buy-in before we modify any of the documents in this direction.

Would such a move mean a charter change?   My suspicion is no as we are enhancing the functions supported by 5277 (but without bringing along the RPC).  Do you have any guidance here?   Is this worth having an interim meeting to discuss and finalize?

Thanks,
Eric

P.S.: Additional discussion on this is contained in minutes 2 to15 minutes of the WebEx audio recording below.

From: Eric Voit, November 30, 2016 5:58 PM

Minutes posted at:
https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30

·        As always, our DezignTM Team is a gathering of individuals providing informal input to NETCONF. We ask NETCONF WG to comment on our discussion results as a preparation for the WG consensus. Please approach Eric Voit if you want to be included directly in these meetings.

Meeting Materials

Attending

WebEx Recording<https://cisco.webex.com/ciscosales/lsr.php?RCID=87cde245293c47dd8cff3772739f66c4>
password: bXeveFV5

Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, Sharon Chisholm

Obsolete RFC5277 or 5277bis?

  *   If you are going to support both old and new capabilities, you will have your old 5277 code, and you will have your new code. Why develop a backwards compatible part of the spec which no one would or should implement. People should develop to the new capability.
     *   5277 already has enough changes to it (e.g., dataplane has moved to 6241 filtered notifications)
  *   Recommendation for people on today's call is to Obsolete 5277
  *   Must go to the WG, its chairs, and Benoit to confirm this recommendation before we adjust current documentation
Changes to the documents discussed today
[5277bis]

  *   Scrub for error types in various subscription states. Authorization and other errors should be reported using the protocol-specific error codes; not specialized errors per these new RPCs. They still need to be identified though. Distinguish error types from subscription state so that you know the state a particular error happened during.
  *   Expose operational state of subscriptions in a separate YANG model or container. (i.e., add “-state” into naming convention for the ro part)
  *   Should subscription-id and filter-id both be id? (double-check, but we can do to the shorter description “identifier”)
  *   Do we rename push-source to “originates from” to be more explicit/accurate? (better name is needed. Include it in the terminology section.)
  *   Section 2.3 has SHOULD for 5277 filters. Not sure why this isn’t a MUST. Also we need a better name for 5277 filters. This name doesn’t expose what is possible, and what is not. Especially if we jettison 5277 compatibility, we need a better name for 6241, and we need to define the boundaries of filter solution. Andy has a strawman proposal.
  *   Delete create-subscription RPC and legacy namespace should WG agree.
  *   Do we do a test-only operation? (Let’s not do this work without an advocate)
  *   We need a way to test if the filters are doing what we expect they are doing. (Perhaps counters/captures on an active subscription?)
  *   For configured subscriptions, make receiver key ip address and port. At this point we don’t want VRF
  *   Change source-vrf description to indicate that we should align with names from draft-ietf-rtgwg-ni-model-01 should it complete in time.
  *   start-time in the YANG model from startTime as we don’t have to worry about backwards compatible RPC.
  *   Make stream type string rather than identity (preference for identity, but not willing to fight. Note: this could change based on what happens with filters)
[Yang-push]

  *   Need to define error type for each subscription parameter such as “encoding not defined”, “Filter syntax not supported” or “filter complexity not supportable by platform”.
  *   Section 3.1 – Discussion on the Editors note - the addition of a “changes-only” flag for a periodic subscription. (Some support for this, but more discussion is needed as the work is non-trivial.)
  *   Section 3.8.4 – recommend removal (ok)
  *   Section 4.4: reduce this just to the new parameters (can we remove this entirely considering section 3.1? Or do we merge 3.1 into here?) (Eric talk to Alex, likely ok)
  *   Section 4.6.2 Is there any reason why we can’t have the timestamp on the yang push include the number of significant digits as expressed by trailing zeros if necessary on the “time-of-update”. This would let platforms express what they are capable of doing. (Note: seconds would be a minimum granularity). (we should go with this if possible. Susan H. is going to check on binary representations here to see if variable field lengths might pose a problem for an update.)
  *   Section 4.6.2 Do we do something on YANG-Push statistics (e.g. counters of object changes, of update messages)? (Both… Test and normal operations need to be covered.. Match to filters working operation question)
Dampening:

  *   Dampen can mean lessen. We should choose Damp or Dampen based on usage therefore.
     *   Google search for “route damping” = 4,850 hits.
     *   Google search for “route dampening” = 11,600 hits
  *   The more common usage is dampening, so we should stick with that.