Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 4 May 2016 23:24:51 +0000

Hi Dan,

Thanks for the excellent comments.   In-line below are what has been done for each of these...

> From: Dan Frost, April 25, 2016 12:04 PM
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as they
> pass through IETF last call and IESG review, and sometimes on special request.
> The purpose of the review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion or by
> updating the draft.
> 
> Document: draft-ietf-i2rs-pub-sub-requirements-06
> Reviewer: Dan Frost
> Review Date: 2016-04-25
> IETF LC End Date: 2016-04-29
> Intended Status: Informational (?)
> 
> Summary:
> 
> I have significant concerns about this document and recommend that the
> Routing ADs discuss these issues further with the authors.
> 
> Comments:
> 
> Overall this is a clear and consistent requirements document that addresses an
> important real-world problem domain, and is nearly ready for publication.
> However, because this work may lead to significant changes in the mechanics of
> network management and control, some extra care in the review stage is
> warranted.  I've marked some issues as major to indicate that they may deserve
> extra consideration by the ADs and/or the wider Internet community.
> 
> 
> Major Issues:
> 
> 1. There seems to be some confusion as to the intended status of the document.
> The draft itself lists its intended status as Informational, which is usually
> appropriate for a requirements document.  On the other hand, the draft was
> submitted to the IESG with an Intended Status of Proposed Standard.
> Furthermore, a quick check of other I2RS WG requirements docs shows them
> split between Informational and Proposed Standard, so the confusion may
> extend beyond this draft.  I'd suggest the ADs and chairs agree on a consistent
> policy.

Fixed 

> 2. The document concerns requirements for a publish/subscribe interface to,
> among other things, real-time operational data.  The text in Section
> 2.3 indicates an awareness of the need to support potentially large numbers of
> subscribers and high volumes of data.  However, the document doesn't seem to
> discuss the global network impact of continuously pushing a lot of data to many
> subscribers.
>
> As the introduction of such a push system could lead to a qualitative shift in the
> total volume of management/control traffic, it seems important to begin
> addressing this issue at the requirements stage.
>
> A possible resolution would be to add a brief section on network impact under
> large-scale conditions, and/or a set of requirements for minimizing this impact.
> Some of the listed requirements are germane to this, e.g. subscription filters.
> bundling, and dampening.  Issues that are not addressed include support for
> encoding formats that are efficient for high-volume transport and processing
> (XML and JSON are usually considered not to be); appropriate selection of
> transport protocols and features according to scale/use-case; and support for
> mechanisms to determine or restrict the bandwidth cost of a proposed or
> ongoing subscription.

Good point.  We do have some relevant requirements as there are mechanisms to:
- Allow/deny/negotiate subscriptions so as not to overwhelm resources.  This could include negotiation of the encoding and filters. See Section 4.2.2
- Notify subscribers that push updates are being suspended/resumed

But there could be more.  For example, there should be the ability of prioritize some subscriptions over others for de-queuing towards recipients
Therefore the new draft version '07' adds a Relative Prioritization section 4.2.6.8 and requirements to ensure limited bandwidth environments are addressed.

> 3. This work is being carried out in the I2RS WG, but the first sentence of Section
> 2.2 states that this document is intended to cover requirements beyond I2RS.  A
> general question for the editors/chairs/ADs is whether it has received any review
> by interested/affected parties outside I2RS?
> 
> 4. The Security Requirements make no mention of data integrity or
> confidentiality.  This is a potentially serious omission in today's network
> environment.  I would expect at the least that subscribers have the ability to
> request a secure (authenticated, integrity-verified,
> confidential) session, that publishers likewise have the ability to refuse non-
> secure sessions, and that the security status of a session is explicitly signaled and
> checked by both parties during negotiation.

With subscriptions signaled in-band, any pushed updates will rely on the underlying transport layer protocols to ensure integrity and confidentiality.  This provides the same level of security as a traditional "GET".  

> 
> Minor Issues:
> 
> 1. The requirements in this document ought to be numbered for ease of
> reference.

Hoping to avoid this :-)
 
> 2. Section 3:
> As this is a requirements doc, the RFC 2119 language paragraph could use a
> clarification sentence along the lines of the one in Section 1.1 of RFC 5654.

Added 
 
> 3. Section 3:
> It's not obvious to me from the text in this section what the distinction and
> intended relationship is between Receivers and Subscribers.  Perhaps this can be
> clarified with an example?  Also the statement "In general, the Receiver and
> Subscriber will be the same entity" doesn't sound right -- maybe you meant that
> in general they can be different, but usually they will be the same?

That is what is meant.
 
> 4. Section 3, last sentence:
> What is the difference between the terms "previous Push" and "last Update"
> used in this sentence?

Agree this was confusing. In fact it included a requirement in the definition.  Extracted this text in the -07 version, and added a reworded requirement to section 4.2.7.

> 5. Section 4.2.3, last paragraph:
> This paragraph would be more useful if it explained what a persistence/replay
> capability was and how it might work.

Updated text
 
> 6. Can a definition or reference be provided for the term "object property" as
> used in Sections 3 and 4.2.7?  This terminology seems slightly different from that
> used in RFC 6020.

I can see where people might get confused.   I tweaked the text to better match what can be seen with RFC6241 filtering.
 
> 7. Section 4.2.4:
> What is the purpose of stating that a subscription service should support
> "different" transports and encodings?  This sounds too vague to be useful.
> Choice of transport and encoding are of great practical importance, but the
> document has almost nothing to say on these topics.
> Can the authors not provide a summary of options and some definite guidance
> here?

This is tough.  There are proposals for transports of NETCONF, RESTCONF, HTTP, and HTTP2 in technology drafts.   Other people have suggested COAP and IPFIX.  Some people want non-IETF transports like gRPC.   We really don't want to take a position.
 
> 8. Section 4.2.5, third paragraph:
> Can you spell out in the document exactly what "Versioning" means here?

Updated
 
> 9. When the underlying transport provides some form of security, should there
> not be a requirement for alignment between transport security and pub/sub
> protocol security?  Can, for example, TLS certificate validation fulfil the pub/sub
> authentication requirement?

These requirements explore the security requirements for control plane messaging, anticipating that the data plane will be locked down as would a traditional "GET" for the same information.  This is why in the Security requirements talk about filtering based on whatever mechanisms would in place for a "GET" using that specific transport.  I.e., we are attempting equivalence for "GET" rather than new incremental mechanisms with perhaps different behavior.

> 10. An important use-case for such a pub/sub update service is a subscriber that
> wants to maintain an up-to-date local copy of a datastore residing on the
> publisher.  This requires the ability to correlate the version of the datastore
> obtained via an out-of-band full download with the version reflected by each
> published update.  Do the authors intend to allow for this case, and have they
> considered the associated requirements?

Yes.   In summary, you can get deltas via on-change.  And when you want to ensure you haven't lost something, you can do a GET against any objects where the remote datastore houses the primary copy.
 
> 
> Nits:
> 
> Section 2.2, first paragraph:
> - s/Switches and Routers/switches and routers/
> - s/past subscriptions includes/past subscription mechanisms includes/

Fixed
 
> Section 2.2, last paragraph:
> - s/NETCONF should the/NETCONF should be the/
> - s/support Multicast and Broadcast/support for multicast and broadcast/

Fixed
 
> Section 3, 8th paragraph:
> - s/referred in/referred to in/
> Section 3, 9th paragraph:
> - s/which have been made/that have been made/ Section 3, last paragraph:
> - s/propert(ies)/properties/

Fixed

> - s/different that/different than that/

Couldn't find that one
 
> Section 4, first paragraph:
> - s/morphed/adapted/

fixed
 
> Section 4.1, last paragraph:
> - s/lease a Subscription/lease of a Subscription/

Fixed

> Section 4.2.1, second and third paragraphs:
> These two requirements seem to make more sense if "one or more" is replaced
> by "multiple".

Fixed

> Section 4.2.8, third paragraph:
> - s/us a failure/is a failure/

Fixed

Eric

> Cheers,
> -d

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 May 2016 06:03:47 -0400

Dan: 

Regarding your major comments: 

Comment on #1  - The ADs agreed on informational after WG LC did standards.
It is fixed to informational now. 
Comment on #2 -  Has Eric's comment addressed your questions? 
Comment on #3 -  NETCONF has adopted push mechanism.  What other parties are
you concerned about? 
Comment on #4 - Please see the security requirements for the I2RS protocol: 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme
nts
https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/

These documents provide requirement for data integrity,  confidentiality,
protection against replay attacks, and DDoS. 

Do you feel you major comments have been addressed? 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, May 04, 2016 7:25 PM
To: Dan Frost
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06

Hi Dan,

Thanks for the excellent comments.   In-line below are what has been done
for each of these...

> I have been selected as the Routing Directorate reviewer for this 
> draft. The Routing Directorate seeks to review all routing or 
> routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request.
> The purpose of the review is to provide assistance to the Routing ADs. 
> For more information about the Routing Directorate, please see 
> Although these comments are primarily for the use of the Routing ADs, 
> it would be helpful if you could consider them along with any other 
> IETF Last Call comments that you receive, and strive to resolve them 
> through discussion or by updating the draft.
> 
> Overall this is a clear and consistent requirements document that 
> addresses an important real-world problem domain, and is nearly ready for
publication.
> However, because this work may lead to significant changes in the 
> mechanics of network management and control, some extra care in the 
> review stage is warranted.  I've marked some issues as major to 
> indicate that they may deserve extra consideration by the ADs and/or the
wider Internet community.
> The draft itself lists its intended status as Informational, which is 
> usually appropriate for a requirements document.  On the other hand, 
> the draft was submitted to the IESG with an Intended Status of Proposed
Standard.
> Furthermore, a quick check of other I2RS WG requirements docs shows 
> them split between Informational and Proposed Standard, so the 
> confusion may extend beyond this draft.  I'd suggest the ADs and 
> chairs agree on a consistent policy.

Fixed 

> 2. The document concerns requirements for a publish/subscribe 
> interface to, among other things, real-time operational data.  The 
> text in Section
> 2.3 indicates an awareness of the need to support potentially large 
> numbers of subscribers and high volumes of data.  However, the 
> document doesn't seem to discuss the global network impact of 
> continuously pushing a lot of data to many subscribers.
>
> As the introduction of such a push system could lead to a qualitative 
> shift in the total volume of management/control traffic, it seems 
> important to begin addressing this issue at the requirements stage.
>
> A possible resolution would be to add a brief section on network 
> impact under large-scale conditions, and/or a set of requirements for
minimizing this impact.
> bundling, and dampening.  Issues that are not addressed include 
> support for encoding formats that are efficient for high-volume 
> transport and processing (XML and JSON are usually considered not to 
> be); appropriate selection of transport protocols and features 
> according to scale/use-case; and support for mechanisms to determine 
> or restrict the bandwidth cost of a proposed or ongoing subscription.

Good point.  We do have some relevant requirements as there are mechanisms
to:
- Allow/deny/negotiate subscriptions so as not to overwhelm resources.  This
could include negotiation of the encoding and filters. See Section 4.2.2
- Notify subscribers that push updates are being suspended/resumed

But there could be more.  For example, there should be the ability of
prioritize some subscriptions over others for de-queuing towards recipients
Therefore the new draft version '07' adds a Relative Prioritization section
4.2.6.8 and requirements to ensure limited bandwidth environments are
addressed.

> 2.2 states that this document is intended to cover requirements beyond 
> I2RS.  A general question for the editors/chairs/ADs is whether it has 
> received any review by interested/affected parties outside I2RS?
> 
> confidentiality.  This is a potentially serious omission in today's 
> network environment.  I would expect at the least that subscribers 
> have the ability to request a secure (authenticated, 
> integrity-verified,
> confidential) session, that publishers likewise have the ability to 
> refuse non- secure sessions, and that the security status of a session 
> is explicitly signaled and checked by both parties during negotiation.

With subscriptions signaled in-band, any pushed updates will rely on the
underlying transport layer protocols to ensure integrity and
confidentiality.  This provides the same level of security as a traditional
"GET".  

Hoping to avoid this :-)
 
> 2. Section 3:
> As this is a requirements doc, the RFC 2119 language paragraph could 
> use a clarification sentence along the lines of the one in Section 1.1 of
RFC 5654.

Added 
 
> 3. Section 3:
> It's not obvious to me from the text in this section what the 
> distinction and intended relationship is between Receivers and 
> Subscribers.  Perhaps this can be clarified with an example?  Also the 
> statement "In general, the Receiver and Subscriber will be the same 
> entity" doesn't sound right -- maybe you meant that in general they can be
different, but usually they will be the same?

That is what is meant.
 
> What is the difference between the terms "previous Push" and "last Update"

Agree this was confusing. In fact it included a requirement in the
definition.  Extracted this text in the -07 version, and added a reworded
requirement to section 4.2.7.

> This paragraph would be more useful if it explained what a 
> persistence/replay capability was and how it might work.

Updated text
 
> 6. Can a definition or reference be provided for the term "object 
> property" as used in Sections 3 and 4.2.7?  This terminology seems 
> slightly different from that used in RFC 6020.

I can see where people might get confused.   I tweaked the text to better
match what can be seen with RFC6241 filtering.
 
> 7. Section 4.2.4:
> What is the purpose of stating that a subscription service should 
> support "different" transports and encodings?  This sounds too vague to be
useful.
> Choice of transport and encoding are of great practical importance, 
> but the document has almost nothing to say on these topics.
> Can the authors not provide a summary of options and some definite 
> guidance here?

This is tough.  There are proposals for transports of NETCONF, RESTCONF,
HTTP, and HTTP2 in technology drafts.   Other people have suggested COAP and
IPFIX.  Some people want non-IETF transports like gRPC.   We really don't
want to take a position.

Updated
 
> 9. When the underlying transport provides some form of security, 
> should there not be a requirement for alignment between transport 
> security and pub/sub protocol security?  Can, for example, TLS 
> certificate validation fulfil the pub/sub authentication requirement?

These requirements explore the security requirements for control plane
messaging, anticipating that the data plane will be locked down as would a
traditional "GET" for the same information.  This is why in the Security
requirements talk about filtering based on whatever mechanisms would in
place for a "GET" using that specific transport.  I.e., we are attempting
equivalence for "GET" rather than new incremental mechanisms with perhaps
different behavior.

> 10. An important use-case for such a pub/sub update service is a 
> subscriber that wants to maintain an up-to-date local copy of a 
> datastore residing on the publisher.  This requires the ability to 
> correlate the version of the datastore obtained via an out-of-band 
> full download with the version reflected by each published update.  Do 
> the authors intend to allow for this case, and have they considered the
associated requirements?

Yes.   In summary, you can get deltas via on-change.  And when you want to
ensure you haven't lost something, you can do a GET against any objects
where the remote datastore houses the primary copy.

Fixed

Fixed

Fixed

Couldn't find that one

fixed

Fixed

> These two requirements seem to make more sense if "one or more" is 
> replaced by "multiple".

Fixed

Fixed

Eric

> -d

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs