Subject: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 9 Apr 2008 07:52:47 -0700 (PDT)

I support the advancement of this document to the IESG with a
     request for publication as a Proposed Standard RFC.

Regards,

Behcet
----- Original Message ----
From: McCann Peter-A001034 <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Friday, April 4, 2008 12:16:30 PM
Subject: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt

This message announces a 2-week working group last call on:

"Generic Notification Message for Mobile IPv4"          
draft-ietf-mip4-generic-notification-message-04.txt

The last call will end at 24:00 UTC on Friday, April 18 2008.

This document specifies protocol enhancements that allow Mobile IPv4
entities to send and receive explicit notification messages using a
new Mobile IPv4 message type designed for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-generic-notification
-message-04.txt

Please respond to this working group last call:

* If you have no comments on the draft, and support its advancement,
  simply respond with a line containing something like

    "I support the advancement of this document to the IESG with a
     request for publication as a Proposed Standard RFC."

   If you have comments, please use a line similar to the one above,
   and supplement this with your comments.

* If you *don't* support its advancement, respond with a line
  containing something like the following, supplemented by your
  comments -

    "I don't support the advancement of this document to the IESG with
     a request for publication as a Proposed Standard RFC, for the
     following reasons:"
    ...

Please direct all replies to the Mobile IPv4 mailing list,
[email-masked].

-Pete
-- 
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/

-- 
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: [email-masked]
Date: Tue, 15 Apr 2008 10:27:28 +0800 (CST)

I support the advancement of this document to the IESG with a request for
publication as a Proposed Standard RFC.

During our research on MIP4, We find it is necessary to allow Mobile IPv4
entities to send and receive explicit notification messages using a
new Mobile IPv4 message type.

> Send Mip4 mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/mip4
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mip4 digest..."
>
>
> Today's Topics:
>
>    1. Re: draft-mccann-mip4-mbb-00.txt (Kent Leung (kleung))
>    2. Re: draft-mccann-mip4-mbb-00.txt (Ahmad Muhanna)
>    3. Re: draft-mccann-mip4-mbb-00.txt (Ahmad Muhanna)
>    4. Re: draft-mccann-mip4-mbb-00.txt (McCann Peter-A001034)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 13 Apr 2008 23:27:55 -0700
> From: "Kent Leung (kleung)" <[email-masked]>
> Subject: Re: [Mip4] draft-mccann-mip4-mbb-00.txt
> To: "McCann Peter-A001034" <[email-masked]>, <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
>
>
>
>> If RFC 3957 is not used, then what method will set up the security
>> associations?  I'm not sure how the MN-AAA and FA challenge/response
>> can be avoided when switching over to CMIPv4, assuming no SA fetched
>> ahead of time?
>
> No, they wouldn't be avoided; in fact the draft anticipates their use.
> If 3957 isn't being used, the HA can do whatever it needs to set up the
> security association such as fetching it from AAA or whatever.
>
> KL> OK.  That is reasonable.  The preregistation message can fetch
> subscriber attributes from AAA server in advance.
>
>
>>> The use of the 'S' bit (and zero lifetime and new CoA) for this
>>> purpose seems kludgy in the protocol.  It may be better to have
>>> explicit Pre-registration Extension to indicate that the message is
>>> intended to perform operations on the entities before actual handoff
>>> signaled by registration request/reply exchange.
>>
>> We decided to use the 'S' bit because it seems logical that the node
>> is trying to create another registration without tearing down the old
>> one, albeit one which doesn't tunnel traffic hence the zero lifetime.
>> However, I'm open to other ways of solving the problem and perhaps a
>> new extension would work; however, we really wanted to introduce just
>> the minimum amount of new specification and the current approach could
>
>> even be considered an implementation option in an existing HA.
>>
>>> Either way, it's a change to existing HA implementation. :)
>
> True, but no new PDUs need to be decoded.
>
> KL> My initial reaction to re-using/overloading the S-bit (which was
> defined for simultaneous bindings) was that it was confusing to be using
> for a different function, namely pre-registration operation.  Now, your
> explanation helps with why that approach was selected.  Though I'm not
> sure if I would quite agree with that because both the message initiator
> and the HA have to have the new logic for dealing with the new
> signaling, regardless if it's a bit or extension.
>
> Kent
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 14 Apr 2008 08:04:37 -0500
> From: "Ahmad Muhanna" <[email-masked]>
> Subject: Re: [Mip4] draft-mccann-mip4-mbb-00.txt
> To: "Kent Leung (kleung)" <[email-masked]>,	"McCann Peter-A001034"
> 	<[email-masked]>, <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="US-ASCII"
>
>
>>
>> >> The use of the 'S' bit (and zero lifetime and new CoA) for this
>> >> purpose seems kludgy in the protocol.  It may be better to have
>> >> explicit Pre-registration Extension to indicate that the
>> message is
>> >> intended to perform operations on the entities before
>> actual handoff
>> >> signaled by registration request/reply exchange.
>> >
>> > We decided to use the 'S' bit because it seems logical that
>> the node
>> > is trying to create another registration without tearing
>> down the old
>> > one, albeit one which doesn't tunnel traffic hence the zero
>> lifetime.
>> > However, I'm open to other ways of solving the problem and
>> perhaps a
>> > new extension would work; however, we really wanted to
>> introduce just
>> > the minimum amount of new specification and the current
>> approach could
>>
>> > even be considered an implementation option in an existing HA.
>> >
>> >> Either way, it's a change to existing HA implementation. :)
>>
>> True, but no new PDUs need to be decoded.
>>
>> KL> My initial reaction to re-using/overloading the S-bit (which was
>> defined for simultaneous bindings) was that it was confusing
>> to be using for a different function, namely pre-registration
>> operation.  Now, your explanation helps with why that
>> approach was selected.  Though I'm not sure if I would quite
>> agree with that because both the message initiator and the HA
>> have to have the new logic for dealing with the new
>> signaling, regardless if it's a bit or extension.
>
> [Ahmad]
> I tend to agree.
> I actually communicated my views earlier to Pete offline and mentioned
> that since the proposal include changes at the MN and the HA anyway,
> then why not we do a clean solution for this pr-registration by using a
> new extension rather than over load the status bit logic.
>
>>
>> Kent
>>
>> --
> ------------------------------
>
> Message: 3
> Date: Mon, 14 Apr 2008 08:09:29 -0500
> From: "Ahmad Muhanna" <[email-masked]>
> Subject: Re: [Mip4] draft-mccann-mip4-mbb-00.txt
> To: "Ahmad Muhanna" <[email-masked]>,	"Kent Leung (kleung)"
> 	<[email-masked]>,	"McCann Peter-A001034" <[email-masked]>,
> 	<[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="US-ASCII"
>
>
>> >
>> > KL> My initial reaction to re-using/overloading the S-bit (which was
>> > defined for simultaneous bindings) was that it was confusing to be
>> > using for a different function, namely pre-registration operation.
>> > Now, your explanation helps with why that approach was selected.
>> > Though I'm not sure if I would quite agree with that
>> because both the
>> > message initiator and the HA have to have the new logic for dealing
>> > with the new signaling, regardless if it's a bit or extension.
>>
>> [Ahmad]
>> I tend to agree.
>> I actually communicated my views earlier to Pete offline and
>> mentioned that since the proposal include changes at the MN
>> and the HA anyway, then why not we do a clean solution for
>> this pr-registration by using a new extension rather than
>> over load the status bit logic.
>
> [Ahmad]
> Hmmm.. meant to say the Simultaneous binding bit:-)
>>
>> >
>> > Kent
>> >
>> > --
>> >      Charter page:
>> http://www.ietf.org/html.charters/mip4-charter.html
> ------------------------------
>
> Message: 4
> Date: Mon, 14 Apr 2008 10:49:55 -0400
> From: "McCann Peter-A001034" <[email-masked]>
> Subject: Re: [Mip4] draft-mccann-mip4-mbb-00.txt
> To: "Ahmad Muhanna" <[email-masked]>,	"Kent Leung (kleung)"
> 	<[email-masked]>, <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
>
> Hi, Ahmad, Kent,
>
> In principle I am open to solving the problem in a different
> way if we can.  Let's work offline and try to come back with
> a draft that we are all happy with.  I think we at least have
> a common agreement on the problem to be solved.
>
> Thanks,
>
> -Pete
>
>
> Ahmad Muhanna wrote:
>>>>KL> My initial reaction to re-using/overloading the S-bit (which was
>>>> defined for simultaneous bindings) was that it was confusing to be
>>>> using for a different function, namely pre-registration operation.
>>>> Now, your explanation helps with why that approach was selected.
>>>> Though I'm not sure if I would quite agree with that because both
>>>> the message initiator and the HA have to have the new logic for
>>>> dealing with the new signaling, regardless if it's a bit or
>>>> extension.
>>>
>>> [Ahmad]
>>> I tend to agree.
>>> I actually communicated my views earlier to Pete offline and
>>> mentioned that since the proposal include changes at the MN and the
>>> HA anyway, then why not we do a clean solution for this
>>> pr-registration by using a new extension rather than over load the
>>> status bit logic.
>>
>> [Ahmad]
>> Hmmm.. meant to say the Simultaneous binding bit:-)
>>>
>>>>
>>>> Kent
>
>
> ------------------------------
>
> --
> End of Mip4 Digest, Vol 47, Issue 13
> ************************************
>
>