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

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Dec 2009 15:22:30 +0200

Romascanu, Dan (Dan) wrote:
> 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. 
>   

I felt your issues were of more technical nature, first we had to find 
out if the whole thing makes sense.

I'm pretty sure we can do at least something to solve your issues. Its 
not clear that a perfect answer exists. But for starters, we talked 
about not-free-for-all model but something which can be allocated 
through the IETF. I'm not quite sure what the working group felt at the 
time, does this completely exclude the vendor specific extensions that 
are in the current version? If yes, Dan's issues are trivially resolved. 
If not, we may need to come up with some additional mechanisms.

Jari

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Dec 2009 14:24:38 +0100

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, December 02, 2009 3:23 PM
> To: Romascanu, Dan (Dan)
> Cc: Ralph Droms; Cullen Jennings; Lars Eggert; Robert Sparks; 
> [email-masked]; 
> Mobile IPv4 Mailing List; IESG
> Subject: Re: coming back to 
> draft-ietf-mip4-generic-notification-message
> 
> > 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.
> >   
> 
> I felt your issues were of more technical nature, first we 
> had to find out if the whole thing makes sense.
> 
> I'm pretty sure we can do at least something to solve your 
> issues. Its not clear that a perfect answer exists. But for 
> starters, we talked about not-free-for-all model but 
> something which can be allocated through the IETF. I'm not 
> quite sure what the working group felt at the time, does this 
> completely exclude the vendor specific extensions that are in 
> the current version? If yes, Dan's issues are trivially resolved. 

I agree. 

Dan

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Dec 2009 16:30:07 +0200

I've heard from Cullen, Lars, and Dan -- what about you Ralph and Robert?

AFAICT, we are waiting for the following to happen:

- get some indication from the remaining ADs that this approach is 
acceptable
- get an answer to my question about whether vendor-specific is still in 
the picture
- possibly get the WG provide an answer to Dan (depending on the outcome 
of the above)
- new draft version

Jari

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.
>
> 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
>
> -- 
> Mip4 mailing list: [email-masked]
> Web interface: https://www.ietf.org/mailman/listinfo/mip4
> Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 2 Dec 2009 16:18:40 -0600

It could  move towards resolving my concern - the stricter iana  
requirements section could also provide guidance to whatever entity  
was responsible for providing review
that essentially achieves what I was looking for (copied here from the  
discuss for convenience):

> Some additional treatment either adding mechanics for agreeing on  
> semantics, the
> creation  of a very limited scope
> for those semantics that would make those
> mechanics unnecessary, and/or additional motivation and discussion of
> architectural impact is needed.

RjS

On Dec 2, 2009, at 8:30 AM, Jari Arkko wrote:

> - get an answer to my question about whether vendor-specific is  
> still in the picture
> - possibly get the WG provide an answer to Dan (depending on the  
> outcome of the above)
> - new draft version
>
> Jari
>
> Jari Arkko wrote:
>> 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:
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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

---

From: Hui Deng <[email-masked]>
Date: Wed, 9 Dec 2009 23:53:19 +0800

Hi, Dan,

I guess that my replied email has been lost on 20090910, so resend here
> Discuss:
> 1. I do not believe that the way Vendor/Organization specific extensions are currently defined allow for any level of interoperability or are for any use in a multi-vendor deployment. Even for mobile nodes and agents belonging to the same vendor, how do these recognize each other and the level of vendor extenstions that they support? It looks like this needs some more wor to design capability advertising and/or negotiation mechanism.
==>Vendor/Org-ID and Vendor-CVSE-Type could help interoperability and
identify itself.
I could add wording to say expliain these, it has been updated in -12.
"Vendor/Org-ID and Vendor-CVSE-T defined in vendor specific extensions
could help to identify itself, if the receiver don't understand this,
this extensions could be just silently discarded."

> 2. If Generic String Extensions MUST be strictly defined as mentioned in section 5.1 should not an IANA register for these extensions be created together with the subtype field registries defined in Section 6?
==> Section 6 has been updatd to mention this subtype IANA register.

>
> 3. The specification is completely mute about the management aspects of the notifications capability. At a minimum I would expect that nodes and agennts expose a list of the supported notifications be accessible to operators via some management interface, that there would be switches to enable / disable notifications, and the capability to tune timers of retransmission.
==> added as you recommended.
"This document recommends that the HA, FA, and MN should expose a list
of the supported notifications be accessible to operators via some
management interface, that there would be switches to enable / disable
notifications,  and the capability to tune timers of retransmission."

thanks for your discusion

-Hui