Subject: [dhcwg] Re: AD review of draft-ietf-mip6-hiopt

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Nov 2007 16:02:09 +0200

Hi all,

I have reviewed the new version and it satisfies my AD review
concerns with the exception of the below minor issues.

Also, I expect that the draft also has to satisfy DHC WG's review,
and address the issues raised by Bernie. I have not looked
at those yet, Bernie have you?

>>         id-type
>>
>>            The type of Home Network Identifier:
>>
>>                0    Visited domain (local ASP)
>>
>>                1    Target MSP
>>
>>                2    No preference
>>     
>
> This seems unnecessarily complicated. Is there some reason why you could
> simply include the target MSP domain information if it is known or an
> empty string otherwise and be allocated a local ASP in that case?
>   

I still disagree that this is needed, but I'm not making this
a blocking comment if the WG wants to do it.

>> 3.2.  MIP6 Relay Agent Option
>>
>>    This option carries the RADIUS or Diameter attributes that are
>>    received at the NAS from the AAAH.  The DHCP relay agent sends this
>>    option to the DHCP server in the Relay-Forward message.
>>     
> It does not carry RADIUS or Diameter attributes (and nor should it).
> Please align this text with the actual subattributes that you have.
>
> Also, it is inappropriate to assume that the information can only come
> from AAA. Presumably we'd like the mechanisms to be general enough that,
> for instance, manual configuration, link identifier, etc. could also be
> used to determine what mobility domains are appropriate for this client.
>   

Text was changed, but it still assumes the data comes from AAAH only.
Suggested edit:

OLD:
   This option carries the home network information which was
   transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius].
NEW:
   This option carries the home network information for the mobile
   node (the NAS may know this, for instance, through AAA by
   using [I-D.ietf-mip6-radius]).

>>            OPTION_MIP6-HNID (TBD)
>>     
> Do you really have to mix underscore and dash in the same symbol?
>   

Some of this still remains: OPTION_MIP6-HNINF (TBD).

Jari

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Nov 2007 09:37:05 -0500

I did review a recent version of the draft - I'm not sure which revision
is now the latest. See the attached email regarding my most recent set
of comments.

- Bernie

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Friday, November 09, 2007 9:02 AM
To: [email-masked]; Bernie Volz (volz)
Cc: Mobile IPv6 Mailing List; Dhcwg
Subject: Re: AD review of draft-ietf-mip6-hiopt

Hi all,

OLD:

Jari

Subject: RE: Review request
From: "Bernie Volz (volz)" <[email-masked]>
To: "Heejin Jang" <[email-masked]>, <[email-masked]>
Cc: "Alper Yegin" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Basavaraj Patil" <[email-masked]>, "Gopal Dommety (gdommety)" <[email-masked]>, "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 1 Nov 2007 21:56:51 -0500

I haven't had much time to do a careful review, but from a quick scan at
least the DHCPv6 options and suboptions are now formatted appropriately.

There's a lot of reserved fields, and perhaps there are plans to use
them, but usually it is difficult to predict the future and sometimes
best to remove stuff like that. But, it is your call.

I also wonder whether the 3.3.1 Home Network Information sub-options
might not be 1 through 6 (instead of 1-3), and incorporate the V bit
into the sub-opt-code. Perhaps you don't even need all 6 values (not
sure if they can all have both values of the V bit). But, that's really
your call.

I think the IANA considerations should also request IANA to start a
registry for the sub-options (3.2.1 & 3.3.1)? Or, how will that space be
managed? And, usually IANA wants to know how future values are to be
assigned (standards action or ...) if it is charged with maintaining a
registry. You'll get that comment during the IANA review if you don't
include it.

I also wonder whether anyone needs to manage the "id-type" space? Or
will there never be any more of these values? Or, is that already
something managed elsewhere in the Mobile IP WG documents (if so,
providing a cross reference to that document would be useful).

I'd also suggest that when FQDN's are mentioned (such as in 3.2.1, "When
the sub-opt-code is set to 3, the Home Network Information field MUST
contain the FQDN as described in [RFC1035]."), you reference RFC 3315,
Section 8 regarding the encoding. Just saying "as described in
[RFC1035]" doesn't tell anyone how it is encoded -- we want all FQDNs to
be DNS wire encoded.

In section 4.3, what's the value of "It may include Interface-Id option,
Client Identifier option according to [RFC3315]." First, interface-id is
usually a RELAY AGENT option (so it may be in the Relayed
Information-Request), but I don't understand why pointing out these two
options is necessary (there are a lot of other options that could be in
an Information-Request or the Relay-Forw part of the message. Nothing in
that section ever references using either of these options for anything.
So, I'd drop that sentence.

Similar text ("The mobile node SHALL also include the OPTION_CLIENTID
[RFC3315] to identify itself to the DHCP server." and later "The relay
agent MAY include the Interface-Id option [RFC3315] in the Relay-forward
message.") is also in 4.1.

- Bernie 

-----Original Message-----
From: Heejin Jang [mailto:[email-masked]] 
Sent: Thursday, October 25, 2007 1:23 AM
To: Bernie Volz (volz); [email-masked]
Cc: Alper Yegin; [email-masked]; [email-masked];
Basavaraj Patil; Gopal Dommety (gdommety); Ralph Droms (rdroms)
Subject: Review request

Hi, Bernie and David.

We appreciate your concern and kind feedback for the hiopt draft.
Your comments were helpful to improve the draft, and the authors has
revised the draft based on your feedback.

Could you review the revised one?
If you kindly review the draft, it would be much of help.

ps> AD's comments will be handled separately.

- Best Regards,
Heejin.