* Bernard Aboba:
My question is more why do they need EAP in situations where they are
not running at the link layer than why do they want or not want PANA.
The simple answer is that there are situations which IEEE 802.1X cannot
handle on wired networks. As specified, IEEE 802.1X is
Isn't this just a don't do that, then scenario? Plugging in a hub
tends to undermine much of the accountability 802.1X is supposed to
provide.
Sure, except that the cost of don't do that is rather high -- a switch
port for every host.
Anyway, 802.1X is terminally broken because end users
Robert Sayre wrote:
On 5/26/06, Geoff Huston [EMAIL PROTECTED] wrote:
Delving down a bit here, I suspect that, as always, the longstanding
issue
here is the actual level of 'independence of the RFC Editor, and the
potential for a player to perform an end run around the IETF Internet
I have been trying to post the following message last few days but failed.
Another try..
Subir Das wrote:
I have read both PANA protocol and PANA framework drafts. I understand
the concept and it is an useful protocol to me. In particular, EAP
over IP is necessary, IMO, and my understanding is
Hi Joel,
Reading the entire thread, I think we should seriously consider your
detailed suggestions to improve the PANA framework draft for broader
acceptance in the community.
Thank you,
Yoshihiro Ohba
On Tue, May 30, 2006 at 09:42:25AM -0400, Joel M. Halpern wrote:
I think the confusion and
I think the confusion and complexity that I perceive comes from the
fact that the framework problem treats all the tasks (user
authentication, network selection, and securing the network
connection as being of the same significance or same relationship to
the solution.
I think that most of
Lucy,
Thanks!
--
E
-- -Original Message-
-- From: Lucy E. Lynch [mailto:[EMAIL PROTECTED]
-- Sent: Friday, May 26, 2006 2:31 PM
-- To: Gray, Eric
-- Cc: Narayanan, Vidya; Sam Hartman; Bernard Aboba; ietf@ietf.org
-- Subject: RE: The Emperor Has No Clothes: Is PANA actually
Sam,
Thanks!
--
E
-- -Original Message-
-- From: Sam Hartman [mailto:[EMAIL PROTECTED]
-- Sent: Friday, May 26, 2006 5:20 PM
-- To: Gray, Eric
-- Cc: Narayanan, Vidya; Bernard Aboba; ietf@ietf.org
-- Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
--
--
Our findings of the schedule of other organization's meetings can be
found at: http://www.ietf.org/meetings/events.cal.html .
Regarding the ITU-T meetings,
would it be possible to specify the SG involved
rather than cryptically notating ITU-T.
I think that the only SGs of interest to many
Yoshihiro Ohba wrote:
Hi Joel,
Reading the entire thread, I think we should seriously consider your
detailed suggestions to improve the PANA framework draft for broader
acceptance in the community.
Which is strong hint that this discussion now belongs on the PANA
mailing list.
Brian
Sam,
However there needs to be a way for a member of this
community--whatever it is--to make a proposal, to get enough support,
and to have that proposal be adopted.
I.E. it is fine if the IAB of whomever can do a lot of things on their
own. However the community needs the ability to
On 05/30/2006 12:17 PM, Yaakov Stein allegedly wrote:
I also don't imagine that there are that many co-participants
of SG4 and IETF.
Well, we have at least one SG4 rapporteur who is pretty active.
___
Ietf mailing list
Ietf@ietf.org
Eliot,
I am not sure where the disagreement between what you're
saying and what Sam said earlier is - unless you're saying that
it is not necessary for the IETF to have an over-ride ability
on specific issues.
It would be nice if the IETF had a direct appeal to the
community
Look at draft-ietf-newtrk-docid-00.txt
This isn't really a chartering issue, IMHO.
Brian
Stewart Bryant wrote:
Robert Sayre wrote:
On 5/26/06, Geoff Huston [EMAIL PROTECTED] wrote:
Delving down a bit here, I suspect that, as always, the longstanding
issue
here is the actual level
As always, Eric, my concern is that we can overprocess things. In New
Jersey, where I come from, this usually involves hair. In standards
bodies it involves rules. Even the doc I put out about obsoleting well
known ports concerns me a little about adding process.
Eliot
I'm in complete agreement with Eliot (but that may be off point for the
general topic). In recent years the IETF has been struck by a
particularly virulent form of back seat driver syndrome which has not
only caused the community to believe they should second guess all
possible decisions, but
this summary is right on
E.g. the IAB should keep its hands off the independent submission
process at least with this channel
so is the rest of Mike's message
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Avi Lior wrote:
The statement regaring GEE and PANA was not made by me but rather by
your company! In order to sway support towards EAP over HRPD, Qualcom
made statements that PANA was dead at the IETF and that GEE will be
standardize at the IETF.
perhaps the IETF should have been consulted
This isn't really a chartering issue, IMHO.
I must strongly disagree here Brian - irrespective of any details of
implementation, the level of independence and discretion granted to the RFC
Editor to edit and publish documents that are not the outcome of the IETF's
peer review process is, I
the level of independence and discretion granted to the RFC
Editor to edit and publish documents that are not the outcome of the
IETF's peer review process is, I believe, a central matter in any
version of an RFC Editor Charter.
how could be any other way?
Scott
I think it is our collective responsiblity not to make false claims when
moving our agenda forward. This is true with any group.
Liaison should not be used for fact checking. This will create
extra-ordinary work for them. They have better things to do.
-Original Message-
From:
I think it is our collective responsiblity not to make false claims
when moving our agenda forward. This is true with any group.
Very much in agreement.
Liaison should not be used for fact checking.
Speaking as a liaison, this sort of fact checking (what is the real
status of WG X or
I suggest that people interested in this topic have a look
at draft-iab-liaison-guidelines-03.txt and send comments to
its author.
Brian
Thomas Narten wrote:
I think it is our collective responsiblity not to make false claims
when moving our agenda forward. This is true with any group.
--On Wednesday, 31 May, 2006 05:02 +1000 Geoff Huston
[EMAIL PROTECTED] wrote:
This isn't really a chartering issue, IMHO.
I must strongly disagree here Brian - irrespective of any
details of implementation, the level of independence and
discretion granted to the RFC Editor to edit and
The IESG has approved the following document:
- 'Experimental Procedure for Long Term Suspensions from Mailing Lists '
draft-hartman-mailinglist-experiment-03.txt as an Experimental RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group. It falls under
The IESG has approved the following document:
- 'The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR) '
draft-ietf-manet-dsr-10.txt as an Experimental RFC
This document is the product of the Mobile Ad-hoc Networks Working Group.
The IESG contact persons are Bill Fenner and
The IESG has received a request from the Inter-Domain Routing WG to consider
the following document:
- 'Graceful Restart Mechanism for BGP '
draft-ietf-idr-restart-11.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The Mobility for IP: Performance, Signaling and Handoff Optimization
(mipshop) working group in the Internet Area of the IETF has been
rechartered. For additional information, please contact the Area Directors or
the working group Chairs.
+++
Mobility for IP: Performance, Signaling and
A new Request for Comments is now available in online RFC libraries.
RFC 4485
Title: Guidelines for Authors of Extensions
to the Session Initiation Protocol (SIP)
Author: J. Rosenberg, H. Schulzrinne
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 4483
Title: A Mechanism for Content Indirection
in Session Initiation Protocol (SIP) Messages
Author: E. Burger, Ed.
Status: Standards Track
30 matches
Mail list logo
