On Mar 29, 2006, at 10:56 AM, Henning Schulzrinne wrote:
We could ask the IEEE, since the relationship between the WiFi
folks and IEEE 802.11 seems to be somewhat similar.
One of the problems I see is that many of the industry associations
(SIP Forum, IPv6 forum, to name two I'm somewhat
We could ask the IEEE, since the relationship between the WiFi folks and
IEEE 802.11 seems to be somewhat similar.
One of the problems I see is that many of the industry associations (SIP
Forum, IPv6 forum, to name two I'm somewhat familiar with) tend to focus
on service providers, not
Dear All,
My apologies for not being clearer - my intention was not to criticize WG or
IAB actions in the past, but to point out that we are now in an escalating
game of whack-a-mole with our applications as the moles that NATs and FWs
are finding new ways to frustrate.
The security guys
On 3/27/06 6:45 AM, Spencer Dawkins [EMAIL PROTECTED] wrote:
My apologies for not being clearer - my intention was not to criticize WG or
IAB actions in the past, but to point out that we are now in an escalating
game of whack-a-mole with our applications as the moles that NATs and FWs
are
Traditionally, it was sufficient for the IETF to publish an RFC
specifying requirements or behavior; the purchasing process, through
RFIs and RFPs, then cited the long list of RFCs, essentially creating
the protocol police force that the IETF doesn't have.
That list-of-RFC-numbers approach is
I think Henning and I are saying the same thing (he's just saying it
better).
From: Henning Schulzrinne [EMAIL PROTECTED]
Trying to devise ever more elaborate NAT traversal mechanisms that include
sending keep-alives every few seconds and various let's try this and then
that algorithms
John, everyone,
I think it's fair to say that the IAB has heard the concern
at this point -- about the net neutrality issue, and the desire
to see some concrete IAB action.
I've also seen a fair bit of discussion about what an appropriate
stance *is*, and whether or how to express it as a
On 3/25/06 7:47 PM, Spencer Dawkins [EMAIL PROTECTED] wrote:
So my point was, I'd really like to take a chance on some IAB statements
about things that need to be stated about our architecture. They might be
ignored. Would the result be any worse?
This is a somewhat bothersome case, because
On 24 mar 2006, at 18.07, Hallam-Baker, Phillip wrote:
If I am going to send a copy of a $200 million action movie to a
viewer I am
going to expect to be paid for that. The viewer is going to expect
a high
quality viewing experience. The problem is that the bandwidth they
subscribe
to for
Geoff, things were indeed different then, as long distance
bandwidth costs were a serious concern. That has changed. I think
the fact that content providers who are paid for that content
don't (in effect) pay for the congestion that they cause hasn't
changed. But mainly I was interested to see
--On Friday, 24 March, 2006 16:28 -0600 Scott W Brim
sbrim@cisco.com wrote:
On Fri, Mar 24, 2006 05:00:07AM -0500, John C Klensin
allegedly wrote:
There are two strategies that make more sense and have more
chance of success. One is precisely what 4084 attempted to
do: lay out
On Sat, Mar 25, 2006 at 05:56:09PM +0100, Patrik F?ltstr?m wrote:
Only path forward is, I think, that end users start to demand better
service, and the ones that do are prepared on paying more. Like if
you just want broadband, buy blue service, but if you want better
quality, buy red service
--On Saturday, 25 March, 2006 12:54 -0500 Jeffrey I. Schiller
[EMAIL PROTECTED] wrote:
The problem is how do we differentiate between cases where
content providers pay to get a higher then default QOS for
their streams vs. the case where the provider pays to prevent
the ISP from
Brian,
Actually the document I referenced is also around 9 years old - so even then
we were having a Fine Debate about settlement systems in this industry.
The introduction of Content into this debate has also been interesting
with the earliest intersection of the two groups (ISPs and content
I don't mean to hijack this conversation, only add a data point...
I have a great deal of respect for the people who have done the heavy
lifting in BEHAVE, but it seems like every time we meet, someone discovers a
new and previously un-observed NAT behavior that Is Not Helpful. This week
was
Tony,
I agree completely and believe the IAB has, of late, been
altogether too timid in this area.
I think you know all of what I'm about to say, but your note is,
IMO, easily misread, so an additional observation about 4084 and
its potential relatives: In this sphere, a document that says
May be if you think the other way around, you reinvent the Minitel model?
Not sure as the final text is not voted and is _very_ confused, but
this _may_ be what the French DADVSI law _may_ lead to.
jfc
At 18:07 24/03/2006, Hallam-Baker, Phillip wrote:
Content-class:
maybe I can summerize John's note by asking if this IAB has the
will to write a RFC 1984 about net neutrality
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I know I'm going to regret saying this, but we haven't made much progress
in ten years.
http://tools.ietf.org/id/draft-carpenter-metrics-00.txt
I got a lot of interest in that draft, none of which came from
ISPs...
Brian
Hallam-Baker, Phillip wrote:
I think that people need to consider that
On Fri, Mar 24, 2006 05:00:07AM -0500, John C Klensin allegedly wrote:
There are two strategies that make more sense and have more
chance of success. One is precisely what 4084 attempted to do:
lay out categories and boundaries that, if adopted, make better
information available to
To quote from the Carpenter draft:...
One approach to resolving the current crisis in Internet
performance is to institute an efficient system of
inter-carrier settlements.
Progress is often hard when you are heading in off in the weeds.
Try
I didn't make it to the mic fast enough at the end, but Brian's comment
about the proposal to outlaw diffserv actually gets to the heart of why the
IAB needs to take specific stands and make public comments. Telling the
telco's they are evil is not the point. General statements of principle or
This directly relates to the Skype discussion during the plenary. Skype
will, if necessary, tunnel media on port 80 and port 443.
To some extent, the debate also highlights a lack of usable protocol
tools: One reason, albeit likely not the only one, that there is talk
about per-source
23 matches
Mail list logo