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

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?

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

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

(Just asking, I don't have a strong opinion, other than if ordering is
important, now is the time to make the rules clear.)

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

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

>       The address trough which the Mobile Node may reach the announced

s/trough/through/

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

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?

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

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

-- 
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4