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

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 13 Jan 2010 18:26:01 -0500

I do not think we have adequately addressed all the issues that
have been raised with respect to this document.

Dan has asked for some negotiation mechanism to facilitate
interoperability when using vendor-specific extensions.
Note that the VSEs defined in RFC 3115 can take two forms:
Critical and Normal.  The semantics of a Critical VSE
are to discard the containing message if you don't understand
the extension.  The semantics of a Normal VSE is to skip it,
but otherwise process the message.  Dan, is this functionality
enough to address your concern about interoperability?

If not, perhaps we need to consider removing vendor-specific
extensions from this draft.  It does seem that having the
semantics of the message (e.g., whether to terminate the
registration or take some other action) depend on the contents
of a VSE is problematic.  Should we say instead that for
now, we only support a semantic-free string extension as
defined in RFC 4917, and that any additional semantics
will be defined in standards-track documents?

One thing popped out at me while re-reviewing the draft: it 
isn't clear why we need to use the Subtype field in the
message header to indicate the extension types.  Extensions
have their own self-describing format.  I don't think the
changes that have been made to the IANA considerations are
correct.  We should just reference RFC 3115 and RFC 4917
more prominently.

I believe that the operational concerns Dan mentions deserve
a fuller exploration and treatment in the draft.

-Pete

Hui Deng wrote:
> 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
> 2009/12/2 Romascanu, Dan (Dan) <[email-masked]>:
>> 
>> 
>>> -----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
>>> 
>>> 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
>>> 
>>> 
>> 
>> I agree.
>> 
>> Dan
>> --
>> 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: Jari Arkko <[email-masked]>
Date: Mon, 18 Jan 2010 12:40:01 +0200

Ok. Clearly we need at least another spin of the document. Can you Hui 
or the other authors do it, so that we can move forward?

Jari

---

From: Hui Deng <[email-masked]>
Date: Mon, 18 Jan 2010 20:21:42 +0800

please allow me 1 or 2 days, I will try to do it
sorry for taking long time

-Hui

2010/1/18 Jari Arkko <[email-masked]>:
> Ok. Clearly we need at least another spin of the document. Can you Hui or
> the other authors do it, so that we can move forward?
>
> Jari
>
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Jan 2010 14:26:21 +0200

Hui,

> please allow me 1 or 2 days, I will try to do it

No problem. Take your time, its more important to get it right than to 
get a draft out tomorrow :-) Talk to Pete about the difficult issues so 
that we can solve everything.

Jari

---

From: Hui Deng <[email-masked]>
Date: Wed, 20 Jan 2010 00:15:23 +0800

Ok, I will talk with Peter about those issues,

thanks again

-Hui

2010/1/18 Jari Arkko <[email-masked]>:
> No problem. Take your time, its more important to get it right than to get a
> draft out tomorrow :-) Talk to Pete about the difficult issues so that we
> can solve everything.
>
> Jari
>
>

---

From: Hui Deng <[email-masked]>
Date: Mon, 25 Jan 2010 23:10:58 +0800

Hi Peter,

Thanks for your suggestion to the draft, do you think that we should
wait for Dan's reply
or just follow your suggestion about remove vendor specific extention?

For subtype, I am fine to remove it,

thanks for your advice.

-Hui

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 25 Jan 2010 14:04:33 -0500

Hi, Hui,

If you remove the Subtype field I think most mentions of VSEs would
go away.

Maybe we should re-word the second paragraph of the Introduction to
something like the following:

   This document defines a generic message that can be used by Mobile
IPv4 
   entities to send various notifications.  It also defines a
corresponding
   acknowledgement message to allow for reliable delivery of
notifications.
   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

   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.
   Future documents may specify additional extension types that may
   be used in a generic notification message and their semantics.

Section 5 also likely needs to be modified.  I'm not sure the
title "Usage Example" is quite right.  Maybe, "Future Extensibility".
The text that talks about removing a PPP resource should make a
reference to the existing Registration Revocation RFC as one way
to do this.  Another paragraph should state that for now, none of
these future semantics are supported and only 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; we may want
to go with "Standards Action" or "Specification Required."

I also note that the 4 descriptions of the IP/UDP header fields
in section 4.1 are identical.  I think this is a bug and needs
to be fixed.

Please move the Acknowledgements section after the Security 
Considerations.

-Pete

Hui Deng wrote:
> wait for Dan's reply or just follow your suggestion about remove
> vendor specific extention?  
> 
>>> No problem. Take your time, its more important to get it right than
>>> to get a draft out tomorrow :-) Talk to Pete about the difficult
>>> issues so that we can solve everything.
>>> 
>>> Jari

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 26 Jan 2010 12:16:16 -0500

Hi, Hui,

A couple of issues:

I think there are still problems with the descriptions of 
the IP/UDP fields in Section 4.1.  For example, the first
one is:

     Source Address         Typically copied from the destination
                            address of the last Registration Reply/
                            Request message to which the agent is
                            sending.

Should this say, "...the last Registration Reply/Request message
that the agent received from the agent to which it is sending the GNM" ?
Similar problems with the other fields.

In Section 5, you took me too literally and added this text:

   There should be minimum requirements given here for adding additional
   extension types to the allowed set and defining their semantics; we
   may want to go with "Standards Action" or "Specification Required."

I meant to say that we should pick one of these and add appropriate
text.  I am not sure which one is best.  Any opinions?

I think we should take the currently last paragraph of the Introduction
that talks about operational issues and move it to this Section 5.  It
needs to be re-worded a bit so that it reads as a requirement on implementations,
e.g.,

   The HA, FA, and MN SHOULD expose a list of the supported notifications
   to operators via some management interface, and there SHOULD be switches
   to enable / disable individual types of notifications and to tune the
   retransmission timers for each type.

At this point, I am not sure we have adequately addressed the criticism
that we received about the lack of motivation for the new messages.  Perhaps
we need some additional discussion in Section 5 about the possible use cases.
And I think the Introduction should point to Section 5, with something like
this added to the (currently 2nd-to-last) paragraph:

   See Section 5 for some prospective application examples that motivate the
   new messages defined in this document.

-Pete

Hui Deng wrote:
> Hi Peter,
> 
> I did the update based on your suggestion with the enclosed draft,
> mip4 mailing list may not get it.
> 1) Update the introduction section
> 2) Removed VSE everywhere
> 3) Update the future extensibility section
> 4) Update the section 4.1 description
> 
> thanks for your review again
> Best regards,
> 
> -Hui
> 
> 2010/1/26 McCann Peter-A001034 <[email-masked]>:
>> Hi, Hui,
>> 
>> IPv4   entities to send various notifications.  It also defines a
>> corresponding   acknowledgement message to allow for reliable
>> delivery of notifications.   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: 
>> 
>> are null;   i.e., it has no effect on the state of a mobile node's
>> existing registration.   Future documents may specify additional
>> extension types that may 
>> Section 5 also likely needs to be modified.  I'm not sure the title
>> "Usage Example" is quite right.  Maybe, "Future Extensibility".
>> reference to the existing Registration Revocation RFC as one way to
>> do this.  Another paragraph should state that for now, none of these
>> future semantics are supported and only 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; we may want to go with
>> "Standards Action" or "Specification Required."
>> 
>> 
>> I also note that the 4 descriptions of the IP/UDP header fields in
>> section 4.1 are identical.  I think this is a bug and needs to be
>> fixed. 
>> 
>>>>> No problem. Take your time, its more important to get it right
>>>>> than to get a draft out tomorrow :-) Talk to Pete about the
>>>>> difficult issues so that we can solve everything.
>>>>> 
>>>>> Jari

---

From: Hui Deng <[email-masked]>
Date: Wed, 27 Jan 2010 00:51:40 +0800

Hi Peter,

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 27 Jan 2010 22:02:02 +0800

Thanks Peter for the review, check the enclosed, mip4 ml may not get it

inline please,

> Similar problems with the other fields.
revised all accrodingly, thanks

> text.  I am not sure which one is best.  Any opinions?
I personally prefer the specification required other than standards action,
since it is more be used sometime by somewhere, so the specification
required sounds appropriate.

>   retransmission timers for each type.
thanks, revised.

> we need some additional discussion in Section 5 about the possible use cases.
Each of them has added  some descripton word there.

>   new messages defined in this document.
Updated, thanks,

Best regards,

-Hui