[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.