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

[Telemaco Melia <[e-mail]>]

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

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
>
> Telemaco Melia (tmelia) wrote:
>   
>> 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:[e-mail]] 
>> 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: [phone]
>> m: [phone]
>> AIM: knollpoi
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>> 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
>> [e-mail]
>> http://www.ietf.org/mailman/listinfo/mipshop-mih-dt
>>     
>
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/mipshop-mih-dt
>   

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