Sorry for the last minute nature of this email, but I was checking with
folks active in the standards bodies that use EAP-AKA.
After some conversations and thought, I think that the goal of limiting
the effects of compromised access network nodes and keys (should that
be clarified?) can be
On Mon, 6 Oct 2008, IESG Secretary wrote:
- A requirements document. This document will list requirements for
the ALTO service, identifying, for example, what kind of information
P2P applications will need for optimizing their choices.
...
I believe this work could be useful and would provide
Hoping openness succeeds ...
My name was submitted to the NomCom for the position of IAB member,
and I've told the NomCom I'm willing to be considered. Of course,
this is no guarantee that if I get selected, I'd still be able to
serve. Please send them whatever positive or negative
My name was submitted to the NomCom for the position of Apps AD, and
I've told the NomCom I'm willing to be considered. Of course, this is
no guarantee that if I get selected, I'd still be able to serve.
Please send them whatever positive or negative feedback you have.
--
Pete Resnick
Lakshminath Dondeti wrote:
Hi Enrico, Vijay,
Thank you for the summary of what transpired after the Dublin
meeting. I appreciate you taking the time.
Lakshminath: No problem. Thank you for your time and effort on
this.
My reading at the BoF was that there were some concerns about this
work
Narayanan, Vidya wrote:
I am surprised to see that ALTO is being proposed for a WG after the
last BoF concluded with no consensus whatsoever. I think a second
BoF is more appropriate than a WG on the topic at this time. That
said, I do see the need for this work, although I have some
On a related note, I'd like to make sure that you guys know that, as we
discussed in Dublin, the P4P Working Group is in the process of documenting the
P4P protocol as used in our field tests, which we would like to offer to the
ALTO group as input into the ALTO process. Our hope is to have
Marshall Eubanks wrote:
I support this moving forward. My reading of the room in Dublin was
that there was serious support for this and certainly a critical mass
to move forward.
Marshall: Thank you for your review. More inline.
Some comments in the charter below. This document clearly
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
So, a while ago a news article appeared on Google News as apparently
current but, when you actually looked at it, was a six year old
article about United Airlines filing for bankruptcy. UAL stock lost
$1B in value before the confusion was straightened out.
It's not that bad but right now if you
Hi Vidja, all,
I believe that the charter is narrow and broad enough to cover the
topic of ALTO, i.e., the charter is not limiting the solution space.
However, when reading your comments, it sounds that you have a very
specific solution in mind which is probably not covered by the
current
Dear Lakshminath,
I left Dublin thinking, out of the p2pi efforts, TANA will be
a WG (there was strong consensus and agreement on the problem
space and what needs to be done) and ALTO may have another
BoF. As of today, there is a WG proposal on the table for
ALTO and in a different area
Vidya: Thank you for your response and your time in helping
define the work. More inline.
Narayanan, Vidya wrote:
When we consider ALTO as a distributed service, there may not
necessarily be a host that specifically resolves the ALTO queries.
For instance, consider the case where ALTO is a
Hi Lakshminath,
and thanks for your review.
After some conversations and thought, I think that the goal of
limiting the effects of compromised access network nodes and keys
(should that be clarified?) can be achieved with fewer changes to AKA.
Fewer is better, lets talk about this.
I like
On 10/12/08 at 10:53 PM -0400, Donald Eastlake wrote:
if you do a Google News search for IETF you find two articles
listed with the claimed date of 15 September 2008 in the summary but
where the articles are actually quite a bit older.
They are both from ZDNet UK. I suspect that whatever it
On 2008-10-10 18:39, Thierry Moreau wrote:
Brian E Carpenter wrote, to multiple mailing lists of which
ietf@ietf.org is the only relevant as far as I am individually concerned:
On 2008-10-10 03:50, Olaf Kolkman wrote:
There are links to a number of process flow diagrams that may
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-pce-path-key-03
Reviewer: Ben Campbell
Review Date: 2008-10-13
IETF LC End Date: 2008-10-22
Summary:
This draft is almost ready for publication as a proposed standard. I
have a few
Hi Ben,
Thanks for the time and effort.
Responding as an author not as a WG chair...
Section 2.1, paragraph 3:
The last sentence is confusing. ...until the LSR that can process it.
does not seem to describe an event that one can wait until. Should it
say ...until it reaches the LSR...?
Brian E Carpenter wrote:
Like it or not, civil servants somewhere in an office called NTIA are
faced with the task of deciding about these (boring but required) DNSSEC
KSK scenarios.
Actually they have another option, which is to leave ICANN alone
to take the technical decisions for
On Oct 13, 2008, at 6:20 PM, Adrian Farrel wrote:
Hi Ben,
Thanks for the time and effort.
Responding as an author not as a WG chair...
Section 2.1, paragraph 3:
The last sentence is confusing. ...until the LSR that can process
it. does not seem to describe an event that one can wait
The IESG has approved the following document:
- 'Unicast UDP Usage Guidelines for Application Designers '
draft-ietf-tsvwg-udp-guidelines-11.txt as a BCP
This document is the product of the Transport Area Working Group.
The IESG contact persons are Magnus Westerlund and Lars Eggert.
A URL
The IESG has approved the following document:
- 'ForCES Forwarding Element Model '
draft-ietf-forces-model-16.txt as a Proposed Standard
This document is the product of the Forwarding and Control Element
Separation Working Group.
The IESG contact persons are Ross Callon and David Ward.
A
The IESG has approved the following document:
- 'Transmission Time offsets in RTP streams '
draft-ietf-avt-rtp-toffset-07.txt as a Proposed Standard
This document is the product of the Audio/Video Transport Working Group.
The IESG contact persons are Cullen Jennings and Jon Peterson.
A URL
The IESG has no problem with the publication of 'Guidelines for Using the
Privacy Mechanism for SIP' draft-munakata-sip-privacy-guideline-04.txt
as an Informational RFC.
The IESG would also like the IRSG or RFC-Editor to review the comments in
the datatracker
The IESG has received a request from the Enhancements to Internet email
to Support Diverse Service Environments WG (lemonade) to consider the
following document:
- 'LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using
Internet Mail '
draft-ietf-lemonade-architecture-03.txt as
25 matches
Mail list logo
