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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 9 Nov 2007 11:08:23 -0500

Dear Bernie,

Let me try to address some of your comments/questions. Please see
inline...

BR,
Kuntal

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Friday, November 09, 2007 8:37 AM
> To: Jari Arkko; [email-masked]
> Cc: Mobile IPv6 Mailing List; Dhcwg
> Subject: RE: AD review of draft-ietf-mip6-hiopt
> 
> 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,
> 
> 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?
> >
> 
[KC>] Empty string w/o this id-type indication will be ambiguous since
it won't convey the case for value 2 (no preference). No preference is a
common way for the MN to convey to the network that it does not really
have a preference for the domain from which it wants to bootstrap MIP6
info.

> 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:
> 
[KC>] The text says "the NAS _may_ know this....". Therefore, other ways
are allowed too, but nothing wrong in giving an example, IMHO.

> 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).
> 
[KC>] We should fix these inconsistencies.

> Jari

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Nov 2007 11:29:00 -0500

These comments were from Jari. Mine I sent separately on Nov 1st.

- Bernie 

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

Dear Bernie,

BR,
Kuntal

revision
an

come

> Jari

"This email message and any attachments are confidential information of
Starent Networks, Corp. The information transmitted may not be used to
create or change any contractual obligations of Starent Networks, Corp.
Any review, retransmission, dissemination or other use of, or taking of
any action in reliance upon this e-mail and its attachments by persons
or entities other than the intended recipient is prohibited. If you are
not the intended recipient, please notify the sender immediately -- by
replying to this message or by sending an email to
[email-masked] -- and destroy all copies of this message
and any attachments without reading or disclosing their contents. Thank
you."

---

From: Heejin Jang <[email-masked]>
Date: Mon, 12 Nov 2007 04:41:40 +0000 (GMT)

Hi, Jari.

We've sent the reply email to Bernie in Nov 6th.
Sorry not to post it here and kindly see the below.

- Best Regards, 
Heejin 

-----------------------------------------------------------------------------------------------------------------
Hi, Bernie.

Thank you for your kind feedback again.

Your feeback is reflected in the draft-ietf-mip6-hiopt-08 (which will
be announced in 2~3 days later) and kindly see the inline comment as a
response to your feedback.

On 11/2/07, Bernie Volz (volz) <[email-masked]> wrote:
> 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.

Ok. We deleted the reserved field from the HN Identifier option, HN
Information option and MIP6 Relay Agent sub-option. But the reserved
field in HN Information sub-option is maintained for future use.

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

It's possible. But the sub-opt-code (1-3) is used to indicate what
kind of home network information is provided and the 'V' flag is
indicate the place where the home network information is assigned. So
we think we'd rather not mix them up and prefer to keep the existing
message format.

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

Ok. The request for the sub-opt-code is added into the IANA Section as follows.

"The Sub-option Codes for both OPTION_MIP6_RELAY and OPTION_MIP6_HNINF
options:
      o Home network prefix       1
      o Home agent address       2
      o Home agent FQDN          3

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

We think that it is better to give a field in HN information option
for indicating the mobile node's preference for the requested home
network. Additionally, if DHCP can know the kind of home network
requested by MN explicitly, it does not need to transfer unnecessary
information which is not in the mobile node's interest.

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

Ok. We referred Section 8 of RFC3315 instead of RFC1035 in Section 3.2.1.

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

Ok. We deleted the unnecessary mention for Interface-Id/Client-id
option and described that the MN and the relay agent processes the
messages according to RFC3315. However, we left the decryption for the
Client-id option in Section 4.2 because it is necessary to mention
that the relay agent searches for the requested HN information and
adds the corresponding HN information into the received message by
using the Client-id as a key.

- Best regards,
Heejin

------- Original Message -------
Sender : Jari Arkko<[email-masked]>
Date   : 2007-11-09 23:02 (GMT+09:00)
Title  : Re: AD review of draft-ietf-mip6-hiopt

Hi all,

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

> This seems unnecessarily complicated. Is there some reason why you could
> simply include the target MSP domain information if it is known or an

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

>>    received at the NAS from the AAAH.  The DHCP relay agent sends this
> Also, it is inappropriate to assume that the information can only come
> from AAA. Presumably we&#39;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.
>   

OLD:

Jari

---

From: Heejin Jang <[email-masked]>
Date: Mon, 19 Nov 2007 01:17:55 +0000 (GMT)

Hi, Kuntal. 

No, he didn't. 
About the id-type, he seems to think that 'the id-type' is unnecessary, and which makes the protocol complicated.

---------- AD's comment -------------
 
>>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. 
---------------------------------------------

 If  "no preference" is still needed/used by some other SDO (for 3GPP2 ?), we need to argue it.
Otherwise, we'd rather remove it in the draft.
Kindly let me know your opinion. 
 
- Best Regards, 
Heejin

------- Original Message -------
Sender : Chowdhury, Kuntal<[email-masked]>
Date   : 2007-11-10 01:08 (GMT+09:00)
Title  : [Mip6] RE: AD review of draft-ietf-mip6-hiopt

Dear Bernie,

BR,
Kuntal

> I did review a recent version of the draft - I&#39;m not sure which
revision
an
[KC>] Empty string w/o this id-type indication will be ambiguous since
it won&#39;t convey the case for value 2 (no preference). No preference is a
common way for the MN to convey to the network that it does not really
have a preference for the domain from which it wants to bootstrap MIP6
info.

come

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