IMHO, this thread of this discussion belongs to the HIP WG list. I
am replying there.
--Pekka Nikander
On Sep 17, 2005, at 15:48, Iljitsch van Beijnum wrote:
On 15-sep-2005, at 9:57, Pekka Nikander wrote:
So, as I state in my little web page, I think we really should
work hard to create
On 15-sep-2005, at 9:57, Pekka Nikander wrote:
So, as I state in my little web page, I think we really should
work hard to create a new waist for the architecture. I, of
course, have my own theory where the new waist should be and how
it should be implemented,
Well, don't be shy: where
... But if I see identification, authentication and routing matters
being addressed, I see proposed changes enough to suspect that this
will affect the level above (DNS) and below (IP addressing).
I don't see any *necessary* changes to IP addressing; OTOH wide
spread use of HIP would certai
Dear Pekka,
I went through a few of your documents to better understand the basic
of HIP. When I told you I prefer models: your proposition could fit
my model. But if I see identification, authentication and routing
matters being addressed, I see proposed changes enough to suspect
that this wi
So, as I state in my little web page, I think we really should
work hard to create a new waist for the architecture. I, of
course, have my own theory where the new waist should be and how
it should be implemented,
Well, don't be shy: where can we absorb these insights?
Since you ask:
U
On 13-sep-2005, at 14:32, Pekka Nikander wrote:
So, as I state in my little web page, I think we really should work
hard to create a new waist for the architecture. I, of course,
have my own theory where the new waist should be and how it should
be implemented,
Well, don't be shy: where
On 14:32 13/09/2005, Pekka Nikander said:
OTOH, maybe I am just a dreamer and totally off the ground here?
No, you are not!
However the problem with a "vision" is to know where the boarder is
between dreams and real future. This is why I prefer a more prosaïc
"model" which gives a simple im
Jari Arkko wrote:
- Good architecture and good design. Placement of
functionality in the right place. I suspect that we
don't do enough work in this area. Almost all
of our activities are related to specific protocol
pieces, not so much on how they work together,
what the whole needs to do,
Jeffrey Hutzelman wrote:
>>> If you have complicated requirements, you are wrong.
>>
>>
>> You are only ever wrong if you do not listen to your customers and as a
>> result fail to provide them with what they want.
>
>
> This is a vast oversimplification. Even if you give your customers what
>
On Monday, September 12, 2005 10:13:52 -0700 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
Behalf Of Masataka Ohta
If you have complicated requirements, you are wrong.
You are only ever wrong if you do not listen to your customers and as a
result fail to provide them with what th
> Behalf Of Masataka Ohta
> If you have complicated requirements, you are wrong.
You are only ever wrong if you do not listen to your customers and as a
result fail to provide them with what they want.
The world is complex, sometimes solutions must also be complex. In those
cases the design cho
Henning Schulzrinne wrote:
> The assumption that specialized protocols are needed for every
> new application.
That's irrelevant.
The question is whether the application is complicated or not.
> As an example, SIP is more complicated than it has
> to be because there was a decision to support
--On søndag, september 11, 2005 17:57:29 -0400 Henning Schulzrinne
<[EMAIL PROTECTED]> wrote:
- Generalization of point solutions. Even major new
functionality often starts out as the need of a specialized
group of users. If you always do only what is needed
right now and don't think ahea
- Good architecture and good design. Placement of
functionality in the right place. I suspect that we
don't do enough work in this area. Almost all
of our activities are related to specific protocol
pieces, not so much on how they work together,
what the whole needs to do, what etc.
These
standards bloat solution:
anyone proposing a new feature has to propose two features to be retired.
anyone proposing a new standard has to propose two standards to be
retired.
This is a fun thread, but if we ever decide to get serious
about complexity, we can't assume a static Internet or
st
--On 9. september 2005 13:55 -0500 Spencer Dawkins <[EMAIL PROTECTED]>
wrote:
This was quite funny - both of you!
Of course, the first thing to do when you want to lose "complexity" is
"Stop adding to the problem" (as in "Put down the fork and push away from
the table...").
standards bloa
Session Border Controller for dessert ?
Grumble Grumble ..< burp>
See you in Vancouver,
Spencer
From: "Richard Shockey" <[EMAIL PROTECTED]>
To: "Pekka Nikander" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, September 09, 2005 1:35 PM
Subject: Re: "The IETF ha
<[EMAIL PROTECTED]>
To: "Pekka Nikander" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, September 09, 2005 1:35 PM
Subject: Re: "The IETF has difficulty solving complex problems" or
alternatively Why IMS is a big fat ugly incomprehensiable protocol
Pekka Nikander wro
Pekka Nikander wrote:
In a whimsical mood, I put up a web page that tries to
clarify the comments that I made about complexity during
the Paris IETF Thursday plenary. So, for your bed time
enjoyment:
http://www.tml.tkk.fi/~pnr/FAT/
Pekka this is a outstanding piece of work and I would sug
In a whimsical mood, I put up a web page that tries to
clarify the comments that I made about complexity during
the Paris IETF Thursday plenary. So, for your bed time
enjoyment:
http://www.tml.tkk.fi/~pnr/FAT/
--Pekka Nikander
___
Ietf mailing lis
At 14:20 09/08/2005, Brian E Carpenter wrote:
without needing an over-arching scalablity framework or robustness framework.
This is what I call the "mono" default architectural parametering of the
Internet. The architecture permits applications to scale. The architecture
could scale. But the
Well, this didn't come up in the Thursday plenary unless
my brain is more than normally fuzzy.
Firstly, it's worth re-reading section 2.3 of RFC 3774...
...OK, now you've read that, I wouldn't necessarily agree
with every word, but I think it's basically true. What I
meant to argue is that what
> This conjecture was disturbing, but calling it a feature was
> even more disturbing. After a bit of pondering, and
> wondering what different groups in the IETF might mean by
> "complex", my first thought was that the IETF has never, ever
> solved one. For example, we do QoS in small pieces
Dear Scott,
could we phrase it differently?
I submit that we could qualify (along with your own wording) "complex"
changes as bringing a "revolution".
In that case the problem becomes simpler: to try to tink if there is a way
to make the "revolution" a simple "evolution".
I will take an exampl
This conjecture was disturbing, but calling it a feature was even more
disturbing. After a bit of pondering, and wondering what different
groups in the IETF might mean by "complex", my first thought was that
the IETF has never, ever solved one. For example, we do QoS in small
pieces that don't fi
25 matches
Mail list logo
