Subject: [MEXT] Issue #1: Last accepted SQN

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 27 Jun 2008 12:08:29 -0700

Hello folks,

The intention in RFC 3775 was pretty clearly to allow the mobile
node to update its record for the sequence number.  An authenticated
Binding Acknowledgement is clearly useful for this purpose.  The
discussion up until now was sticking on the need for a new protocol
element, which Ahmad specified as an extension.

Since I'm in the process of collecting mailing-list inputs and
trying to make recommendations according to the discussion
so far, I thought I'd like to at least suggest a text revision for
rfc3775bis that (a) allows the original intention of RFC 3775
but (b) does not require a new protocol element.

========================================================================

OLD TEXT:

   o  The Sequence Number field matches the Sequence Number sent by the
      mobile node to this destination address in an outstanding Binding
      Update.

========================================================================

NEW TEXT:

   o  The Sequence Number field matches the Sequence Number sent by the
      mobile node to this destination address in an outstanding Binding
      Update, and the Status field is not 135.

... and, just before the bulleted text for Status field #1 (currently on
    pg. 139):

   o  Additionally, if the Binding Acknowledgement correctly passes
      authentication and the Status field value is 135 (Sequence Number
      out of window), then the mobile node MUST update its binding
      sequence number appropriately to match the sequence number given
      in the Binding Acknowledgement.  Otherwise, if the Status field
      value is 135 but the the Binding Acknowledgement does not pass
      authentication, the message MUST be silently ignored.

========================================================================

If this is O.K., I plan to use it as a recommendation for resolution
of this issue.

Regards,
Charlie P.

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 27 Jun 2008 16:49:02 -0500

Hi Charlie.

I am fine with the suggested text.

Cheers!

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Charles E. Perkins
> Sent: Friday, June 27, 2008 2:08 PM
> To: [email-masked]
> Subject: [MEXT] Issue #1: Last accepted SQN
> 
> Hello folks,
> 
> The intention in RFC 3775 was pretty clearly to allow the 
> mobile node to update its record for the sequence number.  An 
> authenticated Binding Acknowledgement is clearly useful for 
> this purpose.  The discussion up until now was sticking on 
> the need for a new protocol element, which Ahmad specified as 
> an extension.
> 
> Since I'm in the process of collecting mailing-list inputs 
> and trying to make recommendations according to the 
> discussion so far, I thought I'd like to at least suggest a 
> text revision for rfc3775bis that (a) allows the original 
> intention of RFC 3775 but (b) does not require a new protocol element.
> 
> If this is O.K., I plan to use it as a recommendation for 
> resolution of this issue.
> 
> Regards,
> Charlie P.
> 
>

---

From: [email-masked] (Arnaud Ebalard)
Date: Sat, 28 Jun 2008 13:59:36 +0200

Hi,

> but (b) does not require a new protocol element.

I don't see where, can you give some context (the end of previous
sentence, for instance)?

>      value is 135 but the the Binding Acknowledgement does not pass

                        ^^^^^^^ small typo

>      authentication, the message MUST be silently ignored.

Cheers,

a+

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 28 Jun 2008 07:29:31 -0700

> I don't see where, can you give some context (the end of previous

 From the current draft, here is the precedeing paragraph and the
first sentence of the next paragraph:
-------------------------------------------------------------------
      Mobile nodes SHOULD send a new Binding Update well before the
      expiration of this period in order to extend the lifetime.  This
      helps to avoid disruptions in communications which might otherwise
      be caused by network delays or clock drift.

   o  Additionally, if the Status field value is 1 (accepted but prefix ...
-------------------------------------------------------------------

Thanks for catching the typo.

Regards,
Charlie P.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 30 Jun 2008 20:48:19 -0400

Hi Charlie,

> If this is O.K., I plan to use it as a recommendation for resolution

This sounds good to me. 

Vijay