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

Kevin,

Would you mind forwarding these comments to the mipshop mailing list, so
that I can send my reply there too (I do not want to send the reply
without the original mail, as that would look out of context).

Thanks!
- gabor

>> -----Original Message-----
>> From: Noll, Kevin [mailto:kevin.noll@twcable.com]
>> 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: mipshop-bounces@ietf.org [mailto:mipshop-bounces@ietf.org] 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
>> Mipshop@ietf.org
>> 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
>> MIPSHOP-MIH-DT@ietf.org
>> http://www.ietf.org/mailman/listinfo/mipshop-mih-dt
>>     
>
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> MIPSHOP-MIH-DT@ietf.org
> http://www.ietf.org/mailman/listinfo/mipshop-mih-dt
>   

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
MIPSHOP-MIH-DT@ietf.org
http://www.ietf.org/mailman/listinfo/mipshop-mih-dt
_______________________________________________
MIPSHOP-MIH-DT mailing list
MIPSHOP-MIH-DT@ietf.org
https://www.ietf.org/mailman/listinfo/mipshop-mih-dt