[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
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. > +#### ~/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 ? > +#### ~/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. > +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. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |