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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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