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

From: MehmetErsue <[email-masked]>
Date: Fri, 2 Dec 2016 21:43:34 +0100

Hi Eric, All,

yes, we need a charter change since there is a difference between enhancing
and replacing.
As I remember the charter discussion people were keen of having backwards
compatibility because of deployed implementations.

I believe we need to understand better the implications and what kind of
"replacing" we would strive for.
Does replacing mean full deprecation of 5277 or will the compatibility
between e.g. old client and new server be possible?

I believe we need a discussion on this on the maillist and get the opinion
of all parties.
At the end the WG will decide.

@All:
Please comment on replacing instead of enhancing 5277.
Please explain why you are in favor of replacing or against.
If you are in favor please explain what kind of replacing (i.e.
compatibility level) you would like to have.
If you are in favor of keeping 5277 as standard and developing an
additional independent notification mechanism please make its case.

Thanks,
Mehmet

On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) <[email-masked]> wrote:

> 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.
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

-- 
Cheers,
Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Dec 2016 13:09:36 -0800

Hi,

This is a gray area. How much old functionality
has to remain to call it a 'bis' draft?
If we are working on new features hat do not exist in RFC 5277,
using a 5277bis draft that obsoletes 5277 seems OK.
I think the update rules only apply wrt/ standards track status.
Since we are cycling at Proposed Standard, that does not matter.

One option is to keep the 5277bis draft, but just remove all the parts that
do not apply to the new solution.

Andy

On Fri, Dec 2, 2016 at 12:43 PM, MehmetErsue <[email-masked]> wrote:

> Hi Eric, All,
>
> yes, we need a charter change since there is a difference between
> enhancing and replacing.
>> ·       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.
>>
>> P.S.: Additional discussion on this is contained in minutes 2 to15
>> minutes of the WebEx audio recording below.
>>
>>
>>
>> Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard,
>> Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, Sharon
>> Chisholm
>>
>>    - For configured subscriptions, make receiver key ip address and
>>    port. At this point we don’t want VRF
>>    - 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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 2 Dec 2016 15:20:20 -0800

[Chair hat off]

Eric, 

What would help is to understand what the backward compatibility section would look like with your proposal. Currently it says that 5277bis will advertise "urn:ietf:params:netconf:capability:notification:1.0” and "urn:ietf:params:netconf:capability:notification:1.1”. Clients can then choose which capability they are capable of and want to support. With the new proposal, are we dropping advertisement of "urn:ietf:params:netconf:capability:notification:1.0”?

If the namespaces are truly different, and the server already supports 5277, what would be the implication of having two <create-subscription>, in two different namespaces?

[Chair hat on]

Echoing what Mehmet has already said. This is essentially a WG call. If you like/do not like this proposal, or have questions about it, this would be the time to speak up.

Cheers.

> On Dec 2, 2016, at 12:43 PM, MehmetErsue <[email-masked]> wrote:
> 
> Hi Eric, All,
> 
> yes, we need a charter change since there is a difference between enhancing and replacing. 
> As I remember the charter discussion people were keen of having backwards compatibility because of deployed implementations. 
> 
> I believe we need to understand better the implications and what kind of "replacing" we would strive for. 
> Does replacing mean full deprecation of 5277 or will the compatibility between e.g. old client and new server be possible? 
> 
> I believe we need a discussion on this on the maillist and get the opinion of all parties.
> If you are in favor please explain what kind of replacing (i.e. compatibility level) you would like to have.
> If you are in favor of keeping 5277 as standard and developing an additional independent notification mechanism please make its case.
> 
> Thanks,
> Mehmet 
> 
> 
> On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <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.
>  
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> 
> 
> 
> 
> -- 
> Cheers,
> Mehmet
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh Jethanandani
[email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 2 Dec 2016 23:49:11 +0000

From: Mahesh Jethanandani, December 2, 2016 6:20 PM

[Chair hat off]

Eric,

Yes.  Anyone who wants to use existing 5277 would just leverage to the old namespace.

There would be no <create-subscription> in 1.1.   With 5277bis the recommended RPC going forward is <establish-subscription>.  In this way everything stays independent.  But a server could chose to support both 1.0 & 1.1.   This gives backwards compatibility in a single deployment.

[Chair hat on]

I am absolutely good to go with whatever the WG decides.   I do believe that obsoleting 5277 makes specification and implementation simpler, with no meaningful loss of functionality.

Eric

Cheers.

On Dec 2, 2016, at 12:43 PM, MehmetErsue <[email-masked]<mailto:[email-masked]>> wrote:

Hi Eric, All,

On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mehmet,
Hi Mahesh,
Hi Benoit,

•       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.

Thanks,
Eric

•        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

  *   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.

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

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

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 3 Dec 2016 09:50:06 +0100

Hi,

I can't follow discussions if people use email clients that do not do
proper quotations. https://en.wikipedia.org/wiki/Posting_style

/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/>

---

From: "Jonathan Hansford" <[email-masked]>
Date: Sat, 3 Dec 2016 10:17:58 -0000

Are you proposing a specific style of quoting, or are any of those listed acceptable? The Wikipedia page doesn't identify what "proper quotations" are.

Jonathan

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: 03 December 2016 08:50
> To: Eric Voit (evoit) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver
> 
> Hi,
> 
> I can't follow discussions if people use email clients that do not do proper
> quotations. https://en.wikipedia.org/wiki/Posting_style
> 
> /js
> 
> > What would help is to understand what the backward compatibility section
> would look like with your proposal. Currently it says that 5277bis will
> advertise "urn:ietf:params:netconf:capability:notification:1.0” and
> "urn:ietf:params:netconf:capability:notification:1.1”. Clients can then choose
> which capability they are capable of and want to support. With the new
> proposal, are we dropping advertisement of
> "urn:ietf:params:netconf:capability:notification:1.0”?
> >
> > If the namespaces are truly different, and the server already supports
> 5277, what would be the implication of having two <create-subscription>, in
> two different namespaces?
> >
> > There would be no <create-subscription> in 1.1.   With 5277bis the
> recommended RPC going forward is <establish-subscription>.  In this way
> everything stays independent.  But a server could chose to support both 1.0
> & 1.1.   This gives backwards compatibility in a single deployment.
> >
> > [Chair hat on]
> >
> > Echoing what Mehmet has already said. This is essentially a WG call. If you
> like/do not like this proposal, or have questions about it, this would be the
> time to speak up.
> >
> > I am absolutely good to go with whatever the WG decides.   I do believe
> that obsoleting 5277 makes specification and implementation simpler, with
> no meaningful loss of functionality.
> >
> > Eric
> >
> > Cheers.
> >
> > On Dec 2, 2016, at 12:43 PM, MehmetErsue
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi Eric, All,
> >
> > As I remember the charter discussion people were keen of having
> backwards compatibility because of deployed implementations.
> >
> > If you are in favor of keeping 5277 as standard and developing an additional
> independent notification mechanism please make its case.
> > Thanks,
> > Mehmet
> >
> > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit)
> <[email-masked]<mailto:[email-masked]>> wrote:
> > Hi Mehmet,
> > Hi Mahesh,
> > Hi Benoit,
> >
> 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>
> > •       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
> > From: Eric Voit, November 30, 2016 5:58 PM Minutes posted at:
> > •        As always, our DezignTM Team is a gathering of individuals providing
> informal input to NETCONF. We ask NETCONF WG to comment on our
> > WebEx
> Recording<https://cisco.webex.com/ciscosales/lsr.php?RCID=87cde245293c
> > 47dd8cff3772739f66c4>
> > password: bXeveFV5
> >
> > Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy,
> > Sharon Chisholm
> >
> >   *   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
> >   *   Must go to the WG, its chairs, and Benoit to confirm this
> > 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
> >   *   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.
> >   *   We need a way to test if the filters are doing what we expect they are
> doing. (Perhaps counters/captures on an active subscription?)
> >   *   Change source-vrf description to indicate that we should align with
> >   *   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
> >   *   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 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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 3 Dec 2016 12:24:49 +0100

I just note that reading email discussion is becoming increasingly
difficult since I often can't find where the statement is that is
being made. I do not want to start a discussion here. Perhaps some
people are willing to spent some time to see whether they can improve
their email client configuration - or they don't (but then I might not
read their email correctly).

Peronally, I believe quoted line prefixes style (aka Usenet quoting)
has the longest tradition and is likely the most unambiguous style
since it allows nesting.

/js

---

From: Randy Presuhn <[email-masked]>
Date: Sat, 3 Dec 2016 11:02:40 -0800

Hi -

On 12/3/2016 3:24 AM, Juergen Schoenwaelder wrote:
...
> has the longest tradition and is likely the most unambiguous style

Agreed.  In addition to that style preference, I'd also like
to see more selectively trimmed quotations, rather than each
message containing the entire thread of preceding messages.

Randy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sun, 4 Dec 2016 15:52:54 +0000

> From: Jonathan Hansford, December 3, 2016 5:18 AM
> 
> Are you proposing a specific style of quoting, or are any of those listed
> acceptable? The Wikipedia page doesn't identify what "proper quotations" are.
> 
> Jonathan
> 
> 

My style until now has been to reply to people using the style which I received.  I will endeavor to shift to text-only when cc'ing NETCONF. 

Eric

> > would look like with your proposal. Currently it says that 5277bis
> > will advertise "urn:ietf:params:netconf:capability:notification:1.0”
> > and "urn:ietf:params:netconf:capability:notification:1.1”. Clients can
> > then choose which capability they are capable of and want to support.
> > With the new proposal, are we dropping advertisement of
> > > Yes.  Anyone who wants to use existing 5277 would just leverage to
> > > the old
> > namespace.
> > >
> > 5277, what would be the implication of having two
> > <create-subscription>, in two different namespaces?
> > >
> > recommended RPC going forward is <establish-subscription>.  In this
> > way everything stays independent.  But a server could chose to support both
> 1.0
> > like/do not like this proposal, or have questions about it, this would
> > be the time to speak up.
> > >
> > that obsoleting 5277 makes specification and implementation simpler,
> > with no meaningful loss of functionality.
> > >
> > > Eric
> > >
> > > Cheers.
> > >
> > > I believe we need a discussion on this on the maillist and get the
> > > opinion of
> > all parties.
> > > additional
> > 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.”
> > >
> > be in independent namespaces. Not supporting 5277 <create
> > subscription> and a separate namespace / model will significantly
> > simplify the new specification.
> > >
> > certainly do this.  Independent capability sets can be advertised.
> > get your and the community’s feedback and buy-in before we modify any
> > of the documents in this direction.
> > >
> > 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
> > >
> > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar
> > > Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares
> > > Ambika Tripathy, Sharon Chisholm
> > >
> > 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.
> > Also we need a better name for 5277 filters. This name doesn’t expose
> > compatibility, we need a better name for 6241, and we need to define
> > the boundaries of filter solution. Andy has a strawman proposal.
> > “encoding not defined”, “Filter syntax not supported” or “filter
> > complexity not supportable by platform”.
> > “changes-only” flag for a periodic subscription. (Some support for
> > this, but more discussion is needed as the work is non-trivial.)
> > this entirely considering section 3.1? Or do we merge 3.1 into here?)
> > (Eric talk to Alex, likely ok)
> > 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.)
> > counters of object changes, of update messages)? (Both… Test and
> > normal operations need to be covered.. Match to filters working
> > operation question)
> > > Dampening:
> > >

---

From: t.petch <[email-masked]>
Date: Mon, 5 Dec 2016 10:06:54 +0000

----- Original Message -----
From: "Jonathan Hansford" <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>;
"'Eric Voit (evoit)'" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, December 03, 2016 10:17 AM

> Are you proposing a specific style of quoting, or are any of those
listed acceptable? The Wikipedia page doesn't identify what "proper
quotations" are.

For me, proper quotations are anything that I can readily see via my MUA
which enables me to distinguish what the sender of the e-mail has
written, as opposed to what was already there when the sender received
the e-mail to which they are responding.

In Eric's response to Mahesh, there is nothing, zilch, zero as in

"Yes.  Anyone who wants to use existing 5277 would just leverage to the
old namespace.

If the namespaces are truly different, and the server already supports
5277, what would be the implication of having two <create-subscription>,
in two different namespaces?

There would be no <create-subscription> in 1.1.   With 5277bis the
recommended RPC going forward is <establish-subscription>.  "

The original text and the new text are separated by a blank line as are,
when appropriate, the paragraphs of the original text and inserted text
making it hard work, sometimes impossible, to tell who is saying what.

The commonest (and so best) way is the use of one or more of > > > on
every line although once per paragraph is usable.  Other characters will
do as long as they display - I get an increasing level of open boxes
these days, especially in the minutes of WGs, which are a fancy Unicode
variant of a quote, double quote, dash, period and such like.

Anything that starts as Microsoft Word is likely to be unintelligible.

Tom Petch

> > would look like with your proposal. Currently it says that 5277bis
will
the old
> > 5277, what would be the implication of having two
<create-subscription>, in
> > recommended RPC going forward is <establish-subscription>.  In this
way
> > that obsoleting 5277 makes specification and implementation simpler,
with
opinion of
> > > If you are in favor please explain what kind of replacing (i.e.
compatibility
> > level) you would like to have.
additional
> > delete subscriptions without closing the client session, to modify
existing
> > be in independent namespaces. Not supporting 5277 <create
subscription>
> > certainly do this.  Independent capability sets can be advertised.
Backwards
> > > P.S.: Additional discussion on this is contained in minutes 2 to15
minutes of
> > the WebEx audio recording below.
> > >
approach
> > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar
Nilsen-Nygaard,
> > >      *   5277 already has enough changes to it (e.g., dataplane
has moved to
> > 6241 filtered notifications)
> > >
codes; not
> > >   *   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
> > >   *   For configured subscriptions, make receiver key ip address
and port. At
> > this point we don’t want VRF
> > >   *   start-time in the YANG model from startTime as we don’t have
to worry
> > about backwards compatible RPC.
complexity
> > “changes-only” flag for a periodic subscription. (Some support for
this, but
> > counters of object changes, of update messages)? (Both… Test and
normal
> > >   *   Dampen can mean lessen. We should choose Damp or Dampen
based
> > on usage therefore.

---

From: MehmetErsue <[email-masked]>
Date: Mon, 05 Dec 2016 12:44:38 +0000

It would be indeed nice if people would use quotations and show the mail
history in a readable fashion.
However there are so many mail clients around which use HTML and even don't
provide automatic quotation.

I sometimes edit HTML mails and add quotation manually to show to which
comment I'm responding.
I think it is difficult to force people to send only text-based mails or
use a particular mail client.

Mehmet

On Mon, Dec 5, 2016 at 11:10 AM t.petch <[email-masked]> wrote:

> > > Phone: +49 421 200 3587 <0421%202003587>         Campus Ring 1 |
> 28759 Bremen |
> Germany
> > > Fax:   +49 421 200 3103 <0421%202003103>         <
> http://www.jacobs-university.de/>
> > >
-- 
Cheers,
Mehmet

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Dec 2016 13:54:30 +0100 (CET)

> I sometimes edit HTML mails and add quotation manually to show to which

Same here.

... and sometimes I actually give up on some threads and don't bother
to reply.

> use a particular mail client.

Right, but hopefully it doesn't hurt to ask politely.  It doesn't make
much sense that people like yourself should have to manually fix other
people's poor formatting if it can be avoided in the cases where there
is a simple setting in the email client.

/martin