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:stephen.farr...@cs.tcd.ie]
> Sent: Thursday, September 15, 2016 7:09 AM
> To: The IESG
> Cc: draft-ietf-nvo3-a...@ietf.org; Matthew Bocci; nvo3-cha...@ietf.org;
> matthew.bo...@alcatel-lucent.com; nvo3@ietf.org
> 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
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to