Subject: RE: Returning home and L bit (Was Re: [mobile-ip] MIPv6 v20 question re L bit)

From: "Greg O'Shea" <[email-masked]>
Date: Tue, 11 Feb 2003 10:30:08 -0000

Actually I pretty much agree with that. But I think we should do MIPv6
well, once, now. I do not think a weak spec to be rehashed in a new WG
is anything other than a diversion, prossibly a loop. 

The scope of the current draft has expanded too much making it large,
hard to manage and near impossible to stablize. In a sense this is a
structural issue with the spec itself. I believe progress would be
(would have been, still could be) faster and easier if it were broken
into at least three parts:
1) minimalist essential core - no real home nets hence no DAD or L or NS
hacks and minimum of anything else controversial 
2) support for real home nets - optional with DAD,L,NS etc
3) DHAAD and prefix discovery

It is good that much of the IPSec is already separate.

>-----Original Message-----
>From: Ed Remmell [mailto:[email-masked]] 
>Sent: 07 February 2003 23:08
>To: Greg O'Shea; Vijay Devarapalli
>Cc: Mobile IPv6 mailling list
>Subject: RE: Returning home and L bit (Was Re: [mobile-ip] 
>MIPv6 v20 question re L bit)
>
>
>Just my 2 cents...
>
>> Some important questions arise:
>> 1) What is are plan and the remit for this MIPv6bis working group?
>> 2) If we plan to rehash the current spec then why are we asking the 
>> IESG to approve something inferior?
>> 3) What will be the status of the current spec if the IESG 
>approve it. 
>> Can implementors depend upon it?
>> 4) Could the IESG are wasting its time on the current spec or could 
>> the MIPv6bis WG will be wasting its time after the horse has bolted?
>
>>From my perspective, we are pretty close already with the 
>current draft 
>>to
>having a workable MN specification. IMHO, I see no reason to 
>do major rework or to pull this specification off of the IETF 
>track. Just IMHO.
>
>Thanks.
>- Ed Remmell
>Elmic Systems, USA
>
>

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 11 Feb 2003 14:02:24 +0100

Folks,

I see we're discussing how to partition the existing spec into smaller
parts.

This is mostly out of scope for now. We are going to publish this
spec as close to rev20 as we can, because that is the consensus that
has brought us this far. And there's much more consensus there than
in any proposed subdivision of the protocol right now.

Any discussions on how to break it out are great and let's keep note of
them, but they are really only relevant after we publish this document and get some
more experience with the protocol.

Also, the fact that anybody publishes an RFC does not mean it won't
change. After all, it's initially a *Proposed* standard. Changes
are expected to happen as it progresses from Proposed to Draft and
then to Internet Standard. We are not making an exception. We're just merely
being proactive on the usual and expected IETF process, see section 4.1
in:

   http://www.ietf.org/rfc/rfc2026.txt

And by the way, not only is it possible to change a protocol, it is also
possible to retract it (as per the above published process).
This isually doesn't happen. Changes in a document,however, do happen and
are expected.

Let's please concentrate on the task at hand of closing the remaining
issues.

-gabriel