Skip to main content

IEEE 802.21 Mobility Services Framework Design (MSFD)
draft-ietf-mipshop-mstp-solution-12

Revision differences

Document history

Date Rev. By Action
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
12 (System) post-migration administrative database adjustment to the Abstain position for Pasi Eronen
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2009-02-06
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-02-06
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-02-06
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-02-05
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-02-05
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-02-05
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-02-04
12 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2009-02-04
12 (System) IANA Action state changed to In Progress
2009-02-04
12 Amy Vezza IESG state changed to Approved-announcement sent
2009-02-04
12 Amy Vezza IESG has approved the document
2009-02-04
12 Amy Vezza Closed "Approve" ballot
2009-02-04
12 Jari Arkko State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko
2009-02-03
12 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to Abstain from Discuss by Pasi Eronen
2009-02-03
12 Pasi Eronen
[Ballot comment]
Two of the four scenarios (described in Section 3) talk about running
this protocol across multiple administrative domains, possibly even
over the general …
[Ballot comment]
Two of the four scenarios (described in Section 3) talk about running
this protocol across multiple administrative domains, possibly even
over the general Internet. I don't think leaving how to use this
securely for future work (or proprietary solutions) is OK in a
Standards Track RFC, and does not meet the requirements of BCP61.

Realistically, this draft cannot fix the situation, so I proposed
publishing this as Experimental instead (with strongly worded IESG
note).

While there can be valid reasons to grant exceptions to BCP61, in my
opinion "some folks prefer to do protocols first and think about
security later" is one of them, even when "some folks" come from
another SDO. However, apparently other ADs don't share my opinion
here, so I'm balloting "Abstain".
2009-02-03
12 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2009-02-03
12 Jari Arkko Waiting on authors, 802.21 chairs, and Pasi.
2009-01-30
12 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-01-30
12 (System) New version available: draft-ietf-mipshop-mstp-solution-12.txt
2009-01-30
12 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation::External Party by Amy Vezza
2009-01-30
12 (System) Removed from agenda for telechat - 2009-01-29
2009-01-29
12 Pasi Eronen
[Ballot discuss]
Two of the four scenarios (described in Section 3) talk about
running this protocol across multiple administrative domains,
possibly even over the general …
[Ballot discuss]
Two of the four scenarios (described in Section 3) talk about
running this protocol across multiple administrative domains,
possibly even over the general Internet.

I don't think leaving how to use this securely for future work
(or proprietary solutions) is OK in a Standards Track RFC, and
does not meet the requirements of BCP61.

Realistically, this draft cannot fix the situation, so I propose
publishing this as Experimental instead (with strongly worded IESG
note). While there can be valid reasons to grant exceptions to BCP61,
I do not think "some folks prefer to do protocols first and think
about security later" is one of them, even when "some folks" come
from another SDO.

However, if other ADs do not share my opinion, I am willing to move
to "Abstain".
2009-01-28
12 Cullen Jennings [Ballot comment]
Support PASI discuss.
2009-01-28
12 Russ Housley [Ballot comment]
2009-01-28
12 Russ Housley
[Ballot discuss]
The Gen-ART Review by David Black was posted on 27-Jan-2009, and Jari
  has indicated that the concerns raised ought to be addressed.  …
[Ballot discuss]
The Gen-ART Review by David Black was posted on 27-Jan-2009, and Jari
  has indicated that the concerns raised ought to be addressed.  Please
  update the document or provide RFC Editor notes.
2009-01-28
12 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Discuss from No Objection by Russ Housley
2009-01-28
12 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2009-01-28
12 Jari Arkko Waiting for authors and Pasi to agree that my IESG note is OK.
2009-01-15
12 Cindy Morgan Placed on agenda for telechat - 2009-01-29 by Cindy Morgan
2009-01-15
12 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2009-01-15
12 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2009-01-15
12 Pasi Eronen
[Ballot discuss]
The document says:

"This document does not provide mechanisms for securing the
communication between a mobile node and the mobility service.
Instead, it …
[Ballot discuss]
The document says:

"This document does not provide mechanisms for securing the
communication between a mobile node and the mobility service.
Instead, it is assumed that either lower layer (e.g., link
layer) security mechanisms, or overall system-specific proprietary
security solutions, are used. The details of such lower layer and/or
proprietary mechanisms are beyond the scope of this document."

I don't think leaving how to use this securely for future work (or
proprietary solutions) is OK in a Standards Track RFC.  Realistically,
this draft cannot fix the situation, so I propose publishing this as
Experimental instead.
2009-01-14
12 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-01-14
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-01-14
11 (System) New version available: draft-ietf-mipshop-mstp-solution-11.txt
2009-01-13
12 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko
2009-01-13
12 Jari Arkko Placed on agenda for telechat - 2009-01-15 by Jari Arkko
2009-01-13
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-01-13
10 (System) New version available: draft-ietf-mipshop-mstp-solution-10.txt
2008-11-04
12 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2008-11-04
12 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2008-11-04
12 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko
2008-11-04
12 Jari Arkko Putting doc in revised id needed for Pasi's discuss.
2008-11-04
12 Jari Arkko Cullen's discuss seems to be addressed in -09. Asking Lars about his. Its more of a borderline case maybe.
2008-11-04
12 Magnus Westerlund [Ballot comment]
2008-11-04
12 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2008-11-03
09 (System) New version available: draft-ietf-mipshop-mstp-solution-09.txt
2008-10-19
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-10-19
08 (System) New version available: draft-ietf-mipshop-mstp-solution-08.txt
2008-10-16
12 Chris Newman
[Ballot comment]
I support Pasi's discuss.  TLS has shown to be a deployable privacy
solution in the real world.  In addition to privacy, it includes …
[Ballot comment]
I support Pasi's discuss.  TLS has shown to be a deployable privacy
solution in the real world.  In addition to privacy, it includes authentication support that works in some scenarios or when combined
with SASL/EAP/HTTP-auth or some other authentication framework), but it
has lots of knobs that have to be specified when a protocol chooses to
use it.  We've had some mistakes when binding it to application protocols
that caused real deployment problems and had to be corrected (the most
notable is allowing "STARTTLS" to be advertised as a capability by a
server even if no server certificate is installed).

I strongly recommend getting this right early rather than botching it
and having to work around bad deployment practices.
2008-09-25
12 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2008-09-25
12 Tim Polk
[Ballot comment]
[I have cleared my discuss and moved this to a comment after discussion with the
sponsoring AD...]

Section 5 puts a lot of …
[Ballot comment]
[I have cleared my discuss and moved this to a comment after discussion with the
sponsoring AD...]

Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and
MoS3.  However, I was surprised to find that these terms never appear in the remainder of the
document.  That is, the transport options in section 6, transport flows in section 7, and
security considerations in section 8 only refer to MoS in general.  I would think that the source
of my mobility services would impact the selection of a transport, and would have security
implications.  (I don't think it impacts the flow, though.  Is that correct?)

Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer
messages which has impacts MIH message Size in 6.1 and rate in 6.2) ?
2008-09-25
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2008-09-25
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-09-25
12 Tim Polk
[Ballot comment]
[I have cleared my discuss and moved this toa comment after discussion with the
sponsoring AD...]

Section 5 puts a lot of effort …
[Ballot comment]
[I have cleared my discuss and moved this toa comment after discussion with the
sponsoring AD...]

Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and
MoS3.  However, I was surprised to find that these terms never appear in the remainder of the
document.  That is, the transport options in section 6, transport flows in section 7, and
security considerations in section 8 only refer to MoS in general.  I would think that the source
of my mobility services would impact the selection of a transport, and would have security
implications.  (I don't think it impacts the flow, though.  Is that correct?)

Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer
messages which has impacts MIH message Size in 6.1 and rate in 6.2) ?
2008-09-25
12 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-09-25
12 David Ward [Ballot comment]
I will let the others hold the discuss but, they must be cleared.
2008-09-25
12 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-09-25
12 Pasi Eronen
[Ballot discuss]
(Updated discuss)

I have read draft-ietf-mipshop-mstp-solution-06. It's not really
possible to review this in meaningful sense without reading 802.21
itself (which I haven't …
[Ballot discuss]
(Updated discuss)

I have read draft-ietf-mipshop-mstp-solution-06. It's not really
possible to review this in meaningful sense without reading 802.21
itself (which I haven't read), but I have the following concerns that
I'd like to discuss:

The document currently says that TLS can be used, but is silent about
the details. For example, how authentication and authorization are
done -- e.g. are some fields in certificates expected to match some
fields in the MIH protocol? What the certificates are expected to look
like? How this interacts with the discovery mechanisms (e.g. NAPTR
specs recommend that the certificate contains the *input* to NAPTR
processing, not the output -- but some specs have chosen otherwise)?
What the mandatory-to-implement parts of TLS are?

In Section 2, the definitions of "MoSh", "MoSv", and "MoS3" seem
inconsistent (MoSV is defined as "anything that isn't a MoSh", and
MoS3 is defined as "anything that isn't a MoSh or MoSV" -- but that
would seem to make MoS3 an empty set).

The document assumes that NAI can be used to identify a MIHF endpoint;
but usually NAI identifies a user account which can be used
simultaneously on multiple hosts (each of which would be a separate
MIHF endpoint).

It seems that both MIH-over-TLS-over-TCP and MIH-over-TCP use the same
port number (likewise for DTLS/UDP case) -- how does the recipient
distinguish which is being used? Perhaps the MIH protocol has
functionality like "STARTTLS"?

draft-ietf-mipshop-mos-dns-discovery-02 supports MIH-over-SCTP as
well, but this document doesn't -- should they be aligned, and if so,
which one needs to be changed?

The examples use real domain names (which are owned by someone). I'd
suggest changing to RFC 2606 names (example.com etc.), unless there
are really good reasons not to do so.
2008-09-25
12 Tim Polk
[Ballot discuss]
This is a discuss - discuss.  After discussion, I will either clear or revise to make this actionable.

Section 5 puts a lot …
[Ballot discuss]
This is a discuss - discuss.  After discussion, I will either clear or revise to make this actionable.

Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and
MoS3.  However, I was surprised to find that these terms never appear in the remainder of the
document.  That is, the transport options in section 6, transport flows in section 7, and
security considerations in section 8 only refer to MoS in general.  I would think that the source
of my mobility services would impact the selection of a transport, and would have security
implications.  (I don't think it impacts the flow, though.  Is that correct?)

Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer
messages which has impacts MIH message Size in 6.1 and rate in 6.2) ?
2008-09-25
12 Tim Polk
[Ballot discuss]
This is a discuss - discuss.  After discussion, I will either clear or revise to make this actionable.

Section 5 puts a lot …
[Ballot discuss]
This is a discuss - discuss.  After discussion, I will either clear or revise to make this actionable.

Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and
MoS3.  However, I was surprised to find that these terms never appear in the remainder of the
document.  That is, the transport options in section 6, transport flows in section 7, and
security considerations in section 8 only refer to MoS in general.  I would think that the source
of my mobility services would impact the selection of a transport, and would have security
implications.  (I don't think it impacts the flow, though.  Is that correct?)

Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer
messages which has impacts MeIH message Size in 6.1 and rate in 6.2) ?
2008-09-25
12 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2008-09-25
12 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2008-09-25
12 Pasi Eronen
[Ballot discuss]
I have read draft-ietf-mipshop-mstp-solution-06. It's not really
possible to review this in meaningful sense without reading 802.21
itself (which I haven't done yet), …
[Ballot discuss]
I have read draft-ietf-mipshop-mstp-solution-06. It's not really
possible to review this in meaningful sense without reading 802.21
itself (which I haven't done yet), but I have the following concerns
that I'd like to discuss:

In Section 2, the definitions of "MoSh", "MoSv", and "MoS3" seem
inconsistent (MoSV is defined as "anything that isn't a MoSh", and
MoS3 is defined as "anything that isn't a MoSh or MoSV" -- wouldn't
that make MoS3 an empty set?).

The document assumes that NAI can be used to identify a MIHF endpoint;
but usually NAI identifies a user account which can be used
simultaneously on multiple hosts (each of which would be a separate
MIHF endpoint). How does this work?

It seems that both MIH-over-TLS-over-TCP and MIH-over-TCP use the same
port number (likewise for DTLS/UDP case) -- how does the recipient
distinguish which is being used? Perhaps the MIH protocol has
functionality like "STARTTLS"? (if so, it should be briefly
described here)

The examples use real domain names (which are owned by someone). I'd
suggest changing to RFC 2606 names (example.com etc.), unless there
are really good reasons not to do so.
2008-09-25
12 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2008-09-25
12 Dan Romascanu
[Ballot discuss]
As there are no known implementations or vendor plans to implement
the specification (according to the proto write-up) I am wondering why this …
[Ballot discuss]
As there are no known implementations or vendor plans to implement
the specification (according to the proto write-up) I am wondering why this document is aiming standards track. Most of the protocol documents in mipshop have been approved until now as Experimental or Informational. Moreover I could not map this document to any of the items in the mipshop WG charter or list of deliverables (no mention of 802.21 there) to help me understand whether this was the intention of the WG from the start and why.
2008-09-25
12 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2008-09-25
12 Lars Eggert
[Ballot comment]
Last Edited Date: 2008-09-25

Section 6.1., paragraph 4:
>    In terms of dealing with short messages, TCP has the capability to
>  …
[Ballot comment]
Last Edited Date: 2008-09-25

Section 6.1., paragraph 4:
>    In terms of dealing with short messages, TCP has the capability to
>    concatenate very short messages in order to reduce the overall
>    bandwidth overhead.  However, this reduced overhead comes at the cost
>    of additional delay to complete an MIH transaction, which may not be
>    acceptable for CS and ES services.

  The only delay with TCP (assuming Nagle is turned off) is the
  connection setup delay, i.e., a delay on the very first MIH exchange.
  Because subsequent exchanges go over an already established
  connection, there is no additional latency. (Other than head-of-line
  blocking under heavy loss due to retransmissions.)


Section 6.2., paragraph 1:
>    Therefore a burst of either
>    short CS/ES messages or long IS message exchanges (in the case where
>    multiple MIH nodes request information) may lead to network
>    congestion.  While the built-in rate-limiting controls available in
>    TCP may be well suited for dealing with these congestion conditions,
>    this may result in large transmission delays that may be unacceptable
>    for the timely delivery of ES/CS messages.

  TCP backs off if there is packet loss, and yes, performance may
  degrade. But UDP is no magic bullet, either - UDP packets in such
  scenarios are lost in the same way as TCP packet, and delivery over
  UDP is unlikely to be more timely than with TCP.


Section 6.3., paragraph 3:
>    An MIH message is retransmitted if its corresponding MIH ACK is not
>    received by the generating node within a timeout interval set by the
>    MIHF.  This approach does not include an exponential backoff and
>    therefore tends to degrade more gracefully than TCP when the packet
>    loss rate becomes large, in the sense that the expected delay does
>    not increase exponentially.  The number of retransmissions is
>    limited, which reduces head-of-line blocking of other MIH messages,
>    but this can cause important ES/CS messages to be lost.  The default
>    number of retransmissions is set to 2 and retransmissions are
>    controlled by a timer with a default value of 10s.  No backoff
>    mechanism is specified.

  I don't buy this. If you wait 10s before the first retransmit and then
  try another one after 20s, TCP will have long retransmitted the lost
  packets, because its RTO is based on the RTT, which is typically much
  less than 10s. UDP will only be faster if much more aggressive timers
  are used here, which is problematic. I'd like to request that the text
  around what timers values are permissible be tightened using 2119
  language. (I believe this is part of Magnus' discuss, so I'll leave this
  as a comment for now. I may upgrade this to a discuss if Magnus'
  discuss doesn't include this bit.)


Section 6., paragraph 1:
>    Given the reliability requirements for
>    the MIH transport, it is assumed in this discussion that the MIH ACK
>    mechanism is to be used in conjunction with UDP, while it is
>    preferred to avoid using MIH ACKs with TCP since TCP includes
>    acknowledgement and retransmission functionality.

  Given the reliability requirements, shouldn't this text REQUIRE MIH
  ACKs with UDP and say they MUST NOT be used with TCP? (I can't come up
  with a reason to permit anything else.)


Section 6.3., paragraph 2:
>    If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.

  See above, I think your reliability requirements make this a MUST.


Section 6.1., paragraph 5:
>    The use of the PUSH bit can alleviate this problem by triggering
>    transmission of a segment less than the SMSS.

  The PUSH bit is not under the control of an application that uses TCP.
  I believe you mean that the Nagle algorithm (RFC896) should be
  disabled.


Section 6.2., paragraph 3:
>    o  If MIHF knows the RTT, the rate can be based upon this

  How?

Section 6.3., paragraph 1:
>    For TCP, the retransmission timeout is adjusted according to the
>    measured RTT.  However due to the exponential backoff mechanism, the
>    delay associated with retransmission timeouts may increase
>    significantly with increased packet loss.

  And that is a *feature* - it's why Internet congestion control works.
2008-09-25
12 Lars Eggert
[Ballot discuss]
Last Edited Date: 2008-09-25

I refreshed my memory on the previous discussion between transport folks and MIPSHOP, and this is a significant edit …
[Ballot discuss]
Last Edited Date: 2008-09-25

I refreshed my memory on the previous discussion between transport folks and MIPSHOP, and this is a significant edit of my earlier discuss and comment text. The use of both UDP and TCP by MIH is OK, but I'd like to see stronger text that recommends or even requires which protocol should be used for which messages (namely, UDP for ES/CS messages that are guaranteed to be < 512 bytes and TCP for all IS messages).

I also have a discuss-discuss, i.e., a point that I'd like to make sure we've discussed before I clear. It seems that SCTP (esp. partial reliability SCTP) would be the ideal transport for MIH, given that it was designed especially for telephony-like signaling. The document doesn't even mention SCTP as an option. Has the WG considered SCTP and if yes, why wasn't it chosen?
2008-09-24
12 Cullen Jennings
[Ballot discuss]
The document seems to recommend a 24 hour keep alive timer for TCP connections. Most NATs and middle boxes I have seen need …
[Ballot discuss]
The document seems to recommend a 24 hour keep alive timer for TCP connections. Most NATs and middle boxes I have seen need something more like 2 hours, however the underlying OS TCP stacks typically do this without people being aware of it. Could the authors have a look and check the document says what they want. I'm OK with 24 hours if that is what people really meant but it surprises me.
2008-09-24
12 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2008-09-24
12 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-09-24
12 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-09-24
12 Russ Housley [Ballot comment]
David Black did a Gen-ART Review during Last Call.  Please respond to
  the concerns raised in this review.
2008-09-24
12 Russ Housley
[Ballot discuss]
David Black did a Gen-ART Review during Last Call.  I have not seen a
  response to his review.  I am especially concerned …
[Ballot discuss]
David Black did a Gen-ART Review during Last Call.  I have not seen a
  response to his review.  I am especially concerned about two issues
  raised in this review.

  First, Section 6.3 says:
  >
  > The default number of retransmissions is set to 2 and retransmissions
  > are controlled by a timer with a default value of 10s.
  >
  Those values appear to be reasonable.  Please say that they SHOULD
  be used, possibly with some qualification involving network-specific
  characteristics.

  Second, IS messages are the primary source of large messages, and IS
  messages do not have tight latency requirements.  So, David asks if it
  is appropriate to say that TCP SHOULD be used for IS messages.
2008-09-24
12 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-09-24
07 (System) New version available: draft-ietf-mipshop-mstp-solution-07.txt
2008-09-23
12 Magnus Westerlund
[Ballot discuss]
This is a discuss, and it really means discuss with me about what I perceive as an issue. I may very well be …
[Ballot discuss]
This is a discuss, and it really means discuss with me about what I perceive as an issue. I may very well be wrong in my understanding of the issue.

Section 6.3:

  If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.
  An MIH message is retransmitted if its corresponding MIH ACK is not
  received by the generating node within a timeout interval set by the
  MIHF.  This approach does not include an exponential backoff and
  therefore tends to degrade more gracefully than TCP when the packet
  loss rate becomes large, in the sense that the expected delay does
  not increase exponentially.  The number of retransmissions is
  limited, which reduces head-of-line blocking of other MIH messages,
  but this can cause important ES/CS messages to be lost.  The default
  number of retransmissions is set to 2 and retransmissions are
  controlled by a timer with a default value of 10s.  No backoff
  mechanism is specified.

I am deeply worried over this retransmission scheme. The reason is that it will give so poor performance compared to an scheme with exponential back-off, RTT measurements and more reasonably set default timers. Due to the bad performance I think people will change the retransmission number to a higher value and reduce the timer to a much smaller value. In which case the lack of exponetial back-off can have bad effects on the network.

I haven't looked at the MIH layer and what functions it provide. To give good performance I hope there is the following facilities available:
- sequence number for duplication and reordering detection
- possibility to timestamp or at least measure the RTT reasonably

I know to little about your requirement and capability to give really good recommendations. However, instead of reinventing the wheel why not always use TCP? If the MN anyway are going to have a persistent connection with the MoS then there are no extra delay compared to UDP to send TCP. And with the specified retransmission protocol TCP will retranstmitt quicker and more optimized. 

Section 6.4:

6.4.  NAT Traversal

  There are no known issues for NAT traversal when using TCP.  The
  default connection timeout of 24 hours is considered adequate for MIH
  transport purposes.
 
If the TCP connection goes through a NAT box also that is subject to binding loss. However, the timeouots are much more reasonable.
 
    However, issues with NAT traversal using UDP are
  documented in [I-D.ietf-tsvwg-udp-guidelines].  Communication
  failures are experienced when middleboxes destroy the per-flow state
  associated with an application session during periods when the
  application does not exchange any UDP traffic.  Hence, communication
  between the MN and the MoS SHOULD be able to gracefully handle such
  failures and implement mechanisms to re-establish their UDP sessions.
  In addition and in order to avoid such failures, MIH messages MAY be
  sent periodically, similarly to keep-alive messages, to attempt to
  refresh middlebox state.  As [RFC4787] requires a minimum state
  timeout of two minutes or more, MIH messages using UDP as transport
  SHOULD be sent once every two minutes.  Re-registration or Event
  indication messages as defined in [IEEE80221] MAY be used for this
  purpose.
 
If the MN has to send keep-alive messages to keep the binding open for MoS -> MN traffic you are going to have to send a lot of traffic. It is not clear if you have messages that goes in that direction, but if you have having a permanent TCP connection with keep-alives every 15-30 minutes seems much more useful.

I am fumbling in the dark here a bit as I don't understand which usage requirements you have, and how the the deployment model looks and between which nodes you really expect NATs to appear.
2008-09-23
12 Magnus Westerlund
[Ballot comment]
Section 6.
Given the reliability requirements for
  the MIH transport, it is assumed in this discussion that the MIH ACK
  mechanism …
[Ballot comment]
Section 6.
Given the reliability requirements for
  the MIH transport, it is assumed in this discussion that the MIH ACK
  mechanism is to be used in conjunction with UDP, while it is
  preferred to avoid using MIH ACKs with TCP since TCP includes
  acknowledgement and retransmission functionality.
 
  It is normally not the ACK themselves that are the issue with reliability within TCP, it is the retransmissions that build up a sending queue further delaying and also requiring duplication handling.

I assume there is retransmission functionality for non-reliable transports, those really SHOULD NOT be used when sending over reliable transports.


Section 6.1:

  It should be noted that MIH layer fragmentation MUST NOT be used
  together with IP layer fragmentation as specified in [IEEE80221].

From this side it is not clear which should be relied on. Considering NAT traversal and performance implications I think recommending against usage of IP fragmentation is the right one. But that is not knowing which facilities MIH layer fragmentation provides. Can you please clarify this.
2008-09-23
12 Magnus Westerlund
[Ballot discuss]
This is a discuss, and it really means discuss with me about what I perceive as an issue. I may very well be …
[Ballot discuss]
This is a discuss, and it really means discuss with me about what I perceive as an issue. I may very well be wrong in my understanding of the issue.

Section 6.3:

  If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.
  An MIH message is retransmitted if its corresponding MIH ACK is not
  received by the generating node within a timeout interval set by the
  MIHF.  This approach does not include an exponential backoff and
  therefore tends to degrade more gracefully than TCP when the packet
  loss rate becomes large, in the sense that the expected delay does
  not increase exponentially.  The number of retransmissions is
  limited, which reduces head-of-line blocking of other MIH messages,
  but this can cause important ES/CS messages to be lost.  The default
  number of retransmissions is set to 2 and retransmissions are
  controlled by a timer with a default value of 10s.  No backoff
  mechanism is specified.

I am deeply worried over this retransmission scheme. The reason is that it will give so poor performance compared to an scheme with exponential back-off, RTT measurements and more reasonably set default timers. Due to the bad performance I think people will change the retransmission number to a higher value and reduce the timer to a much smaller value.

I haven't looked at the MIH layer and what functions it provide. To give good performance I hope there is the following facilities available:
- sequence number for duplication and reordering detection
- possibility to timestamp or at least measure the RTT reasonably

I know to little about your requirement and capability to give really good recommendations. However, instead of reinventing the wheel why not always use TCP? If the MN anyway are going to have a persistent connection with the MoS then there are no extra delay compared to UDP to send TCP. And with the specified retransmission protocol TCP will retranstmitt quicker and more optimized. 

Section 6.4:

6.4.  NAT Traversal

  There are no known issues for NAT traversal when using TCP.  The
  default connection timeout of 24 hours is considered adequate for MIH
  transport purposes.
 
If the TCP connection goes through a NAT box also that is subject to binding loss. However, the timeouots are much more reasonable.
 
    However, issues with NAT traversal using UDP are
  documented in [I-D.ietf-tsvwg-udp-guidelines].  Communication
  failures are experienced when middleboxes destroy the per-flow state
  associated with an application session during periods when the
  application does not exchange any UDP traffic.  Hence, communication
  between the MN and the MoS SHOULD be able to gracefully handle such
  failures and implement mechanisms to re-establish their UDP sessions.
  In addition and in order to avoid such failures, MIH messages MAY be
  sent periodically, similarly to keep-alive messages, to attempt to
  refresh middlebox state.  As [RFC4787] requires a minimum state
  timeout of two minutes or more, MIH messages using UDP as transport
  SHOULD be sent once every two minutes.  Re-registration or Event
  indication messages as defined in [IEEE80221] MAY be used for this
  purpose.
 
If the MN has to send keep-alive messages to keep the binding open for MoS -> MN traffic you are going to have to send a lot of traffic. It is not clear if you have messages that goes in that direction, but if you have having a permanent TCP connection with keep-alives every 15-30 minutes seems much more useful.
2008-09-23
12 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund
2008-09-23
12 Lars Eggert
[Ballot comment]
Section 6., paragraph 1:
>    Given the reliability requirements for
>    the MIH transport, it is assumed in this discussion that …
[Ballot comment]
Section 6., paragraph 1:
>    Given the reliability requirements for
>    the MIH transport, it is assumed in this discussion that the MIH ACK
>    mechanism is to be used in conjunction with UDP, while it is
>    preferred to avoid using MIH ACKs with TCP since TCP includes
>    acknowledgement and retransmission functionality.

  Given the reliability requirements, shouldn't this text REQUIRE MIH
  ACKs with UDP and say they MUST NOT be used with TCP? (I can't come up
  with a reason to permit anything else.)


Section 6.3., paragraph 2:
>    If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.

  See above, I think your reliability requirements make this a MUST.


Section 6.1., paragraph 5:
>    The use of the PUSH bit can alleviate this problem by triggering
>    transmission of a segment less than the SMSS.

  The PUSH bit is not under the control of an application that uses TCP.
  I believe you mean that the Nagle algorithm (RFC896) should be
  disabled.


Section 6.2., paragraph 3:
>    o  If MIHF knows the RTT, the rate can be based upon this

  How?

Section 6.3., paragraph 1:
>    For TCP, the retransmission timeout is adjusted according to the
>    measured RTT.  However due to the exponential backoff mechanism, the
>    delay associated with retransmission timeouts may increase
>    significantly with increased packet loss.

  And that is a *feature* - it's why Internet congestion control works.
2008-09-23
12 Lars Eggert
[Ballot discuss]
Section 6., paragraph 0:
> 6.  MIH Transport Options

  DISCUSS: I don't quite understand why this document allows both UDP
  and …
[Ballot discuss]
Section 6., paragraph 0:
> 6.  MIH Transport Options

  DISCUSS: I don't quite understand why this document allows both UDP
  and TCP, which adds complexity, when TCP alone seems to be a
  completely adequate transport. Here's why:


Section 6.1., paragraph 4:
>    In terms of dealing with short messages, TCP has the capability to
>    concatenate very short messages in order to reduce the overall
>    bandwidth overhead.  However, this reduced overhead comes at the cost
>    of additional delay to complete an MIH transaction, which may not be
>    acceptable for CS and ES services.

  The only delay with TCP (assuming Nagle is turned off) is the
  connection setup delay, i.e., a delay on the very first MIH exchange.
  Because subsequent exchanges go over an already established
  connection, there is no additional latency.


Section 6.2., paragraph 1:
>    Therefore a burst of either
>    short CS/ES messages or long IS message exchanges (in the case where
>    multiple MIH nodes request information) may lead to network
>    congestion.  While the built-in rate-limiting controls available in
>    TCP may be well suited for dealing with these congestion conditions,
>    this may result in large transmission delays that may be unacceptable
>    for the timely delivery of ES/CS messages.

  TCP backs off if there is packet loss, and yes, performance may
  degrade. But UDP is no magic bullet, either - UDP packets in such
  scenarios are lost in the same way as TCP packet, and delivery over
  UDP is unlikely to be more timely than with TCP.


Section 6.3., paragraph 3:
>    An MIH message is retransmitted if its corresponding MIH ACK is not
>    received by the generating node within a timeout interval set by the
>    MIHF.  This approach does not include an exponential backoff and
>    therefore tends to degrade more gracefully than TCP when the packet
>    loss rate becomes large, in the sense that the expected delay does
>    not increase exponentially.  The number of retransmissions is
>    limited, which reduces head-of-line blocking of other MIH messages,
>    but this can cause important ES/CS messages to be lost.  The default
>    number of retransmissions is set to 2 and retransmissions are
>    controlled by a timer with a default value of 10s.  No backoff
>    mechanism is specified.

  I don't buy this. If you wait 10s before the first retransmit and then
  try another one after 20s, TCP will have long retransmitted the lost
  packets, because its RTO is based on the RTT, which is typically much
  less than 10s. UDP will only be faster if much more aggressive timers
  are used here, which is problematic.
2008-09-23
12 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2008-09-18
12 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2008-09-18
12 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Patrick Cain.
2008-09-18
12 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-09-17
12 Amanda Baber
IANA Last Call comments:

Upon approval of this document, the IANA understands that it
must complete a single action.

IANA will assign a port number …
IANA Last Call comments:

Upon approval of this document, the IANA understands that it
must complete a single action.

IANA will assign a port number from the registered port range
for the following UDP and TCP ports:

Port
Short Name Decimal Description
-------- --------------- ------------
ieee-mih TBD/tcp MIH Services
ieee-mih TBD/udp MIH Services

IANA understands that this is the only action required upon
approval of this document.
2008-09-05
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Patrick Cain
2008-09-05
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Patrick Cain
2008-09-04
12 Amy Vezza Last call sent
2008-09-04
12 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-09-04
12 Jari Arkko placed on agenda
2008-09-04
12 Jari Arkko Placed on agenda for telechat - 2008-09-25 by Jari Arkko
2008-09-04
12 Jari Arkko State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko
2008-09-04
12 Jari Arkko Last Call was requested by Jari Arkko
2008-09-04
12 Jari Arkko Ballot has been issued by Jari Arkko
2008-09-04
12 Jari Arkko Thanks for the new version. I have looked at it and the previous AD review, and I'm in general satisfied with the result.
2008-09-04
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-09-04
06 (System) New version available: draft-ietf-mipshop-mstp-solution-06.txt
2008-07-31
12 Amanda Baber
IANA Evaluation comments:

IESG NOTE: Expert Review Required

Upon approval of this document, the IANA will make the following
assignments in the "PORT NUMBERS" registry …
IANA Evaluation comments:

IESG NOTE: Expert Review Required

Upon approval of this document, the IANA will make the following
assignments in the "PORT NUMBERS" registry at
http://www.iana.org/assignments/port-numbers
sub-registry "REGISTERED PORT NUMBERS"

Keyword Decimal Description References
------- ------- ----------- ----------
ieee-mih-IS TBD_BY_IANA/tcp MIH Information Services
[RFC-mipshop-mstp-solution-05]
ieee-mih-IS TBD_BY_IANA/udp MIH Information Services
[RFC-mipshop-mstp-solution-05]
ieee-mih-ES TBD_BY_IANA/tcp MIH Event Services
[RFC-mipshop-mstp-solution-05]
ieee-mih-ES TBD_BY_IANA/udp MIH Event Services
[RFC-mipshop-mstp-solution-05]
ieee-mih-CS TBD_BY_IANA/tcp MIH Command Services
[RFC-mipshop-mstp-solution-05]
ieee-mih-CS TBD_BY_IANA/udp MIH Command Services
[RFC-mipshop-mstp-solution-05]

We understand the above to be the only IANA Action for this
document.
2008-07-11
12 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2008-07-11
12 Jari Arkko Ballot has been issued by Jari Arkko
2008-07-11
12 Jari Arkko Created "Approve" ballot
2008-07-11
12 (System) Ballot writeup text was added
2008-07-11
12 (System) Last call text was added
2008-07-11
12 (System) Ballot approval text was added
2008-07-11
12 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko
2008-07-11
12 Jari Arkko Few relatively minor issues remaining from Gorry's and AD reviews.
2008-07-10
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-07-10
05 (System) New version available: draft-ietf-mipshop-mstp-solution-05.txt
2008-05-19
12 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko
2008-05-19
12 Jari Arkko
I have made my AD review of this document. Please find details below. Overall, there were a few important missing or underspecified parts relating to …
I have made my AD review of this document. Please find details below. Overall, there were a few important missing or underspecified parts relating to parameters and algorithms for using UDP, discovery via another MoS, NAT-traversal retransmissions, and authorization. These should be specified. The security mechanisms should be narrowed down to a more reasonable set.

But the big question for me was whether it is appropriate to employ DHCP-AAA binding so that per-MN information can be provided. I realize that we have done it once in the context of the Mobile IP bootstrapping work. But frankly, that sets a very high bar for deployment in a given access network and introduces dependencies and complexity that is undesirable. In general, if every application that wants to avoid configuration needs to have special support in DHCP relays, it becomes very hard to deploy anything new. My read of RFC 5164 does not say that the AAA binding is required. My question is whether (a) local MIH services, (b) configured home network name and DNS, (c) local MIH IS + redirection to home MIH, (d) other Internet service discovery mechanisms would be sufficient or preferable. At the very least, we should consider publishing the simple solution first, and only if there's actual evidence of deployments with more complex requirements, consider extending it.

Process:

Given the extensive use of DHCP in this document, we need to engage the DHC WG in a discussion of this draft. I would also like to see a transport directorate review. Both to be done after a revision addressing my own comments has been submitted, however.

Technical:

>    DHCP  Dynamic Host Configuration Protocol: a protocol described in
>      [RFC2131] that allows Internet devices to obtain IP addresses,
>      subnet masks, default gateway addresses, and other IP
>      configuration information from DHCP servers.

IPv6 needs to be covered as well. Please add the appropriate reference.

>    Different types of MoS can be provided independently of other types
>    and there is no strict relationship between ES, CS and IS, nor is
>    there a requirement that the entities that provide these services
>    should be co-located.  However, while IS tends to involve a large
>    amounts of static information, ES and CS are dynamic services and
>    some relationships between them can be expected, e.g., a handover
>    command (CS) could be issued upon reception of a link event (ES).
>    Hence, while in theory MoS can be implemented in different locations,
>    it is expected that ES and CS will be co-located, whereas IS can be
>    co-located with ES/CS or located elsewhere.  Therefore, having the
>    flexibility at the MSTP to discover different services in different
>    locations is an important feature that can be used to optimize
>    handover performance.  MoS discovery is discussed in more detail in
>    Section 5.
Is there a need to state that ES/CS is more likely to be associated with a visited network than home?

>    The configuration of the MoS could be executed either upon network
>    attachment or after successful IP configuration.  The methodology to
>    be used depends on the considered deployment scenario.
First, there's a problem here with what kind of network attachment we are talking about. I believe mobility services need to be provided from the access network in many situations. IP layer configuration is somewhat independent of the link layer attachments, given things like bridging, access concentrators, tunneling, proxy MIP and so on. Given this, I think the above needs to say that discovery happens upon initial or changed link layer attachment.

Secondly, the part about IP configuration needs to talk about changed IP  configuration as well.  If your DHCP lease expires, and you get a new address, will you redo discovery? What if you generate a new 3041 address? If the prefixes in the RAs change without the routers themselves being changed? What if you do DNAv4 or v6 and detect a network change?

Thirdly, I do not think it is appropriate to leave this entirely to deployments. At least for the mobile node side, code needs to be written and every host needs to be able to behave in the correct manner.

In conclusion, this text needs to be written in a much more detailed and specification-like manner. It may be that subsequent sections contain at least some of these details. If so, forward references would be needed.

>    In the case where MoS is provided locally (scenarios S1 and S2) , the
>    discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options]
>    and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable and
>    either one MAY be used to discover the MoS.

Dns-discovery requires starting from a known domain name, which seems to exclude using it for local networks. Other than as a follow-up to other methods, like DHCP.

>    In the case where MoS is provided in the home network while the MN is
>    in the visited network (scenario S3), the DNS based discovery
>    described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable,
>    while the DHCP based discovery method would require an interaction
>    between the DHCP and the AAA infrastructure, similarly to what is
>    specified in [I-D.ietf-mip6-bootstrapping-integrated-dhc] .  This
>    latter case assumes that MoS assignment is performed during access
>    authentication and authorization.
I would like to see this simply state that DHCP based discovery in such a scenario is inappropriate for the given reasons. I do not believe it is beneficial to start bundling DHCP with other parts of the network, except where absolutely required.
>    It should be noted that authorization of a MN to use a specific MoS
>    server is not in scope of this document and is specified in
>    [IEEE80221] .
This needs expansion. How does the IEEE scheme affect the transport protocol? Can we end up in a situation where DHCP discovery delivers a server address which refuses to talk to us, for instance?

> In order to use that
> mechanism, the MN MUST first find out the domain name of its home
> network.  Home domains are usually pre-configured in the MNs (i.e.
> subscription is tied to a network), thus the MN can simply read its
> configuration data to find out the home domain name (scenario S1).
This is formulated in a peculiar way. Wouldn't it be simpler to just say that MNs must be configured with the domain name of their home network?

> Alternatively, the MN
> MAY use the DHCP options for MoS
> discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown inFigure 6b.
Again, binding the DHCP process with AAA, knowledge of particular node's home network etc is undesirable. Can we remove this from the draft?

>    DHCP --  In order to find out the domain name of the local network,
>      the MN SHOULD use the dhcpv4 option 15 for learning the domain
>      name [RFC2132].  A similar solution is available for dhcpv6
>      [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] .
The draft is expired. I would suggest re-considering whether this approach (dchp + dns) is necessary.

>    Reverse dns query --  When DHCP does not provide the required domain
>      name, the MN MAY use reverse DNS (DNS PTR record) to find the
>      domain name associated with the IP address it is using in the
>      visited network.  Note, that when a NAT device exists between the
>      MN and the visited network, the MN will first need to find out the
>      external IP address of the NAT device.  Some possible methods for
>      determining the NAT's external IP address are STUN [RFC3849] or
>      UPnP [UPnP_IDG_DCP].  Once the MN has determined the external IP
>      address of the NAT device, it MUST use that address in the reverse
>      DNS query.
A lot of complexity. I wonder if this is really needed. Anyone who is willing to deploy a relatively costly service such as the MIS on their network, why would they not be willing to add a few DHCP options to their network as well? Note that you do not need to use DHCP in IPv6 to acquire such options; stateless DHCP would also do fine, and can be combined with autoconfig addresses.

>    When the discovery of an MoS at the visited network, using the FQDN
>    returned in the reverse DNS query, is not successful, the MN MAY
>    attempt to remove portions from the left side of the FQDN and attempt
>    discovery again.  The process MAY be repeated iteratively until a
>    successful discovery.
As in eventually asking for mobility services from .com, for instance? I think you need text to avoid this from happening.

>    This section assumes the use of IPv6 and DHCPv6 based mechanisms to
>    discover MoS services in home while the MN is in visited network.  If
>    similar functionalities are desired for IPv4 additional DHCPv4
>    extensions would be required.  Since use cases requiring these
>    extensions were not identified at the time of writing this document,
>    they were excluded from the scope of the document.

I am surprised by this. Generally speaking, I would expect to see feature parity for IPv4 and IPv6 in specifications like this.

>    To discover an MoS in a remote network other than home network, the
>    MN MUST use the DNS based MoS discovery method described in
>    [I-D.ietf-mipshop-mos-dns-discovery].  The MN MUST first learn the
>    domain name of the network containing the MoS it is searching for.
>    If the MN does not yet know the domain name of the network, learning
>    it may require more than one operation, as DHCP based discovery can
>    not be used and pre-configuration is not a feasible solution in case
>    of an arbitrary remote network.  The MN MAY attempt to first discover
>    an MoS in either the local or home network (as in Figure 9 part (a))
>    and query that MoS to find out the domain name of a specific network
>    or the domain name of a network at a specific location (as in
>    Figure 9 part (b)).  Alternatively, the MN MAY query an MoS
>    previously known to learn the domain name of the desired network
>    (e.g., via an IS Query).  Finally, the MN MUST use DNS queries to
>    find MoS in the remote network as inFigure 9 part(c).  It should be
>    noted that step c can only be performed upon obtaining the domain
>    name of the remote network.
The part about finding more information from MoS to redirect the mobile node to a third party is vague. Can this document point to specific attributes defined in IEEE that would carry such information? Otherwise this cannot be implemented.

Also, its not clear why "pre-configuration is not a feasible solution in case of an arbitrary remote network". Surely its no harder to configure a given 3rd party network than a given home network. I agree that pre-configuration should be avoided if possible, though.

> while it is preferred to avoid using MIH ACKs with TCP
>    since TCP includes acknowledgement and retransmission functionality.
Is there no need for application level confirmation? TCP ACKs will only tell you that the message got through, not, for instance, that it can be obeyed.

> On the other hand, if UDP
> is used, a rate-limiting effect similar to the one obtained with TCP
> may be obtained by adequately adjusting the parameters of a token
> bucket regulator as defined in the MIH specifications [IEEE80221].
> Recommendations for tocken bucket parameter settings are specific to
> the scenario considered.
The parameters and algorithms governing the use and timing of UDP need to be specified. Its fine to point to an IEEE spec, but it needs to be clear that they are mandatory. From the above I cannot determine what an implementation needs to do.
> As [RFC4787] requires a minimum state timeout of two
> minutes or more, MIH messages using UDP as transport SHOULD be sent
> once every two minutes.

This is too vague. Sent when? If you have an implementation capable of using MIH? When you have something to send, you keep sending it over and over again? When you have something to receive you keep sending something else? How do you know when you have something to receive, or when you want to receive something?

Note that it would be very unfortunate if every host in every network that had turned MIH on would be sending a packet every 2 mins.

> MIH messages sent over UDP, TCP or other supported
>    transport MUST use the default port number defined for that
>    particular transport.
Where are these specified?

> MIH Transport Options
The document is very silent on how MIH messages are carried on a given transport protocol. At the very least the draft should indicate that no extra framing is needed because IEEE specs already contain a length field.

> MIH Transport Options

The document does not talk about how servers know the capabilities of clients that send event/command services to. Is this a part of the IEEE definitions, and you subscribe to a particular event stream? In any case, the document should talk about this and point to the relevant other specifications where needed.

>    In the case where DHCP is used for node discovery and authentication
>    of the source and content of DHCP messages is required, network
>    administrators SHOULD use DHCP authentication option described in
>    [RFC3118], where available or rely upon link layer security.  This
>    will also protect the DHCP server against denial of service attacks
>    to.  [RFC3118] provides mechanisms for both entity authentication and
>    message authentication.

I think the overall recommendation is good, but practically no one is going to deploy RFC 3118. With this in mind, I would like to see the above paragraph explain in more detail the security implications of relying on link layer security.

>    In the case where reliable transport protocol such as TCP is used for
>    transport connection between two MIHF peers, TLS [RFC4346] SHOULD be
>    used for message confidentiality and data integrity.  In particular,
>    TLS is designed for client/server applications and to prevent
>    eavesdropping, tampering, or message forgery.  Readers should also
>    follow the recommendations in [RFC4366] that provides generic
>    extension mechanisms for the TLS protocol suitable for wireless
>    environments.
>
>    In the case where unreliable transport protocol such as UDP is used
>    for transport connection between two MIHF peers, DTLS [RFC4347]
>    SHOULD be used for message confidentiality and data integrity.  The
>    DTLS protocol is based on the Transport Layer Security (TLS) protocol
>    and provides equivalent security guarantees.
>
>    Alternatively, generic IP layer security, such as IPSec [RFC4301] MAY
>    be used where neither transport layer security for a specific
>    transport is available nor server only authentication is required.
Too many options. I do not see a particular requirement for IPsec here, why do we need to include it?

Also, are TLS and DTLS mandatory to implement?

Editorial:

Acronyms used before defined. At least for MSTP (!) and MIHF, maybe others. Expand them on first use, if this happens prior to the terms section.

Most entries in Section 2 need to point to the relevant RFC or other specification that defines them. E.g., NAI or ES.

Fix these idnits issues:

  == Unused Reference: 'I-D.ietf-dime-mip6-integrated' is defined on line
    1066, but no explicit reference was found in the text

  -- Unexpected draft version: The latest known version of
    draft-ietf-mip6-bootstrapping-integrated-dhc is -hc, but you're referring
    to -06.


> Since transporting long MIH messages may require
>    fragmentation that is not available in UDP, ...
This needs to be reformulated. UDP itself has no fragmentation support, but IP does. But the issue is that IP layer fragmentation may not work well, particularly for large packets, may cause several other issues, etc.

> TCP client
I believe it would be more appropriate to talk about the "MSTP client" or "MIH client" or "MSTP TCP client"; TCP does not operate on its own. Or, maybe you can merge "TCP client" and "MIHF" in Figure 10.

(Appears in multiple places in the document, as does the corresponding UDP term)
>    and responses may cause DoS and the inability of the MN to perform a
Acronym "DoS" not introduced earlier.
2008-05-18
12 Jari Arkko State Changes to AD Evaluation from Publication Requested by Jari Arkko
2008-05-18
12 Jari Arkko Intended Status has been changed to Proposed Standard from None
2008-05-15
12 Cindy Morgan
  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the …
  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Vijay Devarapalli is the Document Shepherd for this document. I
have reviewed the document and it is ready for forwarding to the
IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document has been reviewed by numerous folks, including folks
who are proficient in IP Mobility and Security and folks who are
active in the IEEE 802.21 WG. I have no concerns about the depth
or breadth of the reviews that have been performed.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

None.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No specific concerns.

The MIPSHOP WG received numerous liaison statements from the
IEEE 802.21 WG supporting this work. The solution described in
the document is supposed to provide a Layer 3 protocol for
transport of the handover assist information. The IEEE 802.21
WG also provided the requirements for the solution.

An IPR was disclosed regarding this document. Please see
https://datatracker.ietf.org/ipr/932/. This was posted on the
MIPSHOP WG mailing list. There was no objection to progress the
document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is WG consensus in advancing this document.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document meets all the requirements. There were three minor
nits. 1) One line that is longer than 72 characters 2) An unused
reference 3) Reference to a wrong version of
draft-ietf-mip6-bootstrapping-integrated-dhc. I believe these are
minor nits that can be fixed in the next version of the document.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits the references into normative and
informative references. The document has normative
dependencies on draft-ietf-mipshop-mos-dns-discovery and
draft-ietf-mipshop-mos-dhcp-options. These documents will also
be sent to the IESG soon. Note that these extensions are not
necessary for someone to understand the solution framework
described in the document.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA considerations section exists and is consistent with
the body of the document.  The document requests reservations in
the appropriate IANA registries. The IANA registries that need to
be modified/created are clearly identified.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Does not apply.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

This document describes a solution for discovering IEEE 802.21
Media Independent Handover (MIH) servers (called the MoS server)
and a transport layer mechanism for the reliable delivery of MIH
messages.

          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

None.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

There are no known implementations or vendor plans to implement
the specification.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko/Mark Townsley
2008-05-15
12 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-05-11
04 (System) New version available: draft-ietf-mipshop-mstp-solution-04.txt
2008-04-28
03 (System) New version available: draft-ietf-mipshop-mstp-solution-03.txt
2008-04-17
02 (System) New version available: draft-ietf-mipshop-mstp-solution-02.txt
2008-02-29
(System) Posted related IPR disclosure: InterDigital Technology Corporation's Statement about IPR related to draft-ietf-mipshop-mstp-solution-01
2008-02-12
01 (System) New version available: draft-ietf-mipshop-mstp-solution-01.txt
2007-12-17
00 (System) New version available: draft-ietf-mipshop-mstp-solution-00.txt