What fascinates me about p2p is that it was clearly the
next Big Thing, but there seems to be no feedback loop
operating whatsoever.
At the risk of birthing a much unwanted tangent, I think it would have been
somewhat egocentric for the IETF to do anything that lent legitimacy to the
p2p
Michael Thomas wrote:
Scott W Brim wrote:
On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote:
At 1:50 PM -0700 9/15/05, Michael Thomas wrote:
Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and
Behalf Of Brian E Carpenter
Up to a point, but there are limits to what we can do.
We can request that the RFC Editor not publish things we
think are damaging. The IESG does this a few times a year.
Similarly, we can request that IANA not register things we
think are damaging, or at
Scott W Brim sbrim@cisco.com writes:
The metaphor I'm trying to use this week is that the IETF is
landscapers and we provide a fertile, beautiful area for people to go
wild and create excellent gardens.
Exactly. The beauty of TCP/IP (and indeed many protocols when done
well) is that they are
Hallam-Baker, Phillip wrote:
Behalf Of Brian E Carpenter
Up to a point, but there are limits to what we can do.
We can request that the RFC Editor not publish things we
think are damaging. The IESG does this a few times a year.
Similarly, we can request that IANA not register things we
Brian writes
Sigh. That's exactly my point; our stewardship role is really
limited to advocacy and to providing better altermatives. I
don't see where you can find special pleading, vast
political influence, force or anointed in what I wrote.
I think we would do well to avoid polemic
In message [EMAIL PROTECTED], Brian E Carpenter writes:
Michael Thomas wrote:
Perfect. And then someone with less clue decided to
plant Kudzu. We have nothing to say about that?
I just read today that kudzu extract may reduce the desire
for alcohol (Scientific American, 8/2005, p 17). What
On Sep 16, 2005, at 3:29 PM, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Brian E Carpenter
writes:
Michael Thomas wrote:
Perfect. And then someone with less clue decided to
plant Kudzu. We have nothing to say about that?
I just read today that kudzu extract may reduce
From: Gray, Eric [mailto:[EMAIL PROTECTED]
Philip,
Apology in advance if this seems to be removed from
context, but your statement (below) seems to have been made
generally and is
not self consistent. Perhaps you could clarify it somewhat?
--- [ SNIP ] ---
--
-- Sure
Generally, the existence of an assignment authority does encourage
its (proper) use - mostly for the reason you state above. Just as
nobody will want to accept an official registration polluted by
prior use, nobody (deliberately in quotes) will want to attempt
to establish an unofficial
Brian E Carpenter wrote:
Michael Thomas wrote:
I know that we aren't the net.cops, but are we not
net.stewards either?
Up to a point, but there are limits to what we can do.
We can request that the RFC Editor not publish things we think
are damaging. The IESG does this a few times a year.
Behalf Of Michael Thomas
This is more or less what I had in mind. Correct me if
I'm wrong, but http 1.0 wasn't the invention of the ietf,
but sprang forth outside of its purview. Http 1.1 was a
response to the many difficulties placed on the net because
of http 1.0, and there was an
If you want to discuss this as a generic issue, please do so
with an appropriate subject and without cross posting. Thanks.
BTW I agree that there is a generic architectural issue here
that merits discussion.
Brian
Michael Thomas wrote:
Ned Freed wrote:
Ned Freed wrote:
If I were to
Paul Hoffman wrote:
At 5:32 PM -0700 9/14/05, Michael Thomas wrote:
You mean we could invent Bitorrent? :)
BitTorrent (note the spelling) does a lot of very nice things, but not
those. For those interested, the BitTorrent protocol is described at
http://www.bittorrent.com/protocol.html.
At 1:50 PM -0700 9/15/05, Michael Thomas wrote:
Always the risk when one is being flippant, but I only
meant that the world outside of ietf seems to be taking
on a lot of these issues without ietf's advice and consent.
Fully agree.
In this case, there is no advantage to the developer of the
On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote:
At 1:50 PM -0700 9/15/05, Michael Thomas wrote:
Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably considers ietf
old and in the
Paul Hoffman wrote:
At 1:50 PM -0700 9/15/05, Michael Thomas wrote:
Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably considers ietf
old and in the way?
Not sure why this is an
Scott W Brim wrote:
On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote:
At 1:50 PM -0700 9/15/05, Michael Thomas wrote:
Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably
On 16-sep-2005, at 1:00, Michael Thomas wrote:
I'm not sure; maybe it's really a mutual non-admiration
society, and everybody's happy? But it's an elephant
insofar as it's pretty darn big trafficwise, and the
fact that ietf doesn't seem concerned?
Why should the IETF be concerned
Eliot Wes received the obvious feedback that operators find SNMP
Eliot unusable with the USM model because they cannot integrate it
Eliot with their existing security infrastructures and there is no
Eliot denying that this is a real problem. But this is NOT the only
Eliot problem operators face
Ned Freed wrote:
If I were to object to Eliot's proposal (I don't - in fact I strongly
support
it), it would be on the grounds that the IETF should be taking a long
hard look
at the issues surrounding call home in general, not just in the special
case of
SNMP.
I'll bite: what could the IETF
Ned Freed wrote:
If I were to object to Eliot's proposal (I don't - in fact I strongly
support
it), it would be on the grounds that the IETF should be taking a long
hard look
at the issues surrounding call home in general, not just in the special
case of
SNMP.
I'll bite: what could the
Ned Freed wrote:
Ned Freed wrote:
If I were to object to Eliot's proposal (I don't - in fact I strongly
support
it), it would be on the grounds that the IETF should be taking a long
hard look
at the issues surrounding call home in general, not just in the special
case of
SNMP.
I'll
At 5:32 PM -0700 9/14/05, Michael Thomas wrote:
Ned Freed wrote:
Such a third party would act as a repository for update information
provided by
vendors. Applications would then call home to one of these repositories
rather than directly to the vendor. Various anonymyzing tricks could be
: Monday, September 12, 2005 8:36 PM
To: Eliot Lear; Sam Hartman
Cc: [EMAIL PROTECTED]; IETF Discussion; iesg@ietf.org
Subject: Re: [Isms] ISMS charter broken- onus should be on WG
to fix it
Eliot,
At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for
integrating SNMP
Dave,
I support the alternative you are recommending.
Thanks,
Keith.
As primary editor of the SSH draft (SSHSM), I spoke with Eliot last
week. I agree that it is difficult for him to develop a reasonable
proposal that piggybacks on the SSH draft, because the SSH draft is so
incomplete.
I
Juergen,
Wes received the obvious feedback that operators find SNMP unusable with
the USM model because they cannot integrate it with their existing
security infrastructures and there is no denying that this is a real
problem. But this is NOT the only problem operators face with SNMP.
While the
David == David B Harrington [EMAIL PROTECTED] writes:
David Hi, Personally, I'd rather see the issue of working through
David NATs and firewalls solved at the SSH level, and then SNMP
David and other SSH-using applications, such as Netconf and CLI,
David could use the solution in
David == David B Harrington [EMAIL PROTECTED] writes:
David Hi, As primary editor of the SSH draft (SSHSM), I spoke
David with Eliot last week. I agree that it is difficult for him
David to develop a reasonable proposal that piggybacks on the SSH
David draft, because the SSH
Juergen Quittek writes...
It [call home] looks like a good topic for a BoF session in the
OaM area.
There we could find out the relevance of the problem and discuss
requirements for potential solutions. Also there we can identify
which working group would be the right one to deal with the
On Tue, Sep 13, 2005 at 02:31:54PM -0400, Sam Hartman wrote:
David == David B Harrington [EMAIL PROTECTED] writes:
David Hi, Personally, I'd rather see the issue of working through
David NATs and firewalls solved at the SSH level, and then SNMP
David and other SSH-using
Juergen == Juergen Schoenwaelder [EMAIL PROTECTED] writes:
Juergen Sam,
Juergen this is not about blocking port 22 as far as I understand
Juergen things. I think the issue here is that TCP connection
Juergen establishment determines ssh client/server roles. If
Juergen there
On Tuesday, September 13, 2005 05:06:40 PM -0400 Sam Hartman
[EMAIL PROTECTED] wrote:
Juergen == Juergen Schoenwaelder [EMAIL PROTECTED]
writes:
Juergen Sam,
Juergen this is not about blocking port 22 as far as I understand
Juergen things. I think the issue here is that TCP
On Tue, Sep 13, 2005 at 05:06:40PM -0400, Sam Hartman wrote:
I would support setting up port forwarding as a way to get a back
channel; I would also support a facility to run an ssh protocol over
ssh channel.
One advantage of both port forwarding and ssh over ssh is that they
provide a
On Tuesday, September 13, 2005 05:06:40 PM -0400 Sam Hartman
[EMAIL PROTECTED] wrote:
Juergen == Juergen Schoenwaelder [EMAIL PROTECTED]
writes:
Juergen Sam,
Juergen this is not about blocking port 22 as far as I understand
Juergen things. I think the issue here is that
On Tuesday, September 13, 2005 05:23:26 PM -0700 Ned Freed
[EMAIL PROTECTED] wrote:
I suspect that the ssh community would decline to extend ssh in this
direction; I certainly know I would not support it.
I'm not entirely sure _how_ I'd extend SSH in this direction, or how much
utility
36 matches
Mail list logo
