Subject: [Mip4] status of draft-ietf-mip4-generic-notification-message

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Apr 2010 14:50:26 +0300

I have looked at the new draft and the discussions we had. The draft
and changes since the IESG review are visible here:

http://tools.ietf.org/html/draft-ietf-mip4-generic-notification-message-14

http://www.arkko.com/ietf/mip4/draft-ietf-mip4-generic-notification-message-14-from-1.diff.html

I have a number of comments, however, and they need to be resolved
before moving forward. In short we're on the right path but not done
yet:

The messages defined in this
document are capable of carrying the same extensions that have been
defined for the existing Mobile IPv4 messages. However, this
document requires for now that only the following extensions be
present in the new messages defined herein:

- MN-HA Authentication Extension

- MN-FA Authentication Extension

- FA-HA Authentication Extension

- Generic String Extension

This seems a bit special. I would simply say: "Only the following
extensions can be present in these new messages: ..." The discussion
about capable vs. for now is confusing.

For now, the semantics of receiving a generic notification message
are null; i.e., it has no effect on the state of a mobile node's
existing registration.

In some case, the HA or FA needs to notify the MN about service
termination due to the end of prepaid time, or service interruption
due to system maintenance. This information could be defined based
on a string [RFC4917] which is easily recognized by the MN. An
example would be "Maintenance Downtime", "Prepaid Expiration". On
the other hand, the MN may need to notify the network about events
related to a service such as a location change event, or a usage-
preference change event. This information could be defined based on
a string [RFC4917]. An example would be "Location Change" or
"Service Event". These strings MUST be strictly defined so they
could be easily understood by all of the network entities, and a
suitable GNM Subtype number would have to be allocated. All such
definitions are left for future specifications.

But there is no such subtype anymore.

More importantly, RFC 4917 allows free format strings, and I don't know
how to define "easily recognized" strings without a danger of
collisions, at least not without implementing some kind of IANA
registry of subtypes or a reserved prefix for special RFC 4917 strings.

(RFC 4917) Text:

The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect the operation of the protocol.

Proposed usage in generic-notification-message seems to go against the
MUST NOT. At the very least generic-notification-message should explain
the situation and have an "Updates: RFC 4917" header at the top.

For now, none of these above future semantics are supported except
that the Generic String Extension is supported for informational
purposes. There should be minimum requirements given here for adding
additional extension types to the allowed set and defining their
semantics.

OK. Where are such minimum requirements?

There are several applications that could use this GNM. For example,
during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP
resource on the CDMA side has to be removed on the FA (PDSN) to avoid
over-charging subscribers, anyway existing Registration Revocation
RFC [RFC3543] is a one way to do this.

Not a very convincing use case! Rewrite to say directly that for
registration revocation this new generic model is not needed.

Other applications such as HA
switch over(before HA decide to go offline it would like to notify
the MNs to register with another candidate HA), NEMO prefix
changes(MN is notified by HA about NEMO prefix changes and service or
billing related events, which is an operational requirement), Load
balancing(HA wants to move some of the registered MNs to other HAs),
Service Termination(due to end of prepaid time), and Service
Interruption(due to system maintenance).

Something wrong with the sentence (editorial).

There are several applications that could use this GNM. For example,
during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP
resource on the CDMA side has to be removed on the FA (PDSN) to avoid
over-charging subscribers, anyway existing Registration Revocation
RFC [RFC3543] is a one way to do this. Other applications such as HA
switch over(before HA decide to go offline it would like to notify
the MNs to register with another candidate HA), NEMO prefix
changes(MN is notified by HA about NEMO prefix changes and service or
billing related events, which is an operational requirement), Load
balancing(HA wants to move some of the registered MNs to other HAs),
Service Termination(due to end of prepaid time), and Service
Interruption(due to system maintenance).

I do not understand why we have this text in Section 5 when there is
Section 3 that is supposed to describe the use cases. But FWIW, I found
the above explanation far more useful than Section 3... maybe it should
go away.

Jari

Jari Arkko wrote earlier:

Lars, Cullen, Robert, Ralph, Dan, and other ADs
who had critical comments on this draft,

We discussed the situation in the MIP4 WG meeting in Hiroshima. Only
Lars and me were in the meeting. Here's what we uncovered.

As you may recall, the basic issue was threefold: whether there's an
actual need to have this extension, why we need a generic mechanism as
opposed to building specific protocol extensions when we need them, and
whether we are opening the protocol for "free for all" extensions. The
working group meeting gave us the following answers:

On the need: First, Henrik expressed a desire that one previously
designed extension would have been designed on top of this framework
rather than designed as a standalone mechanism. But obviously the train
has left the station for that. Regarding future extensions, there is
one use case in 3GPP2 specifications which builds on the proposed
generic mechanism. In addition, Kent gave us a couple of examples of
what we might want to do in the future. The first example involves the
home agent updating the mobile router's assigned prefix. The second
example was host configuration changes (e.g., DNS or other server
address changes) where the home agent would again wish to inform the
mobile node. The room felt that these examples were potentially good
uses cases for the extension.

On the use of generic vs. standalone extensions: In general, all of
these extensions CAN be designed as standalone, but the working group
felt that it would be better to use a uniform design for all
notifications in the ha->mn direction. To ensure that every
extension does not implement the same thing in a different way. Even if
the generic protocol itself is very minimal, basically just a new
container. The ha->mn direction for notification is not something
that the Mobile IPv4 protocol has traditionally supported.

Free for all concern: The working group noted that there already exists
vendor-specific extension mechanisms, and that the purpose of this
extension is not to open the protocol for new extensions outside the
IETF. Those extensions can already be done.

At the end of the meeting, we proposed the following way forward.
First, we wanted to convey the use cases and rationale to the IESG.
Second, we would like to change the specification so that it requires a
stricter IANA allocation policy. Specification required, RFC required,
or something along those lines before a code point can be allocated on
top of the generic notification service.

Does this way forward help resolve your concerns about this extension?

There are no minutes from the session yet, but audio recordings can be
found here: ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch5-tue-afnoon.mp3
and the discussion starts around 25min from the beginning.