Subject: Re: [mobile-ip] A proposal for resolving a very Possible conflictbetween RFC3220 & RFC3012 (RFC3012bis)

From: Charlie Perkins <[email-masked]>
Date: Wed, 20 Mar 2002 08:35:41 -0800

Hello folks,

Ahmad Muhanna wrote:

> 1. It is good to preserve a sort of forward compatibility, however, we
> need to keep in mind the more important issue which is backward
> compatibility.

I agree that we need backward compatibility, but I don't think that is
at issue
here.  A home agent will require a MN-HA authentication extension if and

only if it has a security association with the mobile node.  Thus, if a
home agent
is built to work with dynamically created assocations, delivered by AAA,

then by definition that home agent will be O.K. with the new
specification.

> 2. When we need to support any argument, we can not use work in
> progress documentation. In other words, we can not defeat existing
> standard by referencing I-D which is not a standard yet.

We can fix anything in RFC 3220bis independently of RFC 3012bis, which
is a
better approach than having RFC 3012bis obsolete language in the
yet-to-be-written
RFC3220bis.  On the other hand, the entire process has to be driven by
working
group consensus.  And, I sincerely hope that there is no such thing as
RFC3220bisbis
in any near future timeframe.

> 3. As per (RFC2002) RFC3220 & RFC3012, existing HA does the following:
>
>         i.      Expects a SA with all of its home domain Mobile Nodes.
>
>         ii.     Expecting a MN-HA authentication extension in every
> RRQ.
>         iii.    MN-AAA authentication extension does not comply with
> the definition of the authorization-enabling extension and
>                 the only extension which is defined as
> authorization-enabling extension is the MN-HA authentication
> extension.

The intention for the "authorization-enabling" language in RFC 3220 was
exactly to enable authorization by means other than the MN-HA
authentication
extension.  It was a mistake not to change this, but nobody caught this
instance
of the inconsistency.  I did change seemingly innumerable other
instances of it.

> 4. Now, with all of the above in mind, It is very dangerous to patch
> the standard here and there to satisfy future forward compatibility.

I don't think this is really true, as I explained above.  Furthermore, I
do think it
is appropriate to eliminate straggling language that would have been
eliminated
before except that we just missed it.

> 5. Interpretation of MIP standard should be done with the original and
> current spirit and understanding rather than the future evolution and
> understanding of MIP standard. This will only create more problems
> without introducing a comprehensive solution.

I agree with you, and yet I see that we should still take the corrective
actions that have
been discussed.

> I believe, a committee needs to take charge of this task with one
> objective in mind "How to evolve MIP standard to be forward combatable
> with all of the new understandings while maintaining a 100% backward
> combat ability".

Hmm... another committee...  I'm not so sure about this, but then again
if
there is a need I'll happily go along with the program, as long as the
committee supplies the text to go along with any future recommendations.

Regards,
Charlie P.