Hi, thanks for the response. Comments in line, with sections removed
that do not seem to need further discussion:
On 4 May 2016, at 18:24, Eric Voit (evoit) wrote:
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.
Where do those requirements live now? I recall this draft mentioning
that support for multiple transports is required, but I don't recall
seeing anything about the required transport properties. (It's entirely
possible I missed it, or just forgot.)
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.
That will likely resolve my concern, but there's not enough detail here
to judge. I will watch for the update.
- 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.
I think you are talking about solution, not requirements. If the
solution is already known, what is the purpose of publishing the
requirements?
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.
I think my response to this will depend on the details you mention are
coming in 07.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
[...]
-- 4.2.2, third bullet: The previous section said dampening periods
MUST be
supported.
Yes, but dampening is never for periodic subscriptions.
The third bullet is about on-change updates, not periodic publication.
4.2.1 says the service MUST support dampening for on-change updates.
[...]
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
