Hi Stephen, > Stephen Farrell, May 03, 2016 8:23 PM > > Stephen Farrell 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 what I hope are two very easily sorted things that I'd like to chat > about: > > (1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why would we ever have > a > pub/sub service whose subscribers can pretend to be the service?
I am not sure I understand. The Subscription Service is located on the Publisher. Having the Publisher and Subscriber mutually authenticate each other makes sense. If you mean something else and you are wondering if whether a Subscriber can also be a Publisher for the information it receives, yes it can. Having a collector/controller as a middle-man is a very valid implementation. But there is nothing which binds such independent subscriptions together. > (2) Don't you need a statement somewhere that commensurate security needs > to be provided for pushed notifications as was used for the original > subscription? > That might be a little hard to phrase correctly but I hope we agree that the > notifications ought not be significantly less secure than the subscription. We had some interactions with Ben Campbell on this topic. In general we are doing our best to decouple the subscription establishment and maintenance from the underlying transport options. This is because there are implementations (for example wholly within an MSDC) which don't require payload encryption. Still most implementations should have transport encryption. So after several interactions with Ben, the text leading off Section 4.2.5 now reads: Some uses of this Subscription Service will push privacy-sensitive updates and metadata. Good deployment practices will bind this generated information within secure, encrypted transport layer mechanisms. For example if NETCONF is used as transport, then [RFC5539] would be a valid option to secure the transported information. The Subscription Service can also be used with emerging deployment contexts as well. As an example, deployments based on [i2rs-usecase] can apply these requirements in conjunction with those documented within [i2rs-protocol-security] to secure ephemeral state information being pushed from a Network Element. Does this hit your objective? Eric > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - I wondered if this was maybe of interest to more than just i2rs, and if so, > whether any effort had been made to try figure out if these requirements work > for folks who don't care about i2rs? It'd seem a shame to work on this but > stop > one step short of being appropriately general. > (But you probably already checked that I guess.) > > - 4.2.2, last para: The MUST here seems like it may be quite onerous, in > general. > Did someone think all of that through? For example, what if the reason for > declining is that the Subscriber doesn't have sufficient privilege? > Saying what privilege is needed would be a breach of least-privilege. > Transient > errors may also make this very hard to do well. I'd suggest s/MUST/MAY/ and to > also turn the information returned into a hint and not a promise. > > - 4.2.5, para 1: saying there "MUST be mutual authentication" is odd - the > usual > terms would be "MUST implement" or "MUST use" which of those does "MUST > be" > mean? > > - 4.2.8: when you say fetch... by whom? Is there an implicit requirement in > the > title of the subsection? > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
