Subject: [mobile-ip] Status of the draft

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Jan 2003 03:26:39 +0200

Hello,

Here's what I think is the status of the currently open issues.
Your help on bringing them to a closure is essential for us
getting a draft 20 out this week. Take a look at what is needed
to solve 205 & 206, 194 & 195, and 210 in particular.

I'm going to be without network connectivity for the next two
days. After this we will produce draft 20 as soon as possible,
so let's try to get that consensus on the open issues quickly.
I'm counting on text to be at my Inbox when I log in again ;-)

210 - Otherwise closed, but we are debating SHOULD vs. MAY for RS

       Action plan: Please comment on the Greg's and Vijay's
       viewpoints so we can close this.

205 & 206 - We have an agreement on the problem and the way to
             solve it, but text is missing. Before we have text
             we can't be sure if there's additional problems in the
             proposed solution.

             Action plan: please contribute text. I think Marc
             is going to produce something on this.

202, 184: I think we have a compromise here on the specific
           issues, though I'm worried with the amount of folks
           complaining about the S bit.

194, 195: We have an agreement on the solution, and some text.
           Parts of the text are still missing, such as the
           normative text on how to use the (K) bit. Also,
           requirements section in the ha-ipsec draft and the
           base is probably not in full sync.

           Action plan: Please review current parts, and
           provide a propoasl on what other things are needed.

192: I think the chairs just closed this.

Other: Please continue the excellent feedback that we've been
        getting on the bugs in the prerelease of draft 20. Take
        a look at the IPsec draft as well, this is probably not
        in as good shape as the base is yet.

Issues and drafts are at the web:

    http://[3ffe:200:8:2000::3]/~jarkko/publications/mipv6/MIPv6-Issues.html
    http://[3ffe:200:8:2000::3]/~jarkko/publications/mipv6/drafts/mobilev6.html
    http://[3ffe:200:8:2000::3]/~jarkko/publications/mipv6/drafts/mipv6haipsec.html

and for the IPv6-challenged they can also be accessed at

    http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html
    http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html
    http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html

Jari

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 15 Jan 2003 09:29:02 +0100

Thanks Jari for the status update.

A couple of comments from the chairs:

The Mobile IPv6 I-D version 19 has been revised following comments and
feedback received from the ADs as well as issues raised during WG last
call by WG members. Draft version 20 will be completed this Friday and
this version will be sent to the IESG for review and IETF last
call.

We will close all remaining issues on Thursday (Jan 16) at 3pm GMT. Any
issues without satisfactory resolutions will be marked as such
but closed nonetheless. These can be worked on as part of
IETF last call comments.

And responding to what Jari said on the S-bit issue:

>           complaining about the S bit.

We too are worried as several folks have expressed a preference
towards removing the S-bit from the base draft. In the interest
of gauging consensus about this, here's what we think we are
seeing:

On Removing S bit:
  pro: charlie, vijay
  cons: greg o'shea, jari, francis, brian haley, mohan, marc
  unclear: Vladislav Yasevich, Krishna Kumar, ??

If your position is not correctly (or clearly) listed above,
please say so. If you haven't expressed an opinion and this is
something you care about PLEASE DO SO.

-the chairs

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 15 Jan 2003 09:33:29 +0100

Correction below...

 > On Removing S bit:

Should be "On leaving the S bit in the base spec" of course...

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 15 Jan 2003 11:20:08 -0500

You can put me into the "Remove the S bit" camp.  I've never
been attached to it, but was interested in making it work.

I think it would be better to specify in a separte draft where
all the ramification can be addressed.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 16 Jan 2003 16:37:04 +0100

Jari,

I've annotated your message with further status info.

-gabriel

-------------------------------------------------------

Marked with ("*"): issues closed because of the deadline imposed
	(3pm GMT, Thursday Jan 16).

----------------------------------------------------------------
210 - Otherwise closed, but we are debating SHOULD vs. MAY for RS

gab: Looks like this is closed as per the agreement on the list
	between Greg and Vijay. Look for thread with subject
	"some more comments on draft 20 (pre)". There was
	agreement on Greg's statement below:

If the draft says SHOULD I'd suggest something like:

"...Upon lower-layer indication of link-layer mobility,
     the mobile node SHOULD send Router Solicitations to
     determine if additional on-link subnet prefixes are
     available on its new link.  The MN SHOULD also mark
     its link-local address as tentative, and follow standard
     Duplicate Address Detection procedures\cite{rfc2462}."

Issue closed.

----------------------------------------------------------------
*205 & 206 - We have an agreement on the problem and the way to
             solve it, but text is missing. Before we have text
             we can't be sure if there's additional problems in the
             proposed solution.

gab: Marc's text looks good and it reflects the consensus, just check for
	minor editorial nits some related to some language
	based on the soon-to-be-obsoleted MLDv1.
	He's written it with SHOULD's instead of MUST's.
	That's fine by me, seems like a SHOULD is best.
	Look for subject
	"Suggested text for issues 205 & 206"
	Issue closed by deadline.

----------------------------------------------------------------
202, 184: I think we have a compromise here on the specific
           issues, though I'm worried with the amount of folks
           complaining about the S bit.

gab: Closed by chairs by removing the S-bit.

----------------------------------------------------------------
*194, 195: We have an agreement on the solution, and some text.
           Parts of the text are still missing, such as the
           normative text on how to use the (K) bit. Also,
           requirements section in the ha-ipsec draft and the
           base is probably not in full sync.

  gab: There is agreement on this. The K bit shows in the
  	pre(20) version.
	Work on final details to proceed for rev20.
	Issue declared closed by deadline.

----------------------------------------------------------------
192: I think the chairs just closed this.

gab: Yes, closed.

---------------------------------------------------------
189: security issues

gab: Go ahead and mark it as closed. Only thing remaining is
the mandatory or not on IKE, let's just go with non-mandatory
for rev20.

---------------------------------------------------------
New issue:

"MIPv6 Clarification to Type 0 & 2 Routing Header interop"
brought up by Ville Nuorvala

gab: This may happen in some implementations when the packet
	"is built starting from the IPv6 header and ending at
	the payload data (e.g. linux with UDP and raw sockets).
	This is not a problem for most implementors as they
	construct the packet from the data ending in the
	IPv6 header"
	Seems like the rule is: construct RH2 first, then
	RH0. And then decapsulate in the inverse order.
	Seems logical, perhaps nothing to clarify.
	At most, perhaps a reference to "Nested Encapsulation"
	in rfc2473 could suffice.

Ville agrees with this:

"If both a type 0 and a type 2 routing header are present,
the type 2 routing header should follow the other routing header.
In such a nested encapsulation the inner (type 2) routing header
is constructed first and then treated as an original packet by
the outer (type 0) routing header construction process."

Issue closed.

-------------------------------------------------------
New issue:

"MIPv6: Problem with site-local prefixes an Type 2Routing  Header?"

Vijay Devarapalli wrote:
 > I think SHOULD NOT is good enough. there is no reason for a
 > MUST NOT.

The way I read these exchanges is that we're keeping the SHOULD NOT, but
adding the default=off configurability in Section 10.4.2 as
suggested by Jari:

   Packets addressed to the mobile node's site-local address
   SHOULD NOT be tunneled to the mobile node by default,
   but this behavior MUST be configurable to enable it;
   ...
   Multicast packets addressed to a multicast address with
   scope larger than link-local but smaller than global
   (e.g., site-local and organization-local~\cite{rfc2373}),
   to which the mobile node is subscribed, SHOULD NOT be
   tunneled to the mobile node by default. This behavior
   MUST be configurable to allow it to be enabled.

...as currently reflected in the pre(20) version:
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#ha-deliver

Right?

-gabriel

gab: Issue closed and currently reflected in the pre(20) draft.
	Also closed since this is a rehashing of issue 162.

-------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jan 2003 06:27:38 +0100 (CET)

> something you care about PLEASE DO SO.

I think for the S-bit to not cause serious confusion between MNs and HAs
it needs to be revamped so that the BAck tells the MN which
addresses actually got registered. 
But even with such a fix the IPsec and other added complexity seems
high.
Thus I personally think that moving it out of the base spec would be a good
idea - potentially saves some more s-bit surprises down the road and makes
the protocol simpler.

  Erik