Eric,
Thanks for your comments. A couple of responses inline:
I think there's a more meta-issue here: do we think it would be good
for the IETF to have more WGs? If the answer is yes, then it makes
sense to foster new work in various ways. If the answer is no then
it makes sense to treat
On Sun, Oct 07, 2007 at 11:07:36AM -0400,
Livingood, Jason [EMAIL PROTECTED] wrote
a message of 48 lines which said:
Those who took the survey will have noticed (and this is available
in the downloadable results) that we in fact had listed a U.K.
choice as well as a Continental Europe
SM wrote:
Spam can pass SPF, Sender-ID and are even DK and DKIM signed
nowadays. One can't blame spammers for not being early adopters. :-)
TMDA may cause backscatter.
After an SPF PASS the backscatter by definition can't hit an
innocent bystander. By the same definition any backscatter
As I was reading this document, I realized that I didn't understand
what it was for.
As I understand it, this document embeds IKEv2 into EAP. Why is this a
good idea? As I understand the situation, EAP already supports a
TLS-based authentication mechanism, which allows it to do both
public-key
At Mon, 08 Oct 2007 10:03:35 +0300,
Jari Arkko wrote:
But the issues with scheduling, lack of attention for important
topics, and low quality of new work proposals are real concerns.
I have a slightly different take on this than what you had above,
however.
INT is probably the most
Inline please,
Eric Rescorla wrote:
At Mon, 08 Oct 2007 10:03:35 +0300,
Jari Arkko wrote:
But the issues with scheduling, lack of attention for important
topics, and low quality of new work proposals are real concerns.
I have a slightly different take on this than what you had above,
If I understand the purpose of this experiment it would be to provide
ADs some indication of level of interest and ability to succeed. I see
no reason why we need to formalize this within the IETF. Furthemore,
the terminology is problematic. We are overlapping a term that is
commonly used by
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:
The way I see it the problem that this proposal tries to solve is about
helping the IESG and the community to make a better decision when the
forming of the working group us discussed. It is not about bringing more
work to the IETF, it is about making sure to a better extent that the
right work is
I have seen the functioning of SGs at the IEEE and agree that they can be
useful, but I'm not sure about how it is being translated into the IETF
It occurs to me that we don't need to invent a new process here. The IRTF
houses different types of research groups: some are meant
to be
Gabriel,
It occurs to me that we don't need to invent a new process here. The
IRTF houses different types of research groups:
We don't _have_ to invent new process -- in addition to IRTF
RGs, there's obviously the default option of keeping post-BOF /
pre-WG efforts outside the formal IETF
I have been somewhat troubled at the discussion about the SG draft and proposed
experiment, and I think part of the reason is that there's a range of leashes
being envisioned, with everything from study groups are where the villagers
riot to the process for forming a study group is
Dear Colleagues,
The IAB has discussed the study group experiment proposed in draft-
aboba-sg-experiment-02.txt.
The IAB does not oppose a scoped experiment.
However, As the IAB reviews BOFs and WG charters (see RFC 2850
section 2.1) as part of its architectural oversight function, we
Thanks Jari, Eric. Some notes inline ...
On 10/8/2007 12:03 AM, Jari Arkko wrote:
snip
Currently this
document simply has it at the IESG's discretion:
If at any point during the Working Group formation process, including
after a first or second BoF session, interest within the IETF
Yes, and this translates in IETF speech into having a viable technical
concept which is caught in a sound charter, proved resources and
community interest plus early code and individual I-Ds as very desirable
additions.
A SG process would not replace those, but could help achieve them in a
more
At Mon, 08 Oct 2007 11:13:50 -0700,
Lakshminath Dondeti wrote:
Thanks Jari, Eric. Some notes inline ...
On 10/8/2007 12:03 AM, Jari Arkko wrote:
snip
Currently this
document simply has it at the IESG's discretion:
If at any point during the Working Group formation process,
Ekr,
Thanks for your review.
As I was reading this document, I realized that I didn't understand
what it was for.
As I understand it, this document embeds IKEv2 into EAP. Why is this a
good idea? As I understand the situation, EAP already supports a
TLS-based authentication mechanism,
Thanks to IAB for the review. Inline:
The IAB does not oppose a scoped experiment.
Great!
However, As the IAB reviews BOFs and WG charters (see RFC 2850 section
2.1) as part of its architectural oversight function, we believe that
the IAB should also review SG charters.
Of course. I think
Please see http://www3.tools.ietf.org/tools/ietfdb/wiki/VancouverSprint
for more details about the upcoming Code Sprint.
Further discussion of the Vancouver IETF Code Sprint will take place on
the tools-discuss mail list. If you are planing to come, please join
that list and let Bill, Henrick,
On 2007-10-09 07:30, Eric Rescorla wrote:
At Mon, 08 Oct 2007 11:13:50 -0700,
Lakshminath Dondeti wrote:
big snip
My
observation based on some of the BoFs I have been involved with recently
is that far too much time is wasted between two BoF sessions. With
little or no discussion between
On Thu, 4 Oct 2007, Keith Moore wrote:
the vast majority of domains won't be able to use DKIM without seriously
impairing their users' ability to send mail.
You seem to be assuming that the vast majority of domains have really
shitty message submission servers or connectivity. Maybe true, but
Tony Finch wrote:
On Thu, 4 Oct 2007, Keith Moore wrote:
the vast majority of domains won't be able to use DKIM without seriously
impairing their users' ability to send mail.
You seem to be assuming that the vast majority of domains have really
shitty message submission servers or
On Oct 8, 2007, at 4:54 PM, Keith Moore wrote:
Tony Finch wrote:
On Thu, 4 Oct 2007, Keith Moore wrote:
the vast majority of domains won't be able to use DKIM without
seriously impairing their users' ability to send mail.
You seem to be assuming that the vast majority of domains have
Hi Eric,
Following up on this ...
On 10/8/2007 11:30 AM, Eric Rescorla wrote:
At Mon, 08 Oct 2007 11:13:50 -0700,
Lakshminath Dondeti wrote:
Thanks Jari, Eric. Some notes inline ...
On 10/8/2007 12:03 AM, Jari Arkko wrote:
snip
Currently this
document simply has it at the IESG's
Keith,
The DKIM component that establishes reputation is being discussed
within the DKIM WG. The DKIM signature offers an alternative to the
IP address which serves as perhaps the only other assured basis for
reputation. Of course the IP address also shares all of these
problems. A DKIM
On 10/8/2007 1:43 PM, Brian E Carpenter wrote:
On 2007-10-09 07:30, Eric Rescorla wrote:
At Mon, 08 Oct 2007 11:13:50 -0700,
Lakshminath Dondeti wrote:
big snip
My observation based on some of the BoFs I have been involved with
recently is that far too much time is wasted between two BoF
On Oct 8, 2007, at 4:37 AM, Frank Ellermann wrote:
SM wrote:
TMDA may cause backscatter.
After an SPF PASS, the backscatter by definition can't hit an
innocent bystander. By the same definition any backscatter after
an SPF FAIL hits an innocent bystander, and therefore is net abuse.
The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'RTP Topologies '
draft-ietf-avt-topologies-06.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'RTP Payload Format for Vorbis Encoded Audio '
draft-ietf-avt-rtp-vorbis-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'Low Density Parity Check (LDPC) Staircase and Triangle Forward Error
Correction (FEC) Schemes '
draft-ietf-rmt-bb-fec-ldpc-06.txt as a Proposed Standard
The IESG plans to
The IESG has approved the following document:
- 'Deprecation of Type 0 Routing Headers in IPv6 '
draft-ietf-ipv6-deprecate-rh0-01.txt as a Proposed Standard
This document is the product of the IP Version 6 Working Group.
The IESG contact persons are Jari Arkko and Mark Townsley.
A URL of
The IESG has approved the following document:
- 'A Uniform Resource Name (URN) Namespace for the Society of Motion
Picture and Television Engineers (SMPTE) '
draft-edwards-urn-smpte-02.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
Please see http://www3.tools.ietf.org/tools/ietfdb/wiki/VancouverSprint
for more details about the upcoming Code Sprint.
Further discussion of the Vancouver IETF Code Sprint will take place on
the tools-discuss mail list. If you are planing to come, please join
that list and let Bill, Henrick,
The IESG has received a request from an individual submitter to consider
the following document:
- 'A URN namespace for the Open Geospatial Consortium (OGC) '
draft-creed-ogc-urn-02.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the Extensible Authentication
Protocol WG (eap) to consider the following document:
- 'Network Discovery and Selection Problem '
draft-ietf-eap-netsel-problem-08.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
A new Request for Comments is now available in online RFC libraries.
RFC 4980
Title: Analysis of Multihoming in Network
Mobility Support
Author: C. Ng, T. Ernst,
E. Paik, M. Bagnulo
Status:
36 matches
Mail list logo
