Subject: [netlmm] Issues Tracker Update

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 18:28:46 +0300

Folks,

I updated the issues tracker, removing old issues based on feedback I have
received and read on the mailing list, and opening new issues so as to reflect
recent mailing list discussions.  Below is a change summary; for more detailed
information please visit the issue tracker timeline at

  http://www3.tools.ietf.org/wg/netlmm/trac/timeline

Needless to say that, if you feel a closed issue requires further discussion, or
if you think a further issue should be recorded in the tracker, please send a
message to the mailing list explaining your view.  I will update the issues
tracker if need be.

The following issues have been removed:

#152: Initial Attachment vs. Handover Procedures
#155: Ordering of RA and PBU
#157: Editorial Quality
#159: Application Abort upon PPP Re-establishment
#165: Responsibility of Home Prefix Assignment
#167: Support for Authentication Option

The following issues are new:

#168: Multi-Homing Support
#169: Timestamp Increment on Retransmission
#170: MAG Compromise
#171: Use of MN-ID
#172: Clock Synchronization Recommendations

Best regards,
- Christian

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 4 Oct 2007 09:10:17 -0700

Hi Christian,

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2007 8:29 AM
> To: NetLMM Mailing List
> Subject: [netlmm] Issues Tracker Update
> 
> Folks,
> 
> 

This issue was discussed with Suresh and the agreement is
that we will use a new timestamp on the retransmitted BU,
currently as specified, but will add the missing check to
ensure the MN is still attached to the link before resending
the PBU, disallowing any false claims from multiple MAG's
for the MN's presence.

> #170: MAG Compromise

The text proposed by Ahmad was discussed and adopted for
resolving this issue. 

> #172: Clock Synchronization Recommendations

The issue is, how should LMA determine if the received
timestamp is close enough, what is the permitted clock
drift. We wanted to leave it to deployments, some think,
we should provide a number.

Sri

---

From: Christian Vogt <[email-masked]>
Date: Mon, 08 Oct 2007 14:14:39 +0300

> The text proposed by Ahmad was discussed and adopted for

This is fine.  Closing issues 169 and 170 now.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 08 Oct 2007 14:30:12 +0300

> we should provide a number.

Recommending an upper bound on the synchronization drift would be good, 
I think.  I'm not an expert on this.  Do folks have a recommendation?

- Christian