Hi Stephen, And some thoughts on your comments too...
> From: Eric Voit, May 17, 2016 1:46 PM > > 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.) Yes, we have attempted to aggregate requirements from other sources. At the beginning there were discussions across I2RS, NETCONF, NETMOD WGs and Ops and Routing ADs to arrange for general applicability. > > - 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. Thanks, you make good points... (1) Changing text to explicitly show that these are hints. (2) Changing text to SHOULD. (3) If the subscriber doesn't have privilege, then the target YANG path would not exist (or be found). Which would be a normal error, not a constrained resource error. And this requirement was aimed at resource constraints. Which means the text needs to be tweaked. To meet these 3 points, how about the text: "In cases where a Subscription Request cannot be fulfilled due to insufficient platform resources, the Subscription Service SHOULD include within its decline hints on criteria that would have been acceptable when the Subscription Request was made." > > - 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? MUST use. Will change text. > > - 4.2.8: when you say fetch... by whom? Is there an implicit > > requirement in the title of the subsection? What is implicit is that some mechanism to meet operational requirements of this section should exist. The entity doing the fetching could be an NMS. Thanks, Eric > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
