Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

From: "Kuntal Chowdhury"<[email-masked]>
Date: Fri, 15 Feb 2002 12:30:53 -0600

Well, I have problem with the statement 
"Since there is a time pressure for a MIPv6 RFC, lets publish something". It
is simply not a wise idea, no matter if a SDO needs MIPv6 RFC by some
timeline.
 
-Kuntal

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Friday, February 15, 2002 12:14 PM
To: [email-masked]
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Please note that all IETF WGs work under a charter with certain deadlines,
i.e. under time pressure. If there is no time pressure for MIPv6 as you seem
to suggest, then let's take it to IRTF the research branch of IETF.

Yes RFCs are obsoleted from time to time. So what is your point?

I am not advocating anything, it is the WG cochairs who are advocating
something. I am just suggesting something purely out of reasonable logic to
make better progress in this WG.

Regards,

Kuntal Chowdhury wrote:

> Recently RFC2002 was modified to become RFC2002bis and then RFC3220. 
> Did this cause backward compatibility nightmares?
 
It seems, you are very sure it does not! To my knowledge, RFC 3220 is far
from being widely deployed and tested?
 
> I think that you are talking about some cyber authority making RFCs that
never change.

Also, cyber authorities should not publish RFCs which need to be obsoleted
every now and then. Had the IETF followed your suggestion, then this whole
internet would have been a real management nightmare.
 
> We all know in the telecom world, the standards change sometimes
completely!

Successful telecom standards are not defined in a hurry and they do not
change like the way you are advocating.
 
-Kuntal

-----Original Message-----
From: Behcet Sarikaya [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Friday, February 15, 2002 11:25 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Kuntal,
  Recently RFC2002 was modified to become RFC2002bis and then RFC3220. 
Did this cause backward compatibility nightmares?
  I think that you are talking about some cyber authority making RFCs that
never change.
We all know in the telecom world, the standards change sometimes completely!

  So I stand by my argument.

Kuntal Chowdhury wrote:

> It could also be noted that whatever the solutions to be agreed this time
under time pressure may always be improved upon later on with additional
RFCs or RFC >xxx-bis's. It is not end of the world.
 
It is always a bad idea to rush into a solution under time pressure to get
an RFC number. This kind of approach always results in backward
compatibility nightmares.
 
-Kuntal

-----Original Message-----
From: Behcet Sarikaya [  <mailto:[email-masked]>
mailto:[email-masked] ]
Sent: Friday, February 15, 2002 10:58 AM
To:  <mailto:[email-masked]> [email-masked] 
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with
solutions of their own defeats the purpose of the design team set up by the
WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for
all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time
under time pressure may always be improved upon later on with additional
RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the
security issues.

Regards,

Glenn Morrow wrote:

Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps
digress into the link layer space of the particular access technology you
believe will be damaged. Please let me know which access specific link layer
technology you are referring to? This will be doing access work but gee if
it is going to keep access specific arguments out of the IETF work, I
suppose I'm game for coming up with an access and media specific solution to
the problem i.e. I guess I'll try to help improve the least common
denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of
these solutions will not happen very often. I also urge you to drive down
the highway right now with an existing cell phone and see if you notice some
delay during handoff. I know you could get a perfect one under some
circumstances but just keep doing it and you'll find that some "engineering
choices" have been made on particular deployments, let alone particular
products. My point here is "get real". The last proposal which I think is
what the Nokia contingent has been saying doesn't even have this theoretic
no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN)
not to send it bundled in the future after the 1st one. This also seems like
a prudent engineering choice. But gee, I haven't seen any of these mythical
sort of IP VOIP 3G handsets deployed that would have this problem in the
future and the way the financiers and vendor plans are going lately with
respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this
points out again just like an old broken record the flaw in the arguments
against bundling. And again, I would like to remind people in a completely
agnostic manner that this is the IETF and not a cellular SDO and that to
technically use the excuse for decision you have used below would signal to
me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn

behcet

-- 
Behcet 

-- 

Behcet Sarikaya

Network Strategy Group, Mobile Networking Team

Alcatel USA M/S 026

1000 Coit Road  PB7

Plano, TX 75075 USA

Email:  [email-masked] <mailto:[email-masked]> 

Phone: (972) 477 2794 Fax: (972) 519 2460

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Feb 2002 10:46:24 -0800

Hello Kuntal,

I think we have to be sensitive to the time pressure in this case.
Thus, we should definitely go for a solution that is:
- open for further improvements in the future
- avoids  trying to boil the ocean

However, I get the sense that we are very close to closure on the
important issues.  It is true that I have raised some points of
difference with the design team recommendations, but I also
think (encouraged by responses from the design team members)
that we are close to resolving those differences.  And, in some
cases, we are close to agreeing that we can evolve to a future
better system given the parts that we can agree on today.

So, I am optimistic that we can get to a very reasonable agreement
on the issues, and that we will be able to do so in a timely fashion.

Lastly, in response to statements about how nothing new is gained
from the current discussion, then I would say those people are not
paying close enough attention.  I have learned new things from
the discussions, and so it is easy for me to imagine that other
open-minded people have also.

Regards,
Charlie P.

Kuntal Chowdhury wrote:

>  Well, I have problem with the statement "Since there is a time
> pressure for a MIPv6 RFC, lets publish something". It is simply not a
> wise idea, no matter if a SDO needs MIPv6 RFC by some timeline.-Kuntal
>
>      Please note that all IETF WGs work under a charter with
>      certain deadlines, i.e. under time pressure. If there is no
>      time pressure for MIPv6 as you seem to suggest, then let's
>      take it to IRTF the research branch of IETF.
>
>      I am not advocating anything, it is the WG cochairs who are
>      advocating something. I am just suggesting something purely
>      out of reasonable logic to make better progress in this WG.
>
>      Regards,
>
>      Kuntal Chowdhury wrote:
>
>     > > Did this cause backward compatibility nightmares?It
>     > seems, you are very sure it does not! To my knowledge, RFC
>     > 3220 is far from being widely deployed and tested?> I
>     > think that you are talking about some cyber authority
>     > making RFCs that never change.
>     > Also, cyber authorities should not publish RFCs which need
>     > to be obsoleted every now and then. Had the IETF followed
>     > your suggestion, then this whole internet would have been
>     > a real management nightmare.> We all know in the telecom
>     > world, the standards change sometimes completely!
>     > Successful telecom standards are not defined in a hurry
>     > and they do not change like the way you are
>     > advocating.-Kuntal
>     >
>     >        I think that you are talking about some cyber
>     >      authority making RFCs that never change.
>     >      > > It could also be noted that whatever the
>     >      > solutions to be agreed this time under time
>     >      > pressure may always be improved upon later on
>     >      > with additional RFCs or RFC >xxx-bis's. It is
>     >      > not end of the world. It is always a bad idea
>     >      > to rush into a solution under time pressure to
>     >      > get an RFC number. This kind of approach always
>     >      > results in backward compatibility
>     >      > nightmares. -Kuntal
>     >      >
>     >      >      From: Behcet Sarikaya [
>     >      >        I have a feeling that Charlie and
>     >      >      Glenn and possibly others coming up
>     >      >      with solutions of their own defeats
>     >      >      the purpose of the design team set up
>     >      >      by the WG cochairs and to my
>     >      >      knowledge agreed by the WG.
>     >      >        I suggest that DT makes a
>     >      >      conference call with these people
>     >      >      once and for all and gets their input
>     >      >      and continues its work.
>     >      >        It could also be noted that
>     >      >      whatever the solutions to be agreed
>     >      >      this time under time pressure may
>     >      >      always be improved upon later on with
>     >      >      additional RFCs or RFC xxx-bis's. It
>     >      >      is not end of the world.
>     >      >     >  Hesham, I too, am starting to feel
>     >      >     >  like a broken record so I think we
>     >      >     >  should perhaps digress into the
>     >      >     >  link layer space of the particular
>     >      >     >  access technology you believe will
>     >      >     >  be damaged. Please let me know
>     >      >     >  which access specific link layer
>     >      >     >  technology you are referring to?
>     >      >     >  This will be doing access work but
>     >      >     >  gee if it is going to keep access
>     >      >     >  specific arguments out of the IETF
>     >      >     >  work, I suppose I'm game for coming
>     >      >     >  up with an access and media
>     >      >     >  specific solution to the problem
>     >      >     >  i.e. I guess I'll try to help
>     >      >     >  improve the least common
>     >      >     >  denominators. Here are some
>     >      >     >  proposals:  - SAR the packet.- Send
>     >      >     >  it over a signaling channel with
>     >      >     >  additional delay.- Make the
>     >      >     >  channels more flexible to handle
>     >      >     >  spurious changes in bandwidth. Keep
>     >      >     >  in mind that the almost negligable
>     >      >     >  delay, if any,  induced by some of
>     >      >     >  these solutions will not happen
>     >      >     >  very often. I also urge you to
>     >      >     >  drive down the highway right now
>     >      >     >  with an existing cell phone and see
>     >      >     >  if you notice some delay during
>     >      >     >  handoff. I know you could get a
>     >      >     >  perfect one under some
>     >      >     >  circumstances but just keep doing
>     >      >     >  it and you'll find that some
>     >      >     >  "engineering choices" have been
>     >      >     >  made on particular deployments, let
>     >      >     >  alone particular products. My point
>     >      >     >  here is "get real". The last
>     >      >     >  proposal which I think is what the
>     >      >     >  Nokia contingent has been saying
>     >      >     >  doesn't even have this theoretic no
>     >      >     >  delay mumbo jumbo point
>     >      >     >  either. Also keep in mind that  the
>     >      >     >  mobile could be configured to tell
>     >      >     >  the CN(MN) not to send it bundled
>     >      >     >  in the future after the 1st one.
>     >      >     >  This also seems like a prudent
>     >      >     >  engineering choice. But gee, I
>     >      >     >  haven't seen any of these mythical
>     >      >     >  sort of IP VOIP 3G handsets
>     >      >     >  deployed that would have this
>     >      >     >  problem in the future and the way
>     >      >     >  the financiers and vendor plans are
>     >      >     >  going lately with respect to
>     >      >     >  alternatives I'm not sure if we
>     >      >     >  ever will.  There - now I've been
>     >      >     >  completely politically incorrect
>     >      >     >  but I hope this points out again
>     >      >     >  just like an old broken record the
>     >      >     >  flaw in the arguments against
>     >      >     >  bundling. And again, I would like
>     >      >     >  to remind people in a completely
>     >      >     >  agnostic manner that this is the
>     >      >     >  IETF and not a cellular SDO and
>     >      >     >  that to technically use the excuse
>     >      >     >  for decision you have used below
>     >      >     >  would signal to me that the IETF is
>     >      >     >  behaving like an access specific
>     >      >     >  cellular SDO. Thanks, Glenn
>     >      >
>     >      >      behcet
>     >      >
>     >      >
>     >      --
>     >      Behcet
>     >
>     >
>     >
>      --
>      Behcet Sarikaya
>      Email: [email-masked]