You continue to not comprehend (or rather ignore) what continues to
plaque DKIM - the lack of fault detection. Its why it continues to
have a hard time and have people who actually believe in this
promising protocol bitch about it. If these big email providers
(or anyone for that matter)
Howdy,
First I'd like to thank the organizers for IETF-81 for another well-run
meeting. The logistics and coordination for such an event must be daunting,
and I know we (the attendees) tend to focus on the negatives rather than the
positives... but we really are thankful for all the time and
I don't think I have seen a proposal like this before. I really like it, as
there are a bunch of post-IETF stuff, some of which starts in the afternoon and
thus conflicts with the IETF. This fixes that problem, enables us to have the
same amount of meeting time, and potentially lets people get
On 31st July 2011, Brian Carpenter wrote, in part:
I believe that the present situation is confusing both to IETF newcomers
(who may falsely believe that the IETF actually follows the 3 stage process)
and, worse, confusing to users of IETF standards (who may falsely believe
that a document
On Jul 31, 2011, at 11:55 AM, RJ Atkinson wrote:
On 31st July 2011, Brian Carpenter wrote, in part:
[snip]
It might cause a change, simply because the effort of making the single
move PS-IS will get you to the end state, whereas previously you had
to make two efforts, PS-DS-STD. But only
+1 to that as well ..an excellent proposal.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric
Burger
Sent: Sunday, July 31, 2011 11:48 AM
To: Hadriel Kaplan
Cc: IETF-Discussion list
Subject: Re: A modest proposal for Friday meeting schedule
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
Moreover, unlike nat64, nat44 can be fully transparent end to end.
Some people may consider it a feature that only incumbents with power
and money can usefully call listen(), and that useful user to user
activities requires the cooperation of an
it looks so - maybe it would be good to have a pointer in this doc
Scott
On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote:
Scott -
Didn't RFC 5657 address your point 2?
The current proposal no longer requires this report during advancement, but
it does not disallow it.
I hope it's
On 2011-07-27 00:52, Olaf Kolkman wrote:
Dear Colleagues,
Based on the discussion I've updated the draft:
http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
Essentially I incorporated Dave Crocker's proposal to
1) replace the 'chairs' by voting members appointed
Hello folks,
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any
Mark Atwood wrote:
Moreover, unlike nat64, nat44 can be fully transparent end to end.
Some people may consider it a feature that only incumbents with power
and money can usefully call listen(), and that useful user to user
activities requires the cooperation of an intrusive 3rd party, while
11 matches
Mail list logo
