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? (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. ---------------------------------------------------------------------- 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
