Subject: Re: [Mipshop] [Fwd: Re: Comments draft-ietf-mipshop-fh80216e-06]

From: Heejin Jang <[email-masked]>
Date: Mon, 03 Mar 2008 01:18:04 +0000 (GMT)

Rignt.
 
In the next version of the draft, we will define generic trigger messages not 
to rely on 802.21, and give a description about 802.21 primitives and their applicability in 
the appendix.  

Thanks for your concerns. :)
 
- Best regards, 
Heejin.

------- Original Message -------
Sender : Rajeev Koodli<[email-masked]>
Date   : 2008-03-01 12:53 (GMT+09:00)
Title  : Re: [Mipshop] [Fwd: Re: Comments draft-ietf-mipshop-fh80216e-06]

On Fri, Feb 29, 2008 at 3:21 PM, Vijay Devarapalli <[email-masked]> wrote:

>
> It seems a bit of a step backwards, away from the original conception of
> the work, to remove normative references to .21. Many of the
> presentations in MIPSHOP have illustrated use of MIP with .21. It was a
> major impetus of .21 to add features to the L2 to satisfy the needs of
> facilitating network layer mobility. Would it be possible to retain
> normative reference to .21, perhaps following some path used in previous
> successful joint projects that were documented in RFC 4441?

I wanted to comment on this particular topic.

The intention is to not require 802.21 to be implemented for
someone to be able to use FMIPv6 over 802.16e access networks.
So we are just modifying the text to reflect this.

The document will still describe how to use FMIPv6 over
802.16e using 802.21 primitives.
Right. It&#39;s been the thinking all along that FH-802.16e should be able to run without requiring 802.21, but be able to use it when available.         
-Rajeev        

Vijay
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Noll, Kevin" <[email-masked]>
Date: Mon, 3 Mar 2008 09:40:15 -0500

I don't believe these comments made it to the MIPSHOP group at-large, so
I am re-posting them. Most are editorial in nature, and I do not claim
to be an expert on the particular subject material, so some of the
questions or comments may not make sense.

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

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: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Fri, 7 Mar 2008 13:04:04 +0100

Hi Kevin,

Please see answers in line starting where Gabor stopped. Editorial
comments skipped, will edit the text as suggested.

tele

[snip]

[tele] this section is the result of simulations studies where several
scenarios were evaluated. Considering that ES and CS would work with TCP
(even tough might not be the best choice) we decided to mandate TCP only
at MN side.

[tele] this is jus an example. Would you like to see a v6 example as
well?

[tele] Please see section 4.1 of draft-bajko-mos-dhcp-options-02.txt.

Thanks for the comments.