Re: [MIPSHOP-MIH-DT] [Mipshop] WG last call on MIHsolution document(draft-ietf-mipshop-mstp-solution-01.txt)

Hello Kevin,

Thanks for your comments. Since I wrote most of section 5, I try to
address your comments to that section: 

-- snip --

I also skip the editorial comments, I will correct the text as you
suggested.

>> 7. Sect. 5 para. 4 - clarify
>> "In case MoS is provided in a remote network other than visited or 
>> home network (scenario S4)" might be better stated as "In the case 
>> that MoS is provided by a third-party network (scenario S4)"

Ok, I'll change the sentence to "In case MoS is provided by a
third-party network, which is different from the current visited
network, ..."

>> 9. Sect. 5.1 para. 1 - technical
>> I'm not sure I agree with the statement that "Home domains are 
>> usually pre-configured in the MN". On what basis is this assumption 
>> made? Even if it is a correct assumption, shouldn't there be a 
>> provision for the scenario where the MN does *NOT* have the home
domain pre-configured?

If the home domain is not preconfigured, how would the MN find it out?
The subscription is tight to a network, which is the home. If there is
no home network, there is no subscription.

>> 13. Sect. 5.2 para. 3 and 4 - technical Perhaps the authors can 
>> clarify what the expected result of the reverse DNS query should be.
>> It seems to me that it would not be uncommon for the reverse query 
>> (if it doesn't fail altogether) to return a domain name that is not 
>> the same as the desired MoS realm name. For example, what if the 
>> reverse query returns something like 
>> node1234.dulles.va.myprovider.net, but the MoS realm should be 
>> myprovider.net? Should the MN attempt to contact the MoS based on the
>> returned domain name and remove portions of the domain name 
>> iteratively until it successfully finds an MoS?

I don't know the answer to this question. I need to investigate how
other specs handle this or implementations deal with it. 

>> 16. Sect 5.3 para 4 - technical
>> What is the document references by "[REF TO NEW DOC]"?

It is a new I.D, which was submitted last week. We need to put the name
of that I.D there (draft-stupar-mos-diameter-options).

>> 18. Sect 5.3 - technical
>> This discovery method seems to assume the use of IPv6 and DHCPv6, but
>> does not state that assumption anywhere that I can find. Even if this
>> is the correct assumption, what happens if only IPv4 and DHCPv4 are 
>> available to the MN?

I-D.bajko-mos-dhcp-options defines extensions to discover MoS only in
visited network for the dhcpv4 case. If the MN is using MIPv4, then the
bootstrapping can happen using AAA. If the MN is only using dhcpv4, then
according to the current status of the work, it can only discover an MoS
in the visited network. To support MoS discovery in the home network
while roaming, using dhcpv4, we would need additional work (define a few
additional dhcpv4 extensions). The question is, do we have or foresee a
deployment scenario which would require this? 

>> 19. Sect. 5.4 - technical
>> Why can the MoS domain name not be pre-configured?

It can, but all 3rd party domain names cannot be preconfigured, it is
not feasible. I will clarify the text.

>> 21. Sect. 5.4 - technical
>> Would an alternative method of discovering the third party MoS be 
>> similar to that described in sect. 5.3 where the AAAh and/or AAAv are
>> able to return the third party MoS information?

Well, what the MN discovers using the procedures in section 5.3 is an
MoS address provided to the MN by the home network. That MoS may
virtually be anywhere (in visited, in home, in a preconfigured 3rd
party), but it is provided to the MN as per the policy in the
subscription. In section 5.4 we define a scenario when the MN does want
an MoS address from a specific 3rd party (maybe in addition of the home
MoS).

Thanks for the good catches.
- gabor
_______________________________________________
MIPSHOP-MIH-DT mailing list
MIPSHOP-MIH-DT@ietf.org
https://www.ietf.org/mailman/listinfo/mipshop-mih-dt