Hi Ben, Thanks for the comment. In-line....
> From: Ben Campbell, May 04, 2016 2:49 PM > ---------------------------------------------------------------------- > 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? When the subscription is established dynamically via an existing transport session (which is expected to be the dominant case) we have the same expectations for Privacy and integrity as would be provided via a "GET" instead of a "PUSH" over the same transport. We could have replicated all these requirements, but that was seen as unnecessary and likely less secure than adopting existing mechanisms. When the Subscriber and Receiver are different, then the transport connection will have credentials passed as part of the establishment. These credentials will be used as a Security Grooming Filter just like the above case so that pushed objects will be excluded from an Update Notification as per the permissions of the Receiver. (I.e., this is identical behavior to the above.) As several people have had questions about this, the new v07 will make this explicit in the Security section. > - 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. The question really was how heavy-weight should the mechanism be. Transports been considering are all encrypted. So there is already a level of trust between the peers. And a target can always pull down the connection if there are issues. In addition, multicast transports are viable for some future cases. We didn't want mechanisms which complicated this type of interaction, especially in a world where dumb IoT devices may be involved. > ---------------------------------------------------------------------- > 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? No. It is just showing that many specialized Push mechanism exist. This is not intended to supplant existing mechanisms, although perhaps it can help avoid future dedicated solutions. > - 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? Existing technologies cannot meet all the requirements specified. There are technology drafts progressing in NETCONF which can. > - 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 ?) Good point. Reworded in v07. > -- 4.2.2, third bullet: The previous section said dampening periods MUST be > supported. Yes, but dampening is never for periodic subscriptions. > - 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. Fixed > - 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? Yes, the timestamp within an update. But this requirement targets a specific object in a specific subscription. So there should be no issues. > Nits: > - The shepherd write up suggests this is standards track. The draft and > tracker > both say informational. Please update the shepherd writ up. Fixed > -3, last paragraph: What's the difference between a "Push" and an "Update"? Reworded > -4.1: A forward reference to the subscription QoS section would be helpful. Moved the requirement in question to 4.2.6. > -- Last paragraph, last sentence: Sentence doesn't parse. Fixed > > - 4.2.8, third paragraph: I don't think that should be a 2119 MAY Fixed Thanks again for the review! Eric _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
