Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-pub-sub-requirements-08: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 16 May 2016 08:09:53 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-i2rs-pub-sub-requirements-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS points.

The comments below are from my initial ballot. I think you've probably
addressed most of them, but I am leaving them for reference:

- General: I support Stephen's DISCUSS

-2.2: What is the real scope of this work? Is it expected to supplant the
mentioned mechanisms?

- 2.3: "We need a new pub-sub
   technology"
The shepherd write up mentioned a goal to use existing technologies. Is
the point of this sentence to suggest that is not feasible?

- 4.1, 4th paragraph:
The MAY doesn't seem right--is this a statement of fact that the
subscriber may have to resubscribe, or a requirement of the form that the
service MAY force the subscriber to resubscribe? (Be careful with MAYs in
requirements language--they imply unexpected things. For example, several
requirements say a SUBSCRIBE MAY do something--do those imply that the
service MUST allow the subscriber to do it ?)

-- 4.2.2, third bullet: The previous section said dampening periods MUST
be supported.

- 4.2.1, third paragraph: This is a bit ambiguous. I think it means to
change the what subtrees the subscription applies to, but could be
interpreted to change the subtrees themselves.

- 4.2.6.4: Would a mechanism that allowed out-of-order delivery but gave
the subscriber a way to reconstruct the order fulfill this requirement?

Nits:
- The shepherd write up suggests this is standards track. The draft and
tracker both say informational. Please update the shepherd writ up.

-3, last paragraph: What's the difference between a "Push" and an
"Update"?

-4.1: A forward reference to the subscription QoS section would be
helpful.

-- Last paragraph, last sentence: Sentence doesn't parse.

- 4.2.8, third paragraph: I don't think that should be a 2119 MAY