On 2008-04-15 05:12 Ned Freed said the following:
On 2008-04-15 00:35 Ned Freed said the following:
On 2008-04-14 23:11 Ned Freed said the following:
I guess I should be flattered, but really, I fail to see why. Guaranteed
bypass
of moderation is simply an allowed-poster whitelist.
So
Having a single system for all WG lists has the appeal that whatever
process(es) handle the lists, it will be the same for all lists, so
you don't have to figure out how N different lists are run.
As a shameless plug, we have a free open source solution developed here
which is widely used against
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:
Fred Baker wrote:
A thought...
your list below eliminates five out of the ten of the IAOC. The
remaining folks include the IAOC secretary (whom I would suggest
should also be ineligible), a member selected by the IETF nomcom, the
member selected by the IESG, and the member selected
- Original Message -
From: IESG Secretary [EMAIL PROTECTED]
To: IETF Announcement list [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; ietf@ietf.org
Sent: Monday, April 14, 2008 5:39 PM
Subject: IESG Statement on Spam Control on IETF Mailing Lists
The following principles apply to spam control
- Original Message -
From: Tom.Petch [EMAIL PROTECTED]
To: Eliot Lear [EMAIL PROTECTED]
Cc: IETF Discussion ietf@ietf.org
Sent: Tuesday, April 15, 2008 6:09 AM
Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists
- Original Message -
From: Eliot Lear [EMAIL
No Ray - the Trust member's need to NOT have any other active IESG/IETF or
IAB relationship's while they sit on the Trust since there would be
clear-cut violation's of conflict and that is that.
Todd Glassey
- Original Message -
From: Ray Pelletier [EMAIL PROTECTED]
To: Fred Baker
Dean -
- Original Message -
From: Dean Anderson [EMAIL PROTECTED]
To: Wes Beebee (wbeebee) [EMAIL PROTECTED]
Cc: IETF Discussion ietf@ietf.org
Sent: Wednesday, April 09, 2008 10:28 PM
Subject: RE: Blue Sheet Change Proposal
Speaking as president of the LPF; not a lawyer but a
-- On Monday, April 14, 2008 10:25 PM +0200 Henrik Levkowetz
[EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam
Control on IETF Mailing Lists --
* IETF mailing lists MUST provide a mechanism for legitimate
technical participants to determine if an attempt to post was
dropped
-- On Monday, April 14, 2008 8:58 PM +0200 Frank Ellermann
[EMAIL PROTECTED] wrote regarding Re: IESG Statement on
Spam Control on IETF Mailing Lists --
Russ Housley wrote:
When IETF lists are housed somewhere other than ietf.org,
they are supposed to include an archive recipient so
I'm not sure I agree. I do agree with Henrik's comments to the
extent that I think we need to be clear. Obviously there's some
ambiguity and we should clear that up.
My interpretation of the two statements is that they are
complementary, not conflicting. I would say that the third bullet
-- On Monday, April 14, 2008 2:11 PM -0700 Ned Freed
[EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam
Control on IETF Mailing Lists --
+1 to Henrik's comments. I don't think the two MUSTs
that he comments on are algorithmically possible.
These two MUSTs (the ability to
On Mon, Apr 14, 2008 at 08:13:23PM +0200, Eliot Lear wrote:
I think there is probably convenience value to housing the mailing lists
at the IETF. It allows for a single whitelist, reduction in those
annoying monthly messages that we eventually all filter into the
bitbucket.
I'll concur
Pekka,
I will provide an updated draft to address your issues below as best
possible. The principal challenge is related to security and most
notably key management. I hope we can avoid waiting on the more
comprehensive RMT Security Discussion document? I agree that it
would be _nice_ to
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:
Hi Pekka,
You have some very good comments. As you point out, the rserpool work
is basically
a research project at this point, with no known planned deployment over
the Internet. We
are targeting the protocol documents as Experimental in order to record
the work.
We will try to clarify the
On 2008-04-15 16:59 James Galvin said the following:
-- On Monday, April 14, 2008 10:25 PM +0200 Henrik Levkowetz
[EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam
Control on IETF Mailing Lists --
* IETF mailing lists MUST provide a mechanism for legitimate
technical
Hi Keith,
I've been working with Tony and John very closely on this issue, and
whether it smells foul or not, I think this is the best we can do.
Tony was very diligent about having conversation on all aspects and
looking at a number of different resolutions including the one he
James Galvin wrote:
Hi, thanks for the explanation, I add some notes of what
I think this means, please correct me if I got it wrong.
[2418]
| As a service to the community, the IETF Secretariat
| operates a mailing list archive for working group
| mailing lists.
Most lists I submitted to the
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
Hi Henrik,
Seems this email about email still needs some more discussion - I have
not been involved much with this much but I suspect that Chris Newman
would probably be the best person on the IESG to work with on both
clarifications and changes.
Cullen
On Apr 15, 2008, at 10:49 AM,
On Apr 14, 2008, at 7:33 PM, Tony Hansen wrote:
The SMTP implementations that have made the transition to support
IPv6 appear to already have done it in a way that supports
records for the implicit MX case. In some cases they are following
RFC 3974, and other cases they are just
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
The Multiparty Multimedia Session Control (mmusic) working group in the
Real-time Applications and Infrastructure Area of the IETF has been
rechartered. For additional information, please contact the Area
Directors or the working group Chairs.
Multiparty Multimedia Session Control (mmusic)
24 matches
Mail list logo
