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

From: Dan Frost <[email-masked]>
Date: Mon, 25 Apr 2016 17:04:19 +0100

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.

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.

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.

Minor Issues:

1. The requirements in this document ought to be numbered for ease of
reference.

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.

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?

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

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.

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.

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?

8. Section 4.2.5, third paragraph:
Can you spell out in the document exactly what "Versioning" means here?

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?

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?

Nits:

Section 2.2, first paragraph:
- s/Switches and Routers/switches and routers/
- s/past subscriptions includes/past subscription mechanisms includes/

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

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/
- s/different that/different than that/

Section 4, first paragraph:
- s/morphed/adapted/

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

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

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

Cheers,
-d

---

From: Alia Atlas <[email-masked]>
Date: Fri, 29 Apr 2016 17:37:31 -0400

Hi Dan,

Thank you very much for your review.  This document is intended to be
Informational; the data-tracker needed to be updated.
I do have a few comments in-line.

Eric, Alex, Gonzalez & Sue, please address these comments ASAP as you feel
is appropriate.
I do think that some clarifications will help.
I do think that version 06 is quite improved in sections 1 & 2.

> the ADs and chairs agree on a consistent policy.

[Alia] Good catch.  Agreement is that they are informational.

> mechanisms to determine or restrict the bandwidth cost of a proposed or

[Alia] There are a number of different potential transports and encodings;
these tend
to be dictated by the ecosystem in which the deployment is desired.  These
I2RS requirements are targeted initially for YANG with NetConf and RestConf.
An expectation is that the mechanisms such as subscription filters,
bundling,
and dampening, can be reused for other transports and encodings.

> is whether it has received any review by interested/affected parties

[Alia] A proposed solution is being discussed in NetConf.

> explicitly signaled and checked by both parties during negotiation.

[Alia] While the I2RS architecture and
draft-ietf-i2rs-security-environment-reqs-01
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/>

and draft-ietf-i2rs-protocol-security-requirements-03
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/>
all cover lots of details
about this, it would be a good idea to touch on it this as well in the
Security Requirements
with a useful reference.

> Can the authors not provide a summary of options and some definite

[Alia] These are the requirements on a pub/sub service.  Of course,
different
transports and encodings may have slight nuances - but I2RS is specifically
reusing NetConf and RestConf and YANG, so that gives the initial set for
at least subscribing.

Thanks,
Alia