Subject: RE: [Seamoby] Moving forward with paging

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 8 Feb 2002 08:46:01 -0800

> 3. Regarding the next steps, the text I suggested was taken from
> James' recent email.  Yes we do have some drafts and it does
> represent some progress. Remember that the "front  runner"
> draft-renker is based on home agent paging whose disadvantages are
> well known.   

For those of us that are not aware of these "disadvantages" that you
are refering to, perhaps you could provide additional information?

Remember, rough concensus is easier to achieve if enough
justification is provided.

PatC

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 08 Feb 2002 12:08:05 -0600

Hi Pat,  
  The problems with HA based paging are
1. it is inefficient because HA can be far away from the visited 
network, this would induce large latencies on registration messages as 
well as in the paging process with high paging load.
2. In cases like Simple IP service in CDMA2000 it can not be used due to 
the dependence on MIP.

However if MIP is assumed and in small networks, HA based paging can 
still be useful with small paging loads.

Hope this helps,

Pat R. Calhoun wrote:

>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >
>
> iQA/AwUBPGQAyTN1fXKoxmisEQI1wQCgyrru7DfH/AHZs43GrFZM9hqmrusAnA+6
> Fri8z8M0JodiaKgjcaF7t+kR
> =3KaT
> -----END PGP SIGNATURE-----
>
Regards,

-- 
Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 08 Feb 2002 14:22:19 -0600

Dear all,
  I would like to expand upon the requirements reconsideration. 
Presently RFC 3154 has 4.7 and 4.8 and trying to satisfy all leads to a 
draft that defines a mobility independent protocol and at least two 
(mipv4 and mipv6) mobility dependent protocols, i.e. 3 protocols in one 
draft.
  How will the implementors cope with such specifications? How could  
interoperability be tested on such implementations?
  Instead would it not make sense to define separate drafts for each? 
Then interoperability can easily be tested. Also the drafts would be 
much easier to evaluate by WG members. So a better selection can be made.
  I think that Mobile IP can be extended by other WGs, I know at least 
one by AAA WG.
  So let us make some slight changes in RFC 3154 to make this possible. 
Profiting the occasion, we also could make the typographical corrections 
pointed out earlier.
   For the security requirements some comments were made before, one 
point here is the mip based protocol can make use of mip security which 
is being worked out at MIP WG so we should make this possible.
  I am not sure if this requires a charter change? I hope not.
  My 2 euro cents.

-- 
Behcet 

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Feb 2002 11:47:36 -0800

Behcet,

> interoperability be tested on such implementations?

Not necessarily.

IMHO, if the implementation of the Tracking Agent function in Section
5.1  of RFC 3154
is moved from the paging protocol to the mobility protocol, the need for
maintaining mobility information in the paging protocol about the host
while it is
in dormant mode is avoided.

The advantages of this are:

    - simplifies paging protocol to just dormant mode alerting and
    advertising of paging areas, plus possible hooks to assist
    the mobility protocol in tracking.

    - avoids duplication of location state information across multiple
    protocols/agents.

    - simplifies recovery if a paging agent fails, since there is no
need
    to duplicate location state information at replicated agents (of
course,
    the mobility protocol still has to maintain this information, but it
    is only at one place).

The disadvantages are;

    - Need to specify how dormant mode location updating is performed
    for each individual protocol.

    - Possible security implications of having an agent which is not
    the host do location updating, because requiring the host
    to do it would impact dormant mode too heavily, and
    thus be a power sink.

With further study, accepatable solutions could
be found to these problems.

> Profiting the occasion, we also could make the typographical
corrections

I don't think we need to make any changes to RFC 3154, since the
functional
architecture doesn't specify a particular protocol implementation.

I think we need to agree that there is an IP paging protocol that covers
DMA and Paging functionality, and that dormant mode location
updating is the function of the mobility protocol. Of course, there
may need to be some hooks for the paging agent to assist
in dormant mode location updating.

In addition, we would need to specify how the exisiting mobility
protocols, MIPv4 and MIPv6, handle dormant mode location
updating.

Whether these should be in the same draft or separate drafts
is another discussion.

> is being worked out at MIP WG so we should make this possible.

I don't think we want to depend on MIP security, but the discussion
in the MIP WG is relevent. In particular, there has been some discussion
there and I've had some discussion offline with some members
of the MIP BU security design team about using CGAs for
general IP signaling security. There is some interest in this, and there
may be some attempt to pull together some activity in this area.
Fortunately, the paging work is not under as much of a time
pressure as MIPv6, so we do not have to decide this issue
right now.

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Feb 2002 17:00:53 -0600

Jim,

 Only if we combine paging with MIP then your analysis applies. 
Unfortunately we won't have a MIP independent paging protocol. 
Originally this was what I had argued for if you remember the 
discussions we had last March.
Then the requirement 4.7 will be violated.
  If we are talking about mobility protocol independent IP Paging 
protocol as there are two IPs it makes two right there. I believe that 
MIP independent IP Paging protocols for v4 and v6 have to be defined 
because there will be demand and interest for cases like Simple IP 
service of CDMA2000, etc. IPv4 and IPv6 being fairly diferent means we'd 
better define them in separate IDs, although one approach could be to 
concentrate on one first (maybe v6 version).
Then the requirement 4.8 will be violated.

This is the problem with RFC 3154.
  If RFC3154bis could state 4.7 or 4.8 as the requirements, then this 
would pave the way to the development of possibly 4 different IDs.
  What do you think?

James Kempf wrote:

>>Presently RFC 3154 has 4.7 and 4.8 and trying to satisfy all leads to
>>
>a
>
>>(mipv4 and mipv6) mobility dependent protocols, i.e. 3 protocols in
>>
>one
>
>>draft.
>>much easier to evaluate by WG members. So a better selection can be
>>
>made.
>
>>  So let us make some slight changes in RFC 3154 to make this
>>
>possible.
>
>>Profiting the occasion, we also could make the typographical
>>
>corrections
>
>>pointed out earlier.
>>
>
>>point here is the mip based protocol can make use of mip security
>>
>which
>

-- 
Behcet

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Feb 2002 12:18:16 -0800

Behcet,

> Then the requirement 4.7 will be violated.

I don't see how that conclusion follows from what I sent in the
original message. My proposal was:

   Mobility Independent Paging  + Mobility Protocol Support  = Paging
                                                       for Dormant Mode
                                                           Mobility

What comes under the first term above is:

    - Actual dormant mode alerting
    - Advertising of IP paging areas
    - Interface with L2 paging
    - Mobility protocol independent hooks for
       supporting dormant mode mobility.

What comes under the second term above is:

    - Enhancements to the mobility protocol to
       allow dormant mode registration of node
       movement.

The first term abides by requirement 4.7. The second
doesn't, but I don't think anybody thought that
paging would not exert some requirements on
the mobility protocol.

> Then the requirement 4.8 will be violated.

I am even more puzzled by this conclusion. What is Simple IP?
What does that and the fact that IPv4 and IPv6 are different have to
do with supporting existing mobility protocols, which is what
requirement 4.8 is about?

> would pave the way to the development of possibly 4 different IDs.

I'd rather get agreement on the technical point of whether it makes
sense
to partition paging functionality as I've outlined above before we get
into counting how many drafts we'll have.

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Feb 2002 15:17:49 -0600

Jim,
  Here is what 4.7 of RFC3154 says:
4.7. Independence of Mobility Protocol

   Recognizing that IETF may support multiple mobility protocols in the
   future and that paging may be of value to hosts that do not support a
   mobility protocol, the IP paging protocol MUST be designed so there
   is no dependence on the underlying mobility protocol or on any
   mobility protocol at all.  The protocol SHOULD specify and provide
   support for a mobility protocol, if the Host supports one.

The Hosts of Simple IP service of CDMA2000 or any Host of UMTS
DO NOT SUPPORT a mobility protocol (developed by IETF).

Hope this clarifies.

James Kempf wrote:

>>service of CDMA2000, etc. IPv4 and IPv6 being fairly diferent means
>>
>we'd
>

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: [email-masked]
Phone: (972) 477 2794 Fax: (972) 519 2460

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Feb 2002 13:52:00 -0800

Behcet,

> DO NOT SUPPORT a mobility protocol (developed by IETF).

Now I am even more confused. Your orginal comment was that Simple IP
was a counterexample to Requirement 4.8:

> >>we'd better define them in separate IDs, although one approach could
be to
> >>Then the requirement 4.8 will be violated.

Now you are saying it is
a counterexample to Requirement 4.7. Which one do you mean?

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Feb 2002 16:21:23 -0600

Jim, let me quote 4.7 and 4.8 below:
4.7. Independence of Mobility Protocol

4.8. Support for Existing Mobility Protocols

   The IP paging protocol MUST specify the binding to the existing IP
   mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3].  The
   IP paging protocol SHOULD make use of existing registration support.

--------
Let's forget Simple IP.
      If we take 4.8 only then we can develop IP paging protocols for v4 
and v6 as extensions to mipv4 and mipv6 (as had been done on many drafts).
     Then the problem is that requirement 4.7 is violated. So these 
protocols are not acceptable as far as RFC 3154 is concerned.
   If we take 4.7 only then we can develop IP paging protocols for v4 
and v6  independent of mipv4/mipv6 (as had been done on one draft).
  Then the problem is that requirement 4.8 is violated. So these 
protocols are not acceptable as far as RFC 3154 is concerned.
  Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 
protocols in one draft and each protocol considered in isolation would 
violate either 4.7 or 4.8. This is wrong, the implementations of such 
drafts can not be interoperability tested.
  This was my main point, I had been writing so many mails to explain it 
over and over again.
SOLUTION is
4.7 or 4.8 should be the requirement
not 4.7 and 4.8.

Regards,

-- 
Behcet

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Feb 2002 18:07:19 -0800

> 4.7 or 4.8 should be the requirement

OK, now I think I understand.

I think it is possible to support both requirements by
partitioning the paging protocol as I described in the original
message. The core protocol is independent of mobility
protocol with hooks for particular mobility management
protocols to handle dormant mode mobility. How the
mobility management protocols handle dormant mode
mobility is specified separately.

Does this make sense?

W.r.t. IPv4/IPv6, there are issues here with features
of one not available in the other. The requirements
don't say anything about this, so I think we need
to open this up for discussion.

Would the working group like to allow differences
in the protocol design for IPv4/IPv6 or should we try
for a protocol design that spans both (note that I'm
not talking about trival differences like address formats)?

                jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 14 Feb 2002 11:26:01 -0500

Jim,

> mobility is specified separately.

I think this would make sense.

But I don't think the hooks described in draft-renker really satisfies
the requirements 4.7 and 4.8 even with Explicit Mode (see below).

> to open this up for discussion.

The scheme described in draft-renker relies on using the PA's address
as the alternate CoA in order to redirect packets for the dormant host
to the PA.  However, when a redirected data packet is received by the
PA, the PA must look into the inner IP header (or the final entry of
Routing Header if route opmization is used) in which the MN's Home
Address is contained in the destination IP address field in order to
distinguish the MN, as described in the draft.  This is very unnatural
way of dealing with IP-in-IP packet (or Routing Header) at an
intermediary node.  This is also related to the following comments 
from the assessment team:

  2) There is no description of how the mobility management is
     completed after the paging request is received.  There must be
     some coordination on when the deregistration is sent to PA.

I think that the coordination is very difficult (especially in terms
of security) as long as the solution relies on the use of the MN's
Home Address at PA.

(Note: Even if such an unusual packet processing at PA is considered
to be acceptable (I don't think it is acceptable), Idle Mode Request
message (used for explicit mode registration) must contain the Home
Address of the MN in order maintain the mapping between the Home
Address and CoA of the MN at the PA (this is not specified in
draft-renker), otherwise the packet would be forwarded back toward the
Home Agent's subnet based on the normal IP routing, which would not
trigger paging operation but rather result in ping-pong between the
Home Agent and PA.  Since explicit mode registration has to carry the
Home Address information, it seems that the scheme is not really
independent of mobility management protocol.)

In order to avoid this situation, an HMIPv6-like solution based on
Regional CoA would be necessary for draft-renker, but this feature is
not available for MIPv4.  This means that the scheme is not really
independent of a mobility management protocol.

On the other hand, the degree of "independency of mobility managenent
protocol" specified in draft-ohba is the highest among all the
proposals, and thus there is no problem of this kind with draft-ohba.
I think this is a very important point.

Although I don't much care whichever protocol is selected as a
starting point, I think very careful investigation is necessary for
draft-renker.

> not talking about trival differences like address formats)?

I would like trying for a protocol design that spans both, which 
would lead us to highly modular design and would also be good 
for supporting a new mobility management protocol in the future.

Thanks,
Yoshihiro Ohba

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 14 Feb 2002 17:29:12 +0100

James,

James Kempf wrote:

> protocols with hooks for particular mobility management

> Does this make sense?

I think yes. Isn't it what we intended to have in a first WG framework
draft anyway, a generic part, which is independent, and an optimization
part, which might make use of MIPvx specifics for optimization purposes.
I think the design of the architecture and the core protocol can be
that generic in most areas. For specific mobility management approaches,
requirement 4.8 can be met by keeping te paging process and state
maintenance transparent to the mobility part, but make use of available
registration mechansims (like alternate CoA registration in MIPv6 in order
to
allow directed forwarding of paging trigger packets <and hopefully longer
binding
lifetime:)>).

> not talking about trival differences like address formats)?

In my opinion, keeping some protocol specifics in kern parts is reasonable
in
some cases. So, why, as an example, not to make use of IPv6 specifics
like Extension Headers (as MIPv6 does)? An alternative generic mode
for IPv4 and IPv6 must be specified without a requirement to change the
entire format (e.g. TLV encoded messages and (sub) options).

Regards,
Marco

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 Feb 2002 10:48:36 -0600

Hello all,

Yoshihiro Ohba wrote:

>>>      If we take 4.8 only then we can develop IP paging protocols for
>>>
>>v4
>>
>>>and v6 as extensions to mipv4 and mipv6 (as had been done on many
>>>
>>drafts).
>>
>>>  This was my main point, I had been writing so many mails to explain
>>>
>>it
>>
>>>over and over again.
>>>SOLUTION is
No, it does not. Can someone point to me an RFC of standard status which
defines multiple protocols? IPv4/IPv6 are implemented in different
stacks in todays technology. Mipv4/6 run using those stacks.
I think that we should ask people to write their protocols in diferent
drafts. What is wrong with this? WG can better judge such drafts.
We all know the controversy over draft-renker, implicit explicit mode,
what it support and what it does not. If they could rewrite it in
separate drafts then people would be able to see clearly what each draft
supports.
What is wrong with this?

I agree with Yoshi on his other points.

-- 
Behcet

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 14 Feb 2002 18:22:08 +0100

Yoshi,

Yoshihiro Ohba wrote:

> distinguish the MN, as described in the draft.

Outer IP header is sripped away, since it addresses the PA in case of
making use of the alternate CoA in MIPv6. Then the PA has to check
the dest. addr. of the IP header, that's correct. In order systems, another
identifier carried with paging trigger packets might be checked. In case of
route optimization with MIPv6, the draft provides a statement, that
no bindings should be valid at CNs anymore when entering idle mode.
But for this specific case and for MIPv6, you are right, the PA has to
check the Home Address, since it is used as a more or less static identifier.

>  This is very unnatural

The Homne address comes with the Idle State Request message
sent from MN to PA. Paging trigger packets are buffered until PA
has resolved MN's CoA (after wake up). The draft refers to more
identifiers, allowing the MN to tell to the PA. During active registration,
MN first tells the mobility agent of its current location, then the PA (in
order to avoid packet loss).

Regards,

Marco

--
_____________________________________________
Marco Liebsch
Network Laboratories Heidelberg
NEC Europe Ltd
Friedrich-Ebert-Anlage 1
D-69115 Heidelberg
Tel: +49/ (0)6221/13708-11
Fax: +49/ (0)6221/13708-28
E-Mail: [email-masked]
http://www.ccrle.nec.de
_____________________________________________

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 14 Feb 2002 14:53:49 -0500

Hello Marco,

> order to avoid packet loss).

That's the point.  I don't understand how the PA delivers the buffered
packets to the resolved MN's CoA by using the Home Address of the
buffered packets for identifing the MN at PA especially when the PA is
not co-located with the home agent corresponding to the Home Address.

As far as I know, when a MIPv6 "home agent" transfers a packet to the
MN, "home address" (i.e., the destination address of the IP packet
before it is tunneled) always is "on-link" to the home agent.  But
when the PA is used for a MIPv6 "home agent" in the visiting network
to transfer the buffered packet to the MN after paging, the "home
address" is not "on-link" to the PA.  So I'm wandering what is the
magic behind it.

Moreover, I think specifying the PA's address as an Alternate Care-of
Address is NOT consistent with the following description in section
10.9 of draft-ietf-mobileip-ipv6-15.txt:

   In any Binding Update
   sent by a mobile node, the care-of address (either the Source Address
   in the packet's IPv6 header or the Care-of Address in the Alternate
   Care-of Address Sub-Option of the Binding Update) MUST be set to one
   of the care-of addresses currently in use by the mobile node or to
   the mobile node's home address.

I think one-to-one mapping between the (Alternate) CoA and home
address is necessary for Mobile IP to work, and Alternate Care-of

What do you think?

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Feb 2002 12:17:27 -0800

Yoshi,

> the requirements 4.7 and 4.8 even with Explicit Mode (see below).

I wasn't proposing that these be used without any modification.

> intermediary node.

What about simply using a Deering-Zill tunnel from the HA?

Also, I'm not sure why a Routing Header wouldn't work. Suppose
there is a Routing Header with the PA's address in it at some point,
and what the PA does when it sees that header is to issue
an IP page. Then, when the MN replies, it sends along the packet.
It is up to the MN to renew it's mobility binding at the HA.

>This is also related to the following comments

I agree that security is difficult. It essentially requires constructing
a trust relationship between the HA and PA that allows the PA
to issue binding updates to the HA when the MN moves in
dormant mode, on the mobile's behalf. But this is no different
in principle than HMIPv6. The benefit is that there is no state
on the mobile's location maintained in the foreign network,
it is all with the HA.

> independent of a mobility management protocol.

The issue I have with this is that the MNs location state gets
maintained at a "routing proxy." This is a potential source
of failure that needs to be replicated. Replication means expense.
I think we want a solution that looks like routing, where nearby
routers take over if one fails. I would rather confine an
expensive replicated agent to the HA, where it is unavoidable,
rather than introduce one into the foreign network. And, when the
IRTF Micromobility Task Force comes up with a micromobility
routing protocol, there will be no expensive routing proxy at all.

W.r.t. MIPv4, I think Regional Registration is now Informational, though
doesn't have an RFC number yet, it is like HMIPv6. But I don't
think it should be used either.

> I think this is a very important point.

draft-ohba doesn't specify where the tracking agent is, in particular,
it doesn't specify that it is handled by the mobility protocol. In
addition,
the security issue isn't discussed.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Feb 2002 12:41:10 -0800

> the security issue isn't discussed.

OK, I see in Section 8 the DMA can be an HA. 

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 Feb 2002 18:21:10 -0600

To Yoshi:
Sorry but I downplay the technicality here as draft-renker in its MIP
independent architecture uses PA only, and later on in the draft's
implicit or explicit mode it tries to do every thing (packet capturing
and paging, two distict functions ) using PA which is simply wrong
architecturally.

To James:
I appreciate your solutions but can you please bundle them in a draft,
like draft-kempf so that we can judge in its entirety?

Regards,

-- 
Behcet

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Feb 2002 19:12:58 -0800

Behcet,

> like draft-kempf so that we can judge in its entirety?

As Yoshi pointed out, I didn't propose anything that draft-ohba and
draft-renker didn't. What we are trying to sort out now is the
mechanism.
The proposal in draft-ohba isn't complete, and the proposal in
draft-renker
has some problems.

Technical discussion of this sort is, after all, the intent of this
mailing list.

            jak

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 15 Feb 2002 11:42:06 +0100

Hi Yoshi,

> address" is not "on-link" to the PA.  So I'm wandering what is the

No magic. What do you mean by 'on-link'? It's not the 'link-local' address, if
you referred to this address. HA intercepts packets on behalf of the MN,
addressed to its 'global' IPv6 address (registered as a binding with the HA).
Than HA tunnels packets, inner packets address global address of CN (as source)
and global home address of MN (as dest). Outer header identifies the HA's global
address as source and the MN's CoA as dest. So, why should the MN not to be
identified by its home address? It's at least a more static ID as CoA is. When
going
dormant, the MN registers as idle with the PA, telling him its ID(s), which is the
home
address in case of MIP. Other systems might identify the MN by different means.

>    the mobile node's home address.

Right. And in case of a MN going dormant, is uses the global PA address
as CoA. Same as hierarchical approaches make use of, which is registration
of, for example, a MAP with the HA, making use of the alternate CoA sub-option.
In my opinion it is reasonable to allow a MN to register a CoA which is different
to the source address of the IP packet carrying the BU. What is to ensure is that
HA authenticates the BU coming from the MN. Therefore, only MN is allowed to
send the BU, since only MN and HA have a security association (with stand. MIP).

Regards,

Marco

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Feb 2002 09:39:59 -0600

James, Pat and all,
I thought we should first sort out the problems in RFC3154 that I
pointed out and so far no reply came.
Therefore it is fair to conclude that RFC3154's requirements 4.7 and 4.8
are impossible to be satified in one protocol and according to well
established rules in IETF it is possible to define several protocols in
one draft of standards track and here is the mathematical proof that it
is impossible to satisfy 4.7 and 4.8.
Recalling back from the design team discussions, can I state that James
insisted on puting these two requirements despite e.g. my comments and
therefore led people like draft-renker, draft-ohba and even draft-koodli
to come up with strange drafts in which a different protocol is
presented as a mode?
How can we continue to discuss the details in these two drafts? They do
not in any way present viable solutions to the problem. it is just loss
of time to do that.

Regards,

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Feb 2002 09:51:08 -0600

James, Pat and all,
I thought we should first sort out the problems in RFC3154 that I
pointed out and so far no reply came.
Therefore it is fair to conclude that RFC3154's requirements 4.7 and 4.8
are impossible to be satified in one protocol and according to well
established rules in IETF it is NOT possible to define several protocols
in one draft of standards track and here is the mathematical proof that
it is impossible to satisfy 4.7 and 4.8.
Recalling back from the design team discussions, can I state that James
insisted on puting these two requirements despite e.g. my comments and
therefore led people like draft-renker, draft-ohba and even draft-koodli
to come up with strange drafts in which a different protocol is
presented as a mode?
How can we continue to discuss the details in these two drafts? They do
not in any way present viable solutions to the problem. it is just loss
of time to do that.

Regards,

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 17 Feb 2002 12:58:11 -0600

Hi Jim,
Well this is interesting!
So we can consider Kempf as coauthor to draft-renker and draft-ohba? If
yes this will clarify many things.
Maybe now it may appear acceptable to you my previous suggestion for way
out: design team with you as player.
The main point is that you can not be a judge and a player at the same time.

Regards,

-- 
Behcet