$100 so far
And Dean is in my state so small claims is just down the road.
-Original Message-
From: ietf-honest-boun...@lists.iadl.org on behalf of Dean Anderson
Sent: Mon 3/23/2009 10:46 PM
To: John Levine
Cc: ietf-hon...@lists.iadl.org; ietf@ietf.org; dcroc...@bbiw.net
Subject: Re:
I suggest that all mail that is cross posted to Mr Andreson IETF-Honest or
whatever other spam list Mr Spammer decides to create be blocked from all IETF
lists.
That way any IETF-er who feeds the troll will not anoy the rest. And any
IETF-er who blacklists Mr Spammer and his spam lists will
I asked to be unsubscribed, he refused.
I have informed him that any further messages will be considered consulting
engagements and billed as such. I suggest everyone else does the same.
I am a professional chartered engineer. I offer consulting services at a
commercial rate. Anyone who
And this is inevitable as you cannot control use of technology by controlling a
registry.
IANA is a consensual illusion. It only has the power to assign names as long as
the community agrees that it performs that role. Patent encumberances must not
be used to deny IANA code points. If that
OK lets do a closer security analysis.
What is the asset at risk here? - The data on the hard drive
What is the risk? - Disclosure
So lets take a deperimeterized approach, what is the smallest security
perimeter that secures the assets? - Round the hard drive.
So one solution that many of us
ensure that there is almost no visible correlation
between the success of a protocol and progress in IETF process.
From: Stephan Wenger [mailto:st...@stewe.org]
Sent: Tue 3/10/2009 9:40 AM
To: Hallam-Baker, Phillip; Steven M. Bellovin
Cc: SM; r...@gnu.org; ietf
Institute the policy as you suggest and you have just given the patent
trolls the power to place an indefinite hold on any IETF proposal.
So instead of extorting payment for exercise of the claims they hold the
standard hostage.
-Original Message-
From: ietf-boun...@ietf.org
1) Patents happen, get over it.
Under the current patent system a company that does not apply for patents risks
finding that a patent troll has applied for their idea. This is perjury, it
should be prosecuted. But it is not. And fighting that type of lawsuit has cost
comapnies involved in
Steve,
Endorsment of a standard implies two (separable) assertions:
1) Do 'X'.
2) If you are going to do 'X', then do it by doing 'Y'
An experimental specification on the other hand contains the assertions
1) It might be desirable to do 'X'
2) It might be possible to do 'X' by doing 'Y'
When British Leyland shut down the assembly line for the Triumph TR7 they found
a note that said, 'Your proposal to prime and paint the TR7 bodyshells before
moving them a hundred miles in open rail cars to the assembly plant has been
made before. If only stopping rust was so simple'.
The
I doubt that this is a huge tool-builder issue. Lets not go looking for
problems.
I think moving the boilerplate is a good idea, particularly for people who are
still reading the TXT versions of the docs.
The only piece I would keep on the front page is the bit that says where
comments should
Indeed I recently read an indignant complaint from one country concerning
commercial espionage conducted by a second. Said conduct having been exposed by
the employment by similar espionage tactics by the first against the second.
-Original Message-
From: ietf-boun...@ietf.org on
I think that a rather more fundamental problem is the fact that the IETF
constitution prevents any organization or party speaking on behalf of the IETF
as a whole.
I agree that it would be rather better if the IAB could take on this particular
role than ISOC. But even the IAB can only
I don't see the value of running code quite as others do.
For me the value of running code is that the requirement to actually implement
stuff does tend to reduce the scope for complexity, you have someone in the
room pushing against something that will make work for them. And the other
Does this help?
http://www.bayarealaptops.com/
-Original Message-
From: ietf-boun...@ietf.org on behalf of Dearlove, Christopher (UK)
Sent: Mon 3/2/2009 5:04 AM
To: ietf@ietf.org
Subject: Terminal room at IETF74
I believe this to be on-topic for this list based on the
summary of
. This is
inevitable because there will be occasions where the intended authorization
policy for a resource is to allow through everything that is authenticated.
From: Stephen Kent [mailto:k...@bbn.com]
Sent: Fri 2/20/2009 2:49 PM
To: Hallam-Baker, Phillip
Cc: ietf
I already tried weaving that particular bright shiny object. plus the
suggestion that we move from a three stage standards process to two. And it did
not work.
Quick someone mention nazis.
From: ietf-boun...@ietf.org on behalf of Christian Huitema
Sent: Thu
Just as a matter of observation, there is not and never has been a security
requirement to rigidly separate authentication and authorization. Indeed there
is no real world deployment in which authentication and authorization are not
conflated to some degree.
The separation of authentication
Do you think that the IETF has changed direction though?
Methinks not.
This is one of those issues where there is a faction that will defend the
status quo regardless of the flaws that are revealed. They will wait till the
end of the discussion and announce that there is no consensus to do
I am somewhat concerned about the legal liabilities of such a board.
There are many types of patent encumberance, as with many other issues in a
consensus organization, the stupider the claim, the more difficulty it causes.
Lets look at some examples:
Case 1: DH/RSA
Patent here was
of their minions? I
think not.
-Original Message-
From: Powers Chuck-RXCP20 [mailto:chuck.pow...@motorola.com]
Sent: Wed 2/18/2009 5:32 PM
To: Hallam-Baker, Phillip; TSG; John Levine
Cc: ietf@ietf.org
Subject: RE: Previous consensus on not changing patent policy (Re:Referencesto
Redphone's patent
There is certainly something wrong, but the source is not necessarily the IETF.
The USPTO seems to be a bigger source of the problem here.
There are many problems with the current approach of leaving patent policy to
groups, not least the fact that case by case negotiation on a per-working
No, please do not go there.
You do not want negotiating flexibility in this type of situation. Instead of
looking how to arrive at a deal, the IETF needs to think about structuring the
incentives so that there is no gain for a patent troll.
-Original Message-
From:
. Moreover nobody can implement until the IPR issues
are fully understood.
-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
Sent: Fri 2/13/2009 6:40 PM
To: Hallam-Baker, Phillip
Cc: ietf@ietf.org
Subject: Re: How we got here, RE: References to Redphone's patent
Some points:
1) Open Source software and 'free software' as defined by the FSF are not the
same thing.
Historically, open source licenses such as BSD and Apache or in the case of
CERN libwww, a grant to the public domain have proved considerably more
effective than GNU copyleft.
The World
Could I just point out here the real risk that this relevant objection might
get lost in the sea of irrelevant aggitation from the FSF supporters?
From: ietf-boun...@ietf.org on behalf of Eric Rescorla
Sent: Tue 2/10/2009 11:57 PM
To: ietf@ietf.org
Subject:
I think Melinda makes a good point here.
The fundamental problem with these RMS-grams is that RMS has a longstanding
habit of working in write only mode. He makes little or often no effort to
determine what the situation is. I have in the past found him entirely
interested in responding to
It depends on what level you are looking at the problem from
In my opinion, application layer systems should not make assumptions that have
functional (as opposed to performance) implications on the inner semantics of
IP addresses. From the functionality point of view an IP address should be
feel that a lot of
the disagreement results from a misunderstanding of exactly what I
(and perhaps others who have made similar proposals) was proposing...
On Dec 4, 2008, at 10:29 PM, Keith Moore wrote:
Hallam-Baker, Phillip wrote:
I am trying to parse this claim.
Are you saying
Yes, that is indeed where the world is going.
My point is that it would be nice if the IETF had a means of guiding the
outcome here through an appropriate statement from the IAB.
Legacy applications are legacy. But we can and should push new applications to
use SRV based connections or some
From: John C Klensin [mailto:[EMAIL PROTECTED]
It was not clear from the context of the argument what was
being referred to. Seemed more likely that they were imaging
something involving more parties than bilateral. It was one of
those 'well people only disagree with me because they are
I am trying to parse this claim.
Are you saying that the DNS is fragile and raw IP relatively robust?
If so I can show you mountains of evidence to show that you are completely
wrong.
-Original Message-
From: [EMAIL PROTECTED] on behalf of Keith Moore
Sent: Thu 12/4/2008 1:23 PM
To:
There are really two separate questions here:
1) Should application developers write protocols that make assumptions as to
the Source/Destination IP headers remaining constant end to end?
2) Should NAT66 be prohibited in order to allow such assumptions to be made?
And then there is the
One of the topics that came up in the architectural debate is that a few folk
made statements of the form that application developers assume that
applications only engage in bilateral communications. In fact one person went
so far that applications developers are not aware of the range of
: John C Klensin [mailto:[EMAIL PROTECTED]
Sent: Tue 12/2/2008 10:43 AM
To: Hallam-Baker, Phillip; ietf@ietf.org
Subject: Re: Applications assume bilateral connections?
--On Tuesday, 02 December, 2008 07:04 -0800 Hallam-Baker,
Phillip [EMAIL PROTECTED] wrote:
One of the topics that came up
Why should anyone care if an internal network is on IPv6 or not? That is
probably the silliest part of the NAT66 debate. I am only going to be deploying
IPv6 for the few hosts that actually need to receive inbound connections. And I
don't expect that to be more than a few hosts on a home
Right, the DNS is no longer providing mere hostname mapping and host discovery,
it is providing service mapping and service discovery.
[EMAIL PROTECTED] does not connect to an IP address, the outgoing email server
first attempts to resolve MX records.
What we are discussing here is
Well technically you are right, but you are still wrong :-0
I know you can get IPv4 on a controller. But I think you will need more than
1kB for IPv6 since IPSEC is required... And IPSEC requires public key on the
controller.
Yes there are bigger processors, but what I am interested in doing
: Mark Andrews [mailto:[EMAIL PROTECTED]
Sent: Wed 11/26/2008 5:40 PM
To: Hallam-Baker, Phillip
Cc: Eric Klein; Fred Baker; [EMAIL PROTECTED] WG; IAB; IETF Discussion; [EMAIL
PROTECTED]; IESG IESG
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
applicationdevelopers
In message
It is quite easy to see how an application that is designed to tolerate
renumbering is able to cope with it given appropriate O/S and protocol level
support. I suspect what is happening there is that SSH loses the connection and
then transparently attempts to reconnect before telling the user
Again, there needs to be an expectations reset here.
The pro-NAT faction are not 'asking' for anything. They are serving notice that
this is the approach that they intend to take.
You are saying, 'you can beg for your NAT but I am not giving it to you, now go
away'. They are saying, 'I do not
[Behave dropped, this is an architectural level discussion. If we don't want
this on ietf we should start a different forum]
I don't think that this claim is right: Promoters of NAT, particularly
vendors, seem to have a two-valued
view of the network in which inside is good and outside is
Could we agree on a consensus point that:
'Any application developer who designs a protocol on the assumption it will not
be subject to NAT66 may be disappointed'
I think that it is beyond rational argument to claim otherwise. Furthermore, if
it is really the interests of application layer
The problem here is that the Behave group seems to have people who are making
IETF wide policy. So that is why opponents of the behave position think that
the appropriate forum is the IETF list.
Behave can decide not to do a NAT66.
But what they cannot do is to decide that NAT66 should be
Eric,
The problem here is that you assume that the IETF has decision power that can
magic away NAT66. Clearly it did not for NAT44 and will not for NAT66.
So the real question for App designers is:
1) Should they design protocols that assume no NAT66
2) Should they regard the assumption
Keith More writes:
I don't think so in either case. The reason I don't think so is that I
suspect the NAT traversal problem is really a firewall traversal problem
in disguise.
Absolutely, and that is why there needs to be a permissions system that allows
effective decisions to be made
I don't quite understand what you men by this.
My internal DNS for the house does not reveal the existence of any of the
machines to the outside world. Multiple horizons have been a feature of DNS for
decades now.
The only thing global about DNS is that there is only one consensus holder of
when it is not. Making use of that cheap energy is going to mean moving the
computing effort to where the power is.
From: Ned Freed [mailto:[EMAIL PROTECTED]
Sent: Wed 11/26/2008 12:17 PM
To: Hallam-Baker, Phillip
Cc: Eric Klein; Fred Baker; behaveietforg WG; IAB
and let others propose a replacement if there is a genuine need.
From: Keith Moore [mailto:[EMAIL PROTECTED]
Sent: Thu 11/13/2008 6:03 PM
To: Hallam-Baker, Phillip
Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG;
[EMAIL PROTECTED
, Phillip
Cc: Keith Moore; Behave WG; IETF Discussion; Routing Research Group Mailing
List; Eric Klein; Mark Townsley
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?
On 13 nov 2008, at 23:50, Hallam-Baker, Phillip wrote:
The most successful Internet protocols do not involve connections
This is a somewhat silly discussion, pretty much the ONLY real reason to use
your own domain rather than a gmail or aol or whatever is precisely the fact
that switching costs are high.
And the real problem is not gmail.com but comcast.net. If access to the email
address requires continuation
I beleive that the question would not arise If we had a coherent Internet
architecture
The idea that an application can or should care that the IP address of a packet
is constant from source to destination is plain bonkers. It was no an
assumption in the original Internet architecture and
Who cares about the use measurement?
I care about the proportion of the Internet where I can obtain acceptable
service with full functionality via an IPv6-only endpoint connection.
From: [EMAIL PROTECTED] on behalf of David Kessens
Sent: Wed 11/12/2008 4:28 PM
, Phillip
Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG;
[EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?
On 11/13/08 10:06 AM, Hallam-Baker, Phillip allegedly wrote:
I beleive that the question would not arise If we had
before that
book came out).
From: Eric Klein [mailto:[EMAIL PROTECTED]
Sent: Thu 11/13/2008 2:07 PM
To: Hallam-Baker, Phillip
Cc: Mark Townsley; Routing Research Group Mailing List; Behave WG; [EMAIL
PROTECTED]; ietf@ietf.org
Subject: Re: [BEHAVE] Can we have
if the other side has queued up RCPT
and DATA commands in the HELO packet.
From: [EMAIL PROTECTED] on behalf of Chris Lewis
Sent: Thu 11/13/2008 3:52 PM
Cc: IETF
Subject: Re: IP-based reputation services vs. DNSBL (long)
Hallam-Baker, Phillip wrote:
To answer your
Since I have been critical of the insistence on a new RR in other contexts, I
will give the reasons why I am unconvinced in this particular case and indeed
would argue that a specific RR would be more effective.
First, let us consider the reasons why you might want to re-use an RR rather
than
[mailto:[EMAIL PROTECTED]
Sent: Thu 11/13/2008 4:34 PM
To: Hallam-Baker, Phillip
Cc: [EMAIL PROTECTED]; Behave WG; IETF Discussion; Routing Research Group
Mailing List
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?
On 13 nov 2008, at 22:15, Hallam-Baker, Phillip wrote:
Well yes
:[EMAIL PROTECTED]
Sent: Thu 11/13/2008 5:28 PM
To: Hallam-Baker, Phillip
Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG;
[EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?
Hallam-Baker, Phillip wrote:
I beleive
It looks to me as if these are developer and interoperability issues that are
not going to be addressed of their own accord through regular IETF meetings.
I think that the only way we could expect progress here would be to have a
series of interop events that involve representatives from all
Agree with your conclusion but your statement is not quite accurate.
Some spammers have in fact developed schemes that involve spoofing the source
IP address of TCP sessions, but only where both IP addresses were under spammer
control.
What some spammers used to do when dialup connections
Well, we have a critical dependency on a star that is going to run out of
hydrogen at some point...
From: [EMAIL PROTECTED] on behalf of Dave CROCKER
Sent: Tue 11/11/2008 10:42 AM
To: [EMAIL PROTECTED]
Cc: ietf@ietf.org
Subject: Re: IP-based reputation
Did a ping this morning from my residential broadband, was surprised to see
responses from an IPv6 address.
Woo-hoo!
Only small problem is the complete lack of IPv4.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
There was indeed a major struggle over the standardization of the light bulb
socket. And the sad part is that due to patent encumberances the US
unfortunately ended up with the inferior product!
Neither Swan nor Edison thought much about the mount. It was Swan's brother who
did most to refine
are your friend.
That said, any new protocol would have to use the DNS and MIME content types at
a minimum.
From: John C Klensin [mailto:[EMAIL PROTECTED]
Sent: Tue 10/28/2008 1:12 PM
To: Hallam-Baker, Phillip; Andrew G. Malis
Cc: [EMAIL PROTECTED]; IETF Discussion
We have made changes of this nature in the past.
For example, last time this issue came up the solution that was defacto adopted
was to impose term limits. I don't necessarily think term limits are the best
solution but there was a definite probem of long term incumbency in certain
particular
Looks good, but needs some smitthing.
I think that the sense that I would want is:
* Whenever the keywords are used they are to be considered normative
* Whenever the keywords are used they SHOULD be capitalized
* Editors SHOULD avoid use of normative keywords for non-normative language,
even
requirements for those protocols are met.
* You SHOULD specify test vectors
* You MAY include code that implements the algorithm
And so on.
From: John Levine [mailto:[EMAIL PROTECTED]
Sent: Tue 7/1/2008 11:40 AM
To: ietf@ietf.org
Cc: Hallam-Baker, Phillip
Subject
Another like restriction that might be investigated is whether
http://microsoft/ or other similar corporate TLDs would work as intended with
deployed legacy browsers.
I suspect (but have not tried) that if you simply type 'Microsoft' into the
address bar of some browsers you might have the
Just register .local and do not assign it in the same way that 10.x.x.x and
192.168.x.x are registered.
From: [EMAIL PROTECTED] on behalf of Joe Abley
Sent: Fri 6/27/2008 4:31 PM
To: David Conrad
Cc: SM; ietf@ietf.org
Subject: Re: Update of RFC 2606 based on the
Todd,
This is nonsense, stop it.
Of course IETF communications could give rise to the posibility of criminal
prosecutions in certain circumstances. The IESG could in theory plot a murder.
That does not mean that every legal concotion you imagine is backed by
criminal sanctions. On
Some points:
1) If the objective is to have a URN for RFCs this has already been done:
RFC 2648: http://www.ietf.org/rfc/rfc2648.txt A URN Namespace for IETF
Documents
These identifiers must be the canonical identifiers for the RFC series. But
they need not be the only identifiers.
2)
I would rather pay $1 to provide bigger, better cookies or tap-dancing penguins
during the plenaries.
I see no value in doing this and in fact plenty of reasons to oppose it.
Where is the $1500 of value to the IETF here? I can see the value to DOI. If
the IETF were to go this route it
So? The rules of academic citation are broken. Take a look at their idiotic
criteria for citing web pages.
Unfortunately the folk who designed the reference manager for office 2008 made
the mistake of taking them seriously. It is not possible to cite urls for
articles as a result.
Sent
Actually this represents currently accepted engineering practice in the
usability field.
According to Nielsen you can identify 80% of issues with small scale
studies of 5 people. The point here is not to create a statistically
representative sample, it is to identity the chief issues that may be
I don't think it is helpful for the IETF to describe its work product as
'flavor-of-the-month'.
DKIM is an IETF Proposed Standard.
Using DKIM is thus a dog-food issue. SPF/Sender-ID on the other hand are
arguably not at the same status but there is a general consensus amongst the
spam
I would suggest that the IESG also think about hosting all IETF lists in
house in the future.
The main reason for this is legal, a list that is maintained by the IETF
is much more satisfactory in a patent dispute than one run by a third
party. Last thing we want is to have patent trolls dragging
.
I would suggest doing this gradually by making in house maintenance a
requirement for all new lists as they are created.
-Original Message-
From: Russ Housley [mailto:[EMAIL PROTECTED]
Sent: Monday, April 14, 2008 10:25 AM
To: Hallam-Baker, Phillip
Cc: ietf@ietf.org; [EMAIL
.
And begging the question is a logical fallacy in which the conclusion is
assumed in the premise, petition principii.
From: Tony Hain [mailto:[EMAIL PROTECTED]
Sent: Wed 26/03/2008 6:59 PM
To: Hallam-Baker, Phillip; ietf@ietf.org
Subject: RE: Last Call: draft
The key issue here is whether people who rely on are likely to
achieve their desired result. Today it does not matter because anyone
who relies on alone with no A fallback is going to receive almost
no mail.
That in turn is going to depend on whether software implementations are
written
I don't undestand the reasoning here.
My understanding is that we implicitly deprecated receivers relying on fallback
to A in 2821. Section 5 makes it clear that you look for MX first and that MX
takes priority.
It is thus not compliant to look at records today and I see no reason to
It is pretty clear here that we are talking about a configuration that is
actually specfically prohibited by 2821.
If you are doing SMTP and claiming to be 2821 compliant you must lookup the MX
and you must not look at the A if there is no MX there. Any sender that is
breaking those rules is
would make it
incumbent on us to fix the same problems in our protocols.
-Original Message-
From: Patrik Fältström [mailto:[EMAIL PROTECTED]
Sent: Mon 24/03/2008 10:30 PM
To: Hallam-Baker, Phillip
Cc: Russ Housley; IETF Discussion
Subject: Re: Write an RFC Was: experiments in the ietf
with human subjects
criteria.
Its not much of a security experiment if you only measure whether people can
deploy it.
From: Andrew G. Malis [mailto:[EMAIL PROTECTED]
Sent: Tue 25/03/2008 9:05 AM
To: Patrik Fältström
Cc: Hallam-Baker, Phillip; IETF Discussion
Subject
If someone participates under a pseudonym with the objective of inserting
patented technology and anyone finds out they are in big trouble. Much worse
than any prior case.
The much bigger problem is people who read an rfc and write out a patent
application over it. It has happened and people
These claims are meaningless to me. Transport and network layer security have
distinct objectives and purposes. They are not replacements or interchangeable
in any sense.
If you beleive that there is an attack that SSL is vulnerable to you should
bring it up in TLS.
In general the higher
Enough, already.
If we are going to have experiments in IETF week then lets do the thing right
and have a process. In particular -
Proposer MUST write an Internet Draft prior to the experiment stating:
1) Purpose - the information to be obtained
2) Method - what it to be done
3) Resources -
Well I would submit that there is a major problem there on the security
usability front.
Don't make me think. My tolerance for network configuration is vastly greater
than the typical user.
This has to all just work, just like my Apple Mac did on the home network the
day I bought it. Not
. I have no trust anchor.
-Original Message-
From: Russ Housley [mailto:[EMAIL PROTECTED]
Sent: Mon 24/03/2008 3:22 PM
To: Hallam-Baker, Phillip
Cc: IETF Discussion
Subject: Re: Write an RFC Was: experiments in the ietf week
Phillip:
Have you tried the SSID at the IETF meetings
Lets look at this from a security usability point of view.
The whole nomcon process is opaque, all meetings and discussions are secret.
Requests for comment are solicited in confidence. Given those circumstances it
is a reasonable assumption for a participant to make that all nomcon actions
But what is an 'obvious mistake in the result'?
All I can think of is that the Nomcon would make a choice that the confirming
body found controversial. While that might be because the ten momcon members
somehow managed to remain ignorant that a particular person was incompetent,
had a felony
Well there you hit the problem of the status-quo veto. The most effective
aspect of the IETF constitution is that it is essentially impossible to
overturn the status-quo without arriving at a 'consensus', the existence of
which is judged by the incumbent establishment.
We cannot apparently
The minutes of that meeting are online, its pretty much the point at which the
system then broke for many years:
http://www.iab.org/documents/iabmins/IABmins.1992-06-18.html
Understanding this particular history is rather helpful if you want to
understand the early history of the World Wide
I think you have the whole confirmation process backwards.
If you start from the premise that the absolute priority is to keep control in
the hands of the establishment you naturally arrive at a need for at least two
bodies arranged so that each acts as a guardianship council to the other.
It occurs to me that a protocol of this type might well have been used to
effect by the recently reired governor of a nearby state to ensure that his
communications were in strict compliance with certain regulations that enforce
certain geographic routing restrictions.
Sent from my GoodLink
the economics of deployment is a critical part of deploying the solution. Ross
Anderson has some resources on this topic.
-Original Message-
From: [EMAIL PROTECTED] on behalf of Hallam-Baker, Phillip
Sent: Sat 08/03/2008 9:18 PM
To: Jeroen Massar; Patrik Fältström
Cc: IETF discussion list
(www.good.com)
-Original Message-
From: Patrik Fältström [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 09, 2008 06:49 AM Pacific Standard Time
To: Hallam-Baker, Phillip
Cc: Jeroen Massar; IETF discussion list
Subject:Re: Was it foreseen that the Internet might handle 242
The problem with multicast in this application is that it only works if all the
clients are accepting the same data stream and viewing it live.
That's not how people tend to view Web video, there might be 50% of the crowd
watching it as Oprah speaks but the rest are likely to be time shifted
I have changed the subject line to reflect the fact that the IAB chair informs
me that this is in fact a consultation period and not as was indicated in the
original subject line a report of a decision already taken.
The list of comments does not include my core objection made in the 'Domain
The IAB tracker indicated this document was dead, now we are told that
publication is imminent. Why?
Do we get to ask the author to address the other proposals that have been made
to address this issue (XPTR) or does it just get published regardless of
whether the claims made are true or not?
1 - 100 of 713 matches
Mail list logo
