Minutes 2016 11 30

Meeting Materials	Attending
WebEx Recording 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 lesse. 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.