Subject: [Mip4] coming back to draft-ietf-mip4-generic-notification-message

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Nov 2009 13:44:18 +0200

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.

Jari

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 23 Nov 2009 12:16:11 +0100

Jari,

Although I share to a certain degree the broader concerns expressed by
other AD's the issues raised in my DISCUSS are more specific. I do not
see them addressed in your response, so I am still expecting a response,
or revised I-D for these to be addressed - of course assuming that this
work continues. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Friday, November 20, 2009 1:44 PM
> To: Ralph Droms; Cullen Jennings; Lars Eggert; Romascanu, Dan 
> (Dan); Robert Sparks
> Cc: 
> [email-masked]; 
> Mobile IPv4 Mailing List; IESG
> Subject: coming back to draft-ietf-mip4-generic-notification-message
> 
> 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. 
> 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 
> There are no minutes from the session yet, but audio 
> recordings can be found here: 

Jari

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Nov 2009 09:51:16 -0700

sounds like a path that would resolve my issues. Would the WG also make sure that the draft documents what sort of extensions are appropriate and what sort are not?

On Nov 20, 2009, at 4:44 AM, Jari Arkko wrote:

> 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.
> 
> 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.
> 
> Jari
>