[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 4/4] docs: Introduce xenstore paths for guest network address information
> -----Original Message----- > From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel- > bounces@xxxxxxxxxxxxx] On Behalf Of Paul Durrant > Sent: 17 November 2015 10:33 > To: Ian Jackson > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org); Ian Campbell; Jan Beulich; > Tim (Xen.org) > Subject: Re: [Xen-devel] [PATCH v4 4/4] docs: Introduce xenstore paths for > guest network address information > > > -----Original Message----- > > From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx] > > Sent: 16 November 2015 17:39 > > To: Paul Durrant > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Ian Campbell; Jan Beulich; Keir > (Xen.org); > > Tim (Xen.org) > > Subject: Re: [PATCH v4 4/4] docs: Introduce xenstore paths for guest > > network address information > > > > Paul Durrant writes ("[PATCH v4 4/4] docs: Introduce xenstore paths for > > guest network address information"): > > > +* MAC_ADDRESS -- 6 integers, in hexadecimal form, separated by ':', > > > + specifying an ethernet MAC address. > > > +* IPV4_ADDRESS -- 4 integers, in decimal form, separated by '.', > > > + specifying an IP version 4 address. > > > +* IPV6_ADDRESS -- Up to 8 integers, in hexadecimal form, separated > > > + by ':', specifying an IP version 6 address. > > > + (Zero compression of addresses, using '::' notation, > > > + is allowed but not required). > > > > Sorry for not mentioning this before, but you should probably > > provide normative cross-references. > > I'm sorry, I don't understand what you mean there. Do you mean references > to relevant RFCs? > Since I'm going to re-post the series any, I'll assume you do. Paul > > > > > +#### ~/attr/vif/$DEVID/name = STRING [w] > > > + > > > +A domain may write its internal 'friendly' name for a network device > > > +using this path. A toolstack or UI may use this for display purposes > > > +but, since it is entirely under the control of the guest, no > > > +particular meaning should be inferred from the name. > > > > Permitted character set ? Encoding ? > > UTF-8 I guess. I'll add that. > > > > > > +#### ~/attr/vif/$DEVID/mac/$INDEX = MAC_ADDRESS [w] > > > + > > > +The guest may override the MAC address written in the vif backend by > > > +the toolstack and hence the guest may write one of the paths of > > > +this form with the unicast MAC address it is currently using. Other > > > +paths may be used by the guest to write multicast addresses which > > > +are in operation. > > > > "Paths of this form" vs "other paths" is confusing. If there is a > > distinction between $INDEX==0 and others, you need to say so - but I > > think you probably don't intend that. > > > > Ok, I'll re-word. > > > > +The values written to these paths are under guest control and, as > > > +such, they are primarily for display purposes and should not be used > > > +for packet filtering or routing purposes. > > > > Not using them for filtering or routing is not just for security > > reasons but also to avoid hideous layer violation doom. So I would > > delete the whole section about `under guest control' (which is > > obvious) and make it two sentences. I would also say `must not' > > rather than `should not'. > > > > A similar comment applies to the IPv4 and IPv6 addresses. > > > > Ok. > > Paul > > > Thanks, > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |