[I2nsf] Murray Kucherawy's No Objection on draft-ietf-i2nsf-registration-interface-dm-25: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-i2nsf-registration-interface-dm-25: No Objection 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/ -- COMMENT: -- The shepherd writeup seems to have skipped answering part of the first question: Why is this the right document status? I'm also confused by the answer to question 18. [copied from my otherwise-resolved DISCUSS] It also makes me wonder if this shouldn't be updating some other document if you're extending required behavior of an I2NSF component that was defined someplace else. I looked around for a document defining "security controller" and couldn't find an obvious one, so I'm at a loss for what to suggest. ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
[I2nsf] Murray Kucherawy's No Objection on draft-ietf-i2nsf-consumer-facing-interface-dm-28: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-i2nsf-consumer-facing-interface-dm-28: No Objection 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/ -- COMMENT: -- I support Lars' DISCUSS about normative references. I don't understand the shepherd writeup answer to question #18. This document doesn't create any new registries. I'm no expert, but shouldn't the YANG Module itself include (as a comment) the BCP 14 boilerplate? I ask because the only MUST is in the module, and the only SHOULD is in Security Considerations, so in one sense the BCP 14 reference could go away, and in another, it's missing. ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
[I2nsf] Murray Kucherawy's Discuss on draft-ietf-i2nsf-registration-interface-dm-24: (with DISCUSS and COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-i2nsf-registration-interface-dm-24: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/ -- DISCUSS: -- I'd like to talk about the two SHOULDs in Section 1, the Introduction. Normative guidance is normally in the meat of the document where the protocol material is being presented. Here, the Introduction says: * "the security controller SHOULD be able to request the DMS for NSFs that have the required security capabilities" * "describes the operations that SHOULD be performed by the Security Controller and the DMS via the Registration Interface using the defined model" I think you need a (probably small) section after Section 2 that lays out these normative requirements for controller behavior if that's what the intent is here. If the intent was just a plain old "should" and not a BCP 14-style SHOULD, then this is a pretty easy fix. But the language you're using here appears to be asserting that controllers are expected to behave a particular way. It also makes me wonder if this shouldn't be updating some other document if you're extending required behavior of an I2NSF component that was defined someplace else. I looked around for a document defining "security controller" and couldn't find an obvious one, so I'm at a loss for what to suggest. -- COMMENT: -- The shepherd writeup seems to have skipped answering part of the first question: Why is this the right document status? I'm also confused by the answer to question 18. ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
[I2nsf] Murray Kucherawy's No Objection on draft-ietf-i2nsf-nsf-monitoring-data-model-15: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-i2nsf-nsf-monitoring-data-model-15: No Objection 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/ -- COMMENT: -- The shepherd writeup indicates that there is an IPR declaration, but does not characterize the discussion about it that occurred (if any). Please update the writeup to state, or at least let the IESG know by replying to this, what the outcome of this was. I suggest breaking Section 11 into subsections, one for each IANA action being requested. ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
[I2nsf] Murray Kucherawy's No Objection on draft-ietf-i2nsf-nsf-facing-interface-dm-21: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-i2nsf-nsf-facing-interface-dm-21: No Objection 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/ -- COMMENT: -- In Section 3, there's this: A default action is used to execute I2NSF policy rule when no rule matches a packet. The default action is defined as pass, drop, reject, rate-limit, and mirror. The default action can be extended according to specific vendor action features. The default action is described in detail in [I-D.ietf-i2nsf-capability-data-model]. The second sentence is confusing. It appears to say the default is all five of those, when I think it means to say is that the default is one of those. Anywhere "http" or "https" appear as words in prose, but not as part of a URL or part of the YANG module, I believe they should be in all caps since they're acronyms. See, for instance, the numerous instances of this in Section 5. A very minor point: I suggest Section 6 be broken into two subsections, one per major action being requested. ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
[I2nsf] Murray Kucherawy's No Objection on draft-ietf-i2nsf-capability-data-model-12: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-i2nsf-capability-data-model-12: No Objection 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-i2nsf-capability-data-model/ -- COMMENT: -- I support Eric's DISCUSS position about the information model vs. data model publications. The smashed-together list of references at the top of Section 5 could use some formatting. I tripped over several of the editorial points Barry found. Here's one more. In Section 3: o If a network administrator wants to block malicious users for IPv6 traffic, he sends a security policy rule to block the users to the Network Operator Management System using the I2NSF User (i.e., web application). Block malicious users "for" IPv6 traffic? I don't understand. Perhaps "block IPv6 traffic from malicious users"? ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
