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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


- (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

Reply via email to