Stephen Farrell has entered the following ballot position for draft-ietf-nvo3-arch-07: 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-nvo3-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - (This comment is just a generic remark, offered in the hope that future IPR declarations might be more tightly targeted, so there's no need to respond to it.) It's not clear to me how an architecture with 2 RAND-with-fee IPR declarations amounts to a win here. Well, unless the IPR is rubbish maybe - I did take a look at those and do have an opinion, but I'll leave you to guess what that is:-) But the IPR declarations seem like they were timely, and the last call did mention them, so I guess it is what it is. Generally though, I think it'd be way better if IPR declarations were attached to specific protocol documents that the IPR holders consider relevant and not to architecture documents or similar. I can understand that making an IPR declaration on a document like this might be seen as getting the declaration out earlier (a good thing), but one has to wonder how anything here represents a credible invention. If that's the case I'd note that IPR declarations can be made that don't point at an Internet-draft which might be a better way to provide earlier notification to a WG. And declarations can be updated later to be associated with specific drafts if/when that's needed. - Generally this was pretty well written, thanks. - abstract/intro: "work with other components with no changes to other components" isn't great, suggest re-wording. - 4.2: ToR could do with an expansion on 1st use - 4.2.1: TS - I assume that's "tenant system" (from 7635) but you should say as it's used a good bit (and 7635 also defines "tenant separation" making TS potentially ambiguous). Mostly, uses of TS seem clear from context, but I think it'd be good to fix this and to check over where TS is used in this draft as there could be some subtlety there, e.g. whether or not a TSI is part of a TS or not (and is somehow architecturally "beside" a TS) could affect some later protocol work. - section 16: I think it might be worth noting here that meta-data and operational data could be unexpectedly sensitive, for example performance statistics could be used to infer what's being done in a VM or VN. So in addition to encrypting data in transit or storage, one might also want to consider minimising the types of data that NVEs/NVAs collect. That could have an impact on protocols defined later so may well be worth noting here too. If you do add text on that you may also want to recognise the tension between such data minimisation and the operational need to detect misbehaviours or errors happening within VNs. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
