Stephen, > - Generally this was pretty well written, thanks.
Thanks for the careful review. > - 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 Editorial improvements made for both of the above. > - 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. Checked, expanded some uses of TS. It's always Tenant System, and the acronym usage is generally clear. > - 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. I believe that's generally the case for operational data, e.g., performance stats. If you or the OPS ADs have a reference to suggest, I'd be happy to cite it on this concern, but would prefer not to add a from-scratch discussion, as covering this: > 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. is likely to entail a discussion of trust models between a network operator (landlord) and tenants using that network infrastructure. I suspect that discussion will be neither simple nor short, and moreover, it has much broader IETF applicability than just NVO3. Thanks, --David > -----Original Message----- > From: Stephen Farrell [mailto:[email protected]] > Sent: Thursday, September 15, 2016 7:09 AM > To: The IESG > Cc: [email protected]; Matthew Bocci; [email protected]; > [email protected]; [email protected] > Subject: Stephen Farrell's No Objection on draft-ietf-nvo3-arch-07: (with > COMMENT) > > 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
