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

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Fri, 15 Feb 2008 09:23:34 +0100

Thanks Kevin,

Your review is very useful. I copy in cc the DT mailing list.
Your comments will be considered in the revision of the document.
If in the meanwhile you think there are fundamental issues we should
address to improve the ID please feel free to post them to the mailing
list.

Cheers
Telemaco

-----Original Message-----
From: Noll, Kevin [mailto:[email-masked]] 
Sent: Thursday, February 14, 2008 7:30 PM
To: Telemaco Melia (tmelia)
Cc: Nada Golmie; Subir Das
Subject: RE: [Mipshop] WG last call on MIH solution
document(draft-ietf-mipshop-mstp-solution-01.txt)

Telemaco,

I've been lurking on the MIPSHOP list for a while, but have not been
active in any of the conversations regarding this draft. I also do not
consider myself an expert on the subject matter, so I'm not posting
comments to the list.

I do, however, have some minor comments regarding this draft if you
could forward them to whomever is appropriate.

1. Sect. 3.4 para 1 - spelling error
"exist both in hom enad in visited" should be "exist both in home and in
visited

2. Sect. 4 para 6 - grammar
"The MN could know or not the realm" could be better stated as "The MN
could know or not know the realm" or "The MN might or might not know the
realm"

3. Sect. 4 para 6 - spelling
"The dynamic assignation methods " should be "The dynamic assignment
methods"

3. Sect. 4 para 6 - clarify
If the MoS is statically configured, why wouldn't the realm also be
statically configured?
Perhaps this clarification isn't important in this "Overview" section,
but I'm just reading it from top to bottom.

4. All sections - spelling/grammar
The singular form of "case" is often used where the plural form should
be used. For example, in Sect. 4.1 para 3, "In case where " should be
"In cases where ". Optionally the singular form could be used if the
phrase is changed to "In the case where".

5. Sect. 4.2 - clarify
What does "and invariant to interface IP addresses" mean?

6. Sect. 5 para. 3 - grammar
"similarly to what " would be better stated as "similar to what is
specified "

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

8. Sect. 5.1 para. 1 - grammar
"as shown inFigure 6a." should be "as shown in Figure 6a."

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?

10. Sect. 5.2 para. 3 - grammar/omission Paragraph ends with "it MUST
use that address in the reverse". I think it  is meant to be "it MUST
use that address in the reverse DNS query".

11. Sect. 5.2 Title - nit-pick
Should "MIN" be "MN"?

12. Sect. 5.2 para. 3 - nit-pick
"Reverse dns query" should be "Reverse DNS query" (DNS should be
capitalized, I think)

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?

14. Sect 5.3 para 2 - grammar
"described in section Section 5.1" should be "described in section 5.1" 
(redundant word "section")

15. Sect 5.3 para 3 - grammar
"Similarly to" should be "Similar to"

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

17. Sect 5.3 para 11 - grammar/clarify
Does "the MoS information will anyway be sent to the AAAV" mean "the MoS
information will always be sent to the AAAv"?

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?

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

20. Sect 5.4 para 1 - grammar
"network as inFigure 9" should be "network as in Figure 9"

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?

22. Sect 6. para 1 - clarify
What does this sentence mean? "The client MAY use the DNS discovery
mechanism to discover which transport protocols are supported by the
server in addition to TCP and UDP."

23. Sect 6.1 para 1 - grammar
"between 50 to100 bytes " should be "between 50 to 100 bytes "

24. Sect 6.1 para 1 - nit-pick
"wasted bandwidth utilization" should be "wasted bandwidth" or "poor
bandwidth utilization" ... it doesn't make sense (grammatically) to
"waste utilization".

25. Sect 6.5 para 1 - grammar
"particular transport.." should be "particular transport." (one ending
period)

26. All sections - nit-pick
There is inconsistent use of "MOS" versus "MoS". "MoS" (with lowercase
"o") is defined in Section 2.

27. Sect 6.5 para 2 - technical
Why is the MN not required to support UDP?

28. Sect 7. para 1 - grammar
"MIH user requests for an IS service" should be "MIH user requests an IS
service" or "MIH makes a request for an IS service".

29. Sect. 7. para 2 - technical
There seems to be an assumption of DHCPv4 being in use. Is this correct?
What if DHCPv4 is not available?

30. Sect. 7. para 2 - technical
Is it also be possible for the MN to receive the MoS address in DHCP
initialization? In other words, rather than waiting some period of time
after the MN has obtained its initial IP configuration to send a request
via DHCPINFORM, the MN could request the MoS option request in a
DHCPDISCOVER/DHCPREQUEST and receive the MoS address in the
DHCPOFFER/DHCPACK.

Of course, this assumes the MN is using DHCP to initialize the IP
parameters.

31. Sect. 7 para 2 - grammar
"The message arrives to the source" should be "The message arrives at
the source"

32. Sect. 8. para 2 - grammar
"In case where " should be "In the case where "

33. Sect. 8. para 2 - grammar
"of DHCP messages are required" should be "of DHCP messages is required"

34. Sect. 8. para 2 - grammar
"it is recommended that network administrators should use DHCP
authentication option described in [RFC3118], where"
should be
"network administrators should use the DHCP authentication option
described in [RFC3118] where"

35. Sect 8 para 2 - grammar
"This will also protect the denial of service attacks to DHCP server."
should probably be
"This will also protect the DHCP server against denial of service
attacks."

36. Sect 8. para 3 - grammar
see #32 

37. Sect. 8 para 4 - grammar
"In case where reliable " should be "In the case where a reliable "

38. Sect. 8 para 4 - nit-pick
"a specific > transport" should be "a specific transport"

--kan--
--
Kevin A. Noll, CCIE
Sr. Wireless Engineer
Time Warner Cable
13241 Woodland Park
Herndon, VA 20171
o: +1-703-345-3666
m: +1-717-579-4738
AIM: knollpoi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vijay Devarapalli
Sent: Wednesday, February 13, 2008 6:37 PM
To: 'Mipshop'
Subject: [Mipshop] WG last call on MIH solution
document(draft-ietf-mipshop-mstp-solution-01.txt)

Hello folks,

This is to announce a working group last call for the MIH solution
document (draft-ietf-mipshop-mstp-solution). You can find the document
at the following URL.

http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-01.
txt

The last call expires on March 5 2008. (Its a three week last call
because of Internet Draft submission deadlines on the 18th and 25th).

The intended status for this document is Standards Track.

Please post any issues or comments on this document to the MIPSHOP WG
mailing list. In case you have reviewed the document and found no
issues, please send an email saying you support advancing this document.

Vijay
_______________________________________________
Mipshop mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mipshop
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject
to copyright belonging to Time Warner Cable. This E-mail is intended
solely for the use of the individual or entity to which it is addressed.
If you are not the intended recipient of this E-mail, you are hereby
notified that any dissemination, distribution, copying, or action taken
in relation to the contents of and attachments to this E-mail is
strictly prohibited and may be unlawful. If you have received this
E-mail in error, please notify the sender immediately and permanently
delete the original and any copy of this E-mail and any printout.

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 Feb 2008 10:55:01 -0800

Telemaco, Kevin,

Now that the document is a working group document, discussions
should be held on the MIPSHOP WG mailing list. Not the design
team mailing list. The comments from Kevin, seemed to be
editorial, so its ok in this case. But if there are any
technical discussions they should be on the MIPSHOP mailing list.

Vijay

---

From: Telemaco Melia <[email-masked]>
Date: Fri, 15 Feb 2008 22:32:06 +0100

Sorry about that Vijay.
Kevin could you please post to the mipshop ML?

Thanks,
Telemaco

---

From: "Noll, Kevin" <[email-masked]>
Date: Tue, 19 Feb 2008 10:51:12 -0500

I will post any additional comments to the MIPSHOP mailing list.

Thanks!

--kan--
--
Kevin A. Noll, CCIE
Sr. Wireless Engineer
Time Warner Cable
13241 Woodland Park
Herndon, VA 20171
o: +1-703-345-3666
m: +1-717-579-4738
AIM: knollpoi

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: Friday, February 15, 2008 4:32 PM
To: Vijay Devarapalli
Cc: Telemaco Melia (tmelia); [email-masked]; Noll, Kevin
Subject: Re: [MIPSHOP-MIH-DT] [Mipshop] WG last call on MIH solution

Sorry about that Vijay.

Thanks,
Telemaco

Vijay Devarapalli ha scritto:
> Telemaco, Kevin,
>
> Now that the document is a working group document, discussions should 
> be held on the MIPSHOP WG mailing list. Not the design team mailing 
> list. The comments from Kevin, seemed to be editorial, so its ok in 
> this case. But if there are any technical discussions they should be 
> on the MIPSHOP mailing list.
>
> Vijay
>
>> address to improve the ID please feel free to post them to the 
>> mailing list.
>>
>>
>> Cheers
>> Telemaco
>>  
>>
>> active in any of the conversations regarding this draft. I also do 
>> not consider myself an expert on the subject matter, so I'm not 
>> posting comments to the list.
>>
>> "exist both in hom enad in visited" should be "exist both in home and

>> in visited
>> "The MN could know or not the realm" could be better stated as "The 
>> MN could know or not know the realm" or "The MN might or might not 
>> know the realm"
>>
>> Perhaps this clarification isn't important in this "Overview" 
>> section, but I'm just reading it from top to bottom.
>>
>> The singular form of "case" is often used where the plural form 
>> should be used. For example, in Sect. 4.1 para 3, "In case where " 
>> should be "In cases where ". Optionally the singular form could be 
>> used if the phrase is changed to "In the case where".
>>
>> 5. Sect. 4.2 - 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)"
>>
>> 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?

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

>> returned domain name and remove portions of the domain name 
>> iteratively until it successfully finds an MoS?
>>
>> 17. Sect 5.3 para 11 - grammar/clarify Does "the MoS information will

>> anyway be sent to the AAAV" mean "the MoS information will always be 
>> sent to the AAAv"?
>>
>> 18. Sect 5.3 - technical

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

>> "MIH user requests for an IS service" should be "MIH user requests an

>> IS service" or "MIH makes a request for an IS service".
>>
>> initialization? In other words, rather than waiting some period of 
>> time after the MN has obtained its initial IP configuration to send a

>> request via DHCPINFORM, the MN could request the MoS option request 
>> in a DHCPDISCOVER/DHCPREQUEST and receive the MoS address in the 
>> DHCPOFFER/DHCPACK.
>>

>> document (draft-ietf-mipshop-mstp-solution). You can find the 
>> document at the following URL.
>>
>>

>> proprietary information, which is privileged, confidential, or 
>> subject to copyright belonging to Time Warner Cable. This E-mail is 
>> intended solely for the use of the individual or entity to which it
is addressed.
>> notified that any dissemination, distribution, copying, or action 
>> taken in relation to the contents of and attachments to this E-mail 
>> is strictly prohibited and may be unlawful. If you have received this

>> delete the original and any copy of this E-mail and any printout.

This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.

---

From: <[email-masked]>
Date: Fri, 29 Feb 2008 17:30:33 -0600

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.

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

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.

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

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

>> is the correct assumption, what happens if only IPv4 and DHCPv4 are 

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? 

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

>> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop-mih-dt