[dhcwg] Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt

[Henrik Levkowetz <[e-mail]>]

Thank you, Thomas.

	Comments below.  /Henrik

On Tuesday, 25 Nov 2003, Thomas wrote:

> Here is my review of this document. Note that I'm crossposting because
> some of my comments are more DHCP-ish, while others are MIP4-ish.
> 
> Thomas
> 
> >    The Mobility Agent Information field shall NOT be terminated with a
> >    255 sub-option.  The length N of the DHCP Mobility Agent Information
> 
> Why is this here? There is presumably no "255 sub-option" defined,
> since this document definess all the suboptions that are applicable to
> this option. Or am I just confused?

I doubt the latter :-)  I included this here as there exists an
255 end option (not sub-option) which seems to have prompted the
same clarifying (or confusing!) text in some other documents defining
suboptions. It doesn't seem needed, but maybe there is history
lurking here?

> 
> >    tuples.  Since at least one sub-option must be defined, the minimum
> >    Mobility Agent Information length is two (2).  The length N of the
> 
> s/must be defined/must be included in the option/

Yes.

> >    value field.  A sub-option length may be zero.  The sub-options need
> >    not appear in sub-option code order.
> 
> Would it be appropriate to go further and say:
> 
>       The sub-options need not appear in any particular order.

Yes. And (as urged by other people on the dhcwg list) I'll change the
zero length part to require a flag instead of using the option presence
itself as a flag.

> >    The Network Access Identifier sub-option of the Mobility Agent
> >    Information Option MAY be used by the DHCP client to provide
> >    identifying information to the DHCP server, as part of the
> >    DHCPDISCOVER message.  The server may then use this information in
> >    selecting mobility agent announcement parameters for the client.
> 
> Can this sub-option only be provide in the DISCOVER, or can it also
> appear in the REQUEST? (I would assume both, i.e., I think clients can
> provide options in the REQUEST normally)

Both make sense to me. Will rectify.

> >    Option code
> >       DHCP_MIP_OPTION (to be assigned by IANA)
> > 
> >    Length
> >       Length in bytes of this option, not including the Option code and
> >       Length bytes.
> 
> Not sure why you include this here (section 3.3.) the picture shows
> only a suboption. Shouldn't the description just include the
> sub-option fields? (This is also for consistency, since the other
> suboption doesn't seem to include the code/length of DHC option
> itself).

Yes. should be sub-option, not option.

> >       The address trough which the Mobile Node may reach the announced
> 
> s/trough/through/

Yes.

> >    Sequence Number
> >       The count of Mobility Agent DHCP announcements made since the DHCP
> >       server was initialized (RFC 3220, Section 2.3.2 [5]).
> 
> This is copied from the MIP advertisement. But does it make sense
> here? Isn't this for replay protection (or something?)? Not sure the
> same rational applies here. Also, this is a potentially significant
> new requirement on the DCHP server. I'm not aware of any other option
> that requires this sort of state me maintained.

There are instances where the use of this field would make sense, 
mostly to signal a re-boot of a box with co-located dhcp server and
fa. But in most cases, it should be possible to signal that this
field should be ignored. My thought is to add a bit field whereby
this and any other selected field may be marked "to be ignored".

> Also, what does it mean in the context of DHC, where the server may be
> talking to multiple  different clients... Is this a per-client count,
> or a total count?

Total count, not per client.

> >    B
> >       Busy.  The foreign agent will not accept registrations from
> >       additional mobile nodes.
> 
> Also copied from the MIP message. But the DHC server generally won't
> be able to set this bit sensibly as I would assume only very loose
> syncronization between the DHC server and specific mobility agents.

Agree; basically the same comment applies here as above for the
sequence number.

> > 6. IANA Considerations
> > 
> >    The value for the DHCP_MIP_OPTION code must be assigned from the
> >    numbering space defined for public DHCP Options in RFC 2939 [10].
> 
> Create a new IANA registry for future subtypes?

Yes.