Alvaro Retana has entered the following ballot position for draft-ietf-i2nsf-framework-08: 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-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As Alissa mentioned in her Ballot, the long-term archival value of this draft is not clear to me either. There are some places where it is not clear what the intent of the document is wrt the references; are they examples, recommendations or do they represent a stronger pillar in the i2nsf work. Just to highlight one of them: I’m not sure what is the intent with rfc5575 (Dissemination of Flow Specification Rules) is in 9.2. I’m confused because the reference is Normative, but the text sounds as if FlowSpec was an example: 9.2. Registration Categories Developers can register their NSFs using Packet Content Match categories. The IDR (Inter-Domain Routing) Flow Specification [RFC5575] has specified 12 different packet header matching types. More packet content matching types have been proposed in the IDR WG. I2NSF should re-use the packet matching types being specified as much as possible. More matching types might be added for Flow-based NSFS. Tables 1-4 below list the applicable packet content categories that can be potentially used as packet matching types by Flow-based NSFs: Also, the tables present categories that go beyond what FlowSpec covers. Where does the other information come from? Is there work that can reused there? What about IPFIX (that seems more appropriate than FlowSpec)? To be clear, I like very much the fact that the text advocates for reuse. It is just not clear what the expectation is with regards to rfc5575 or other proposed work in the idr WG. Is the expectation that the matching types be used in i2nsf systems? What about other related extensions that may be developed in idr, are there specific requirements or considerations that the idr WG should take into account? From the archive, it looks like idr hasn’t reviewed (or been notified of) this document… Note that if the mention of rfc5575 is just an example, then I think some of the text could be made clearer (and the reference should be Informative). _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
