Ben Campbell has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-06: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple of points I would like to discuss. Hopefully they can be resolved easily: Are there really no requirements for privacy or integrity protection? Is there an expectation that this mechanism would ever carry privacy sensitive or otherwise sensitive information? - 4.2.5, 2nd to last paragraph: I am surprised to find that, when the receiver is not the subscriber, that the receiver is expected to opt-out. It seems like some form of opt-in or affirmative consent would be needed here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
