Re: [Mipshop] Comments on draft-ietf-mipshop-mstp-solution-03

["Telemaco Melia (tmelia)" <[e-mail]>]

V4 is being re-worked. We should be able to post soon the new text and
diff from v3.

telemaco 

-----Original Message-----
From: Vijay Devarapallli [mailto:[e-mail]] 
Sent: Friday, May 09, 2008 6:16 AM
To: [e-mail]; Telemaco Melia (tmelia); [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: Comments on draft-ietf-mipshop-mstp-solution-03

Hello,

I was about to prepare the document shepherd writeup for
draft-ietf-mipshop-mstp-solution in order to send the document to the
IESG. But its not ready yet. I went through draft once more and have a
few comments.

 >    IS Information Service: a MoS that originates at the lower or
upper
>
>      layers and sends information to the local or remote upper or
lower
>      layers.  It can use secure or insecure ports to transport
>      information elements (IEs) and information about various
>      neighboring nodes.

We might have to clarify what "lower" and "upper" layers mean here.
I guess "lower" is anything below IP and "upper" is anything above the
transport layer? What if an event is generated by Mobile IP (the same
"upper" and "lower" terminology is used for ES and CS information too)?

> Its architecture is outside the scope of the
>      IEEE 802.21 draft document.

Do we care about this in this draft?

>   o  MoS discovery can be performed during initial network attachment
>      or thereafter.

Re-word to

  o  MoS discovery can be performed either during initial network
     attachment or at any time thereafter.

>   The MN could know or not know the realm of the MoS to be discovered.

Re-word to

 The MN may not know the realm of the MoS to be discovered.

>   In any case after the acquisition of the target realm (e.g. via
>   Information Server or statically configured) the MN could either be
>   pre-configured with the address of the MoS, or this address could be
>   obtained through DHCP or DNS.

Something is wrong with the above sentence. Couldn't parse it.

>                              +-------+
>               +----+         |Domain |
>               | MN |-------->|Name   |
>               +----+         |Server |
>                              +-------+
>                [e-mail]
>
>                             (a) using DNS Query
>
>
>
>                            +-----+      +------+
>               +----+       |     |      |DHCP  |
>               | MN |<----->| DHCP|<---->|Server|
>               +----+       |Relay|      |      |
>                            +-----+      +------+
>
>
>                             (b)  Using DHCP Option
>
>    Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option

You might want to mention here that the DHCP relay is optional. It may
not always be there between the MN and the DHCP server in the home
network.

> 5.2.  MoS Discovery when MN is in visited network and MoSv is also in
>      visited network (Scenario S2)

>   It should be noted, that the usage of DHCP options to discover an
MoS
>   in this particular scenario is recommended because of its simplicity
>   over the DNS based discovery method: the DNS discovery method
>   requires the MN to learn the domain name of the local network first,
>   possibly using DHCP, and then perform the DNS query.  The usage of
>   the DHCP based discovery method does not require any additional
>   procedure.

I think the above paragraph should be re-worded. Its possible that the
visited network has deployed MoS, but not the DHCP extensions for
discovering a MoS server. So the MN should first try using DHCP.
If there is no response, the MN should try to do a DNS lookup for the
MoS server after acquiring the visited network realm information.

> 5.3.  MOS Discovery when the MN is in a visited Network and Services
are
>      at the Home network (Scenario S3)

>   The mobile node executes the network access authentication procedure
>   (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS.  The NAS
>   is in the visited and it interacts with AAAh via AAAv to
authenticate
>   the mobile node.  In the process of authorizing the mobile node, the
>   AAAh verifies in the AAA profile that the mobile node is allowed to
>   use MoS services.  The AAAh assigns the MoS in the home and returns
>   this information to the NAS.  The NAS may keep the received
>   information for a configurable duration or it may keep the
>   information for as long as the MN is connected to the NAS.

Why is authorization relevant here? I also I wonder why there is no talk
about checking if the MN is authorized for MoS service in scenarios S1
and S2. Why does authorization become important for only in scenario S3?

> 6.  MIH Transport Options
>
>   Once the Mobility Services have been discovered, MIH peers MAY
>   exchange information over TCP, UDP or any other transport supported
>   by both the server and client, as described in
>   [I-D.rahman-mipshop-mih-transport].

We are not planning to progress
draft-rahman-mipshop-mih-transport-03 in any form. The above text seems
to suggest that this draft should be an Normative reference.
Why is this reference relevant here?

> 11.1.  Normative References
>
>   [I-D.ietf-dhc-dhcpv6-opt-dnsdomain]
>              Yan, R., "Domain Suffix Option for DHCPv6",
>              draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in
progress),
>              June 2007.

You are adding a normative reference to the above draft. I am not sure
what the status of the above draft is. If we leave it as a normative
reference, draft-ietf-mipshop-mstp-solution will not be published until
the DHCPv6 draft is published.

>   [I-D.ietf-dime-mip6-integrated]
>              Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
>              and K. Chowdhury, "Diameter Mobile IPv6: Support for
>              Network Access Server to Diameter Server  Interaction",
>              draft-ietf-dime-mip6-integrated-08 (work in progress),
>              February 2008.
>
>   [I-D.ietf-mip6-bootstrapping-integrated-dhc]
>              Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
>              Integrated Scenario",
>              draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
>              progress), April 2008.

These two should be moved to Informative section. You are referring to
these drafts to say that the solution is similar to these. Thats all,
not using anything from these drafts.

>   [I-D.ietf-tsvwg-udp-guidelines]
>              Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for
>              Application Designers",
draft-ietf-tsvwg-udp-guidelines-06
>              (work in progress), April 2008.

Informative. These are just guidelines.

>   [I-D.stupar-dime-mos-options]
>              Korhonen, J. and T. Melia, "Diameter extensions for MoS
>              discovery", draft-stupar-dime-mos-options-00 (work in
>              progress), February 2008.

Informative. Not relevant for implementing the solution described in
this draft.

>   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
>              Internet Protocol", RFC 4301, December 2005.
>
>   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
>              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
>
>   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
>              Security", RFC 4347, April 2006.
>
>   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J.,
>              and T. Wright, "Transport Layer Security (TLS)
>              Extensions", RFC 4366, April 2006.

All of these should be Informative. You are only referring to them in
the security considerations section saying that they can be used to
protect the MIH messages.

>   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
>              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
>              RFC 4787, January 2007.

Informative again.

Telemaco, how soon can you submit a new version? :) As soon as you
submit a new version, it will be shipped to the IESG.

I apologize for bringing up these issues so late. I should I have done
this during the WG last call.

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