RE: [Mipshop] DT progress report on draft-melia-mipshop-mstp-solution-01
Hi Tele,
Thanks for the good draft. Some comments.
1. Figure-2 does not show Mosh. The text says that mobility services
are ALSO provided by visited network... Clarify text or figure.
2. Scenario-s4: This scenario refers to MN requesting services from a
3rd party. It is possible for MOS to exist in both visited and home
network. Should atleast acknowledge in the text.
3. Is the text after figure 4 applicable only to S4? I hope not. Need a
separate heading.
4. Please add IEEE in front of 802.21 whereever.
5. Section 4: "For the discovering the location of an MOS..." There is
some confusion here regarding service discovery and address resolution.
First we do service discovery in a realm and then address resolution. In
one case, MN can have only static realm info and service discovery and
address resolution must be done. In another case, MN may not even have
the realm info e.g. visited or 3rd party and discovery and resolution
follow.
6. section 4: ...or this address could be dynamically assigned through
DHCP or DNS by the network. Suggest rephrasing to "or this address could
be obtained through DHCP or DNS."
7. Figure 5, I do not see any relevance to show MIHF-User in figure. It
shows MN stack, what about network stack?
8. Section 4.2. It is good to mention that MIHF Id are managed at MIHF
layer.
9. Section 5.2. It is not clear why DHCP is favorable in S2. Once the
visted realm is known from DHCP or reverse DNS, one could just use the
DNS query. I do not understand why DHCP is preferable. Knowing that the
visited network can also be a home network to their subscribers (as in
S1), they have to support DNS discovery mechanism. Now, with this
requirement, we ended up requiring a network to support both DNS for S1
and DHCP and S2. Plus the DHCP still requires two exchanges, one for
realm discovery and then for MOS discovery. If realm discovery does not
work, reverse-DNS and then again MOS discovery with DHCP?
10. Figure 8, under what conditions does AAAh knows to provide MOS info
to the AAAv during access authentication. Does it do all the time?
11. Section 5.2, knowing that a network SHOULD support DNS for scenario
S1 , there is no need for any complication to discover MOS using other
mechanims e.g. DHCP and then again during access authentication. Why
even touch DHCP and AAA?
12. section 5.4. contradiction. First statement says MUST and last
statement says CAN.
13. section 5.4. why explicitly point out that local network discovery
is done by DHCP (fig 9a)? Can't we use DNS as in section 5.1 or 5.2?
14. MIH ACK definition: no reference to UDP is needed. Suggest removing
all references to MIH ACK from the draft. Just say that in the case of
UDP, the reliability is expected to be supported in the MIH layer.
15. section 6.2. message rate estimations are unfounded. Just talk about
congestion control without reference to rates.
16. Assumptions on IS messages are unwarranted. What if 802.21 added
dynamic info to IS in their next version? Suggest removing SHOULD for
TCP use.
17. where are default ports defined?
18. why does figure 10 show an optional discovery mechanism instead of
DNS? Would be good to show TLS exchange (as a box).
Regards,
Srini
-----Original Message-----
From: ext Telemaco Melia [mailto:melia@nw.neclab.eu]
Sent: Wednesday, November 21, 2007 9:47 AM
To: mipshop@ietf.org
Cc: STDS-802-21@listserv.ieee.org; mipshop-mih-dt@ietf.org
Subject: [Mipshop] DT progress report on
draft-melia-mipshop-mstp-solution-01
Hello,
The DT recently posted the -01 version of the solution document.
The ID already received several reviews from the 802.21 WG and all
required changes have been implemented in the current version.
For a productive meeting in Vancouver we would welcome reviews from the
WG.
Please send your reviews to quickly advance the status of the document.
Cheers,
Telemaco (on behalf of the entire DT)
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop