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

[Vijay Devarapalli <[e-mail]>]

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