Sue Hares
(shepherd)
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Eric Voit
(evoit)
Sent: Wednesday, May 04, 2016 7:25 PM
To: Ben Campbell; The IESG
Cc: [email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [i2rs] Ben Campbell's Discuss on
draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)
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?
[eric's comment:
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.
End of eric's comment]
Sue: The transport provides for privacy, integrity protection. Most
configuration in network boxes would need privacy.
- 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.
Sue: If the receiver accepts a secure transport set-up from the
server, can
you provide the reason why this is not an "opt-in" once it receives
the
connection from the I2RS agent?
----------------------------------------------------------------------
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
<mailto:[email protected]> [email protected]
<https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs
