Subject: [mobile-ip] Re: Issue 55

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Sep 2002 16:34:45 -0700

Hello Jim,

Thanks for your comments!  If there is more followup, please
let me know, especially if you want further textual changes
to my deployment paragraph.  Here is my attempt to resolve Issue 55.

James Kempf wrote (on July 8, 2002):

         ........

> Proposal:
> 
> 1) Editorial
> 
> The spec is in need of being worked through by a technical editor with
> an understanding of IETF specifications. In some cases, MUST and
> SHOULD language is missing where it would be useful to designate
> requirement level.

Without specific examples, I can't be sure that our revisions
will have addressed your concern.  We have tightened up a lot
of places in the spec.

>     The material in Appendix A should either be incorporated
> into the text or dropped.

I thought that Jari put the section in as a result of previous
requests from the working group.

>                          Similarly, the other two appendicies should
> be dropped. Appendix C would be good for the WG to use as a guide for
> future work, but doesn't belong here.

The ADs have asked for such Changes sections in other documents,
and in previous versions of this document I believe.

The Future Extensions text is reasonably included in the document,
I think.  It does serve to give a lot of context for various
design decisions that have been reached.

> 7) BA return
> 
> Section 6.1.8 says that a BA MUST be sent if the A bit is set, but it
> does not say what should happen if the A bit isn't set. Can a node
> send a BA if the A bit isn't set?

Yes, a node can send a BA if the 'A' bit is not set.
For instance, it may wish to report an error condtion.
This is discussed in section 9.4.4, which is cross-referenced
from section 6.1.8.

> 8) PadN
> 
> Would it be worthwhile to specify that the PadN bits must be zeroed?

It's already specified that those bits MUST be ignored.
I don't think it's incorrect as is, but I put it in for PadN,
and for consistency also for Pad1.

> 12) Value judgement on security infrastructure
> 
> In Section 14.2, pg. 130 contains a paragraph with a value judgement
> on whether security infrastructure might be deployable or not.  It is
> too early to tell whether this value judgement is correct and, in any
> event, it does not belong in this specification. The
> infrastructureless approach can be motivated by the simple statement
> that deploying an IPsec security association between two arbitrary
> node in the Internet in the absence of a global PKI is a hard problem,
> and so a solution that does not require such was developed in the
> interests of maintaining the minimum requirements for deployable
> MIPv6. Whether or not an infrastructure based solution can be
> developed for some subproblem is an open question.

Here's the new text:

   It is expected that Mobile IPv6 route optimization will be used on
   a global basis between nodes belonging to different administrative
   domains.  Deploying an IPsec security association between two
   arbitrary node in the Internet in the absence of a global PKI is
   a hard problem, and so a solution that does not require such was
   developed in the interests of maintaining the minimum requirements
   for a deployable mobility solution.  The chosen infrastructureless
   method is described in Section 5.2 and Section 14.4 discusses the
   resulting security level and the design rationale of this approach.

> 13) References
> 
> The nonnormative references should be removed or converted into
> normative references.

I strongly disagree with this, and I've never heard of any
such directive aimed at other specifications.  Recently, in
fact, we've been asked to divide the references into two
classifications.  Such a request seems to rest securely on
the supposition that there are indeed two kinds of references.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 17:37:25 -0700

Hi Charlie,

These look fine.

I've been informed that the RFC editor now accepts nonnormative references, so I
have no problems with them.

Thanx for your hard work on the spec.

            jak

----- Original Message -----
From: "Charles E. Perkins" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Mobile IP Working Group"
<[email-masked]>
Sent: Tuesday, September 17, 2002 4:34 PM
Subject: Re: Issue 55

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Sep 2002 16:38:48 +0300

>>requests from the working group.
This is issue #76, the state machine. Most people who responded said that they'd
rather remove the appendix, so it's now gone.

Jari