On 17/05/16 19:32, Eric Voit (evoit) wrote: > Hi Stephen, > > And some thoughts on your comments too...
Those're all good. Cheers, S > >> 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
