Re: [Xen-devel] [PATCH v4 4/4] docs: Introduce xenstore paths for guest network address information

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

> 
> > +#### ~/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