Hi. All of these questions have come up before on the various lists
where this draft was developed, but I suppose it's worth going through
them again.
On the other hand, I have a few questions: the first one, why
Proposed standard? Is it really a good idea to standardize these
lists (most being
On Fri, Nov 07, 2008 at 02:18:21PM -,
John Levine [EMAIL PROTECTED] wrote
a message of 55 lines which said:
All of these questions have come up before on the various lists
where this draft was developed, but I suppose it's worth going
through
That's the point of an IETF-Wide Last Call.
After Each entry in the DNSxL MUST have an A record., add The A
record MUST NOT be interpreted as an IPv4 address. It is an opaque
value, whose presence simply means that the name or address queried is
actually listed in the DNSxL.
Seems reasonable.
No, it's just experience. The last funny
At 10:35 PM -0800 11/6/08, SM wrote:
The IANA Considerations section is missing. I suggest registering the header
as specified in RFC 3864.
We purposely did not make this extensible in this document. From talking to
many of the companies that would be certifiers, there was no interest in
Stephane Bortzmeyer wrote:
On Fri, Nov 07, 2008 at 02:18:21PM -,
John Levine [EMAIL PROTECTED] wrote
All of these questions have come up before on the various lists
where this draft was developed, but I suppose it's worth going
through
That's the point of an IETF-Wide Last Call. I'm
Dave == Dave CROCKER [EMAIL PROTECTED] writes:
Dave Stephane Bortzmeyer wrote:
On Fri, Nov 07, 2008 at 02:18:21PM -, John Levine
[EMAIL PROTECTED] wrote
All of these questions have come up before on the various
lists where this draft was developed, but I suppose it's
The IANA Considerations section is missing. I suggest registering
the header as specified in RFC 3864.
We purposely did not make this extensible in this document.
I think you're talking past each other here. I read SM's message
as adding VBR-Info: to the list of known mail header lines here:
At 5:13 PM + 11/7/08, John Levine wrote:
The IANA Considerations section is missing. I suggest registering
the header as specified in RFC 3864.
We purposely did not make this extensible in this document.
I think you're talking past each other here. I read SM's message
as adding
Sam Hartman wrote:
It seems quite clear to me that RFC 2418 does not apply at all to the
output of an RG.
Sam,
I've looked around and the WG Guidelines doc happens to be the only place I
could find that defines the purpose of a Last Call. The mere fact that the title
of document is
On Friday 07 November 2008 13:00:19 ext Christian Vogt, you wrote:
Whether it's of any use depends on the connection model (or lack
thereof) of
the transport protocol. I don't want to presume that this would make
sense
for all future transport protocols. [...]
I don't agree. A reason
On Tue, Nov 04, 2008 at 10:59:46AM -0800,
The IESG [EMAIL PROTECTED] wrote
a message of 26 lines which said:
- 'DNS Blacklists and Whitelists '
draft-irtf-asrg-dnsbl-07.txt as a Proposed Standard
Well, it is certainly very important that the DNSxL are documented,
given their widespread
Rémi -
(2) On requirements 1 and 3:
REQ-1: A NAT MUST have an Endpoint-Independent Mapping
behavior for DCCP.
REQ-3: If application transparency is most important, it is
RECOMMENDED that a NAT have an Endpoint-independent
filtering
behavior for
Incidentally, although it may still be the conventional
wisdom in the IETF that DNSBLs don't work and aren't useful,
in the outside world where 95% or more of mail is spam,
they're essential tools to run a mail server. Although there
are indeed lots of stupid DNSBLs, those aren't the
On Nov 7, 2008, at 3:17 AM, Stephane Bortzmeyer wrote:
On Tue, Nov 04, 2008 at 10:59:46AM -0800,
The IESG [EMAIL PROTECTED] wrote a message of 26 lines which
said:
- 'DNS Blacklists and Whitelists '
draft-irtf-asrg-dnsbl-07.txt as a Proposed Standard
Well, it is certainly very
On 11/7/08 at 9:38 AM -0800, Dave CROCKER wrote:
Sam Hartman wrote:
It seems quite clear to me that RFC 2418 does not apply at all to
the output of an RG.
I've looked around and the WG Guidelines doc happens to be the only
place I could find that defines the purpose of a Last Call. The mere
Pete == Pete Resnick [EMAIL PROTECTED] writes:
Pete http://tools.ietf.org/rfc/rfc4844.txt
Pete http://tools.ietf.org/id/draft-irtf-rfcs-03.txt
Pete We have (IMO) historically screwed up with regard to IRTF
Pete and individual documents and not given them a proper stream
Pete
+1
If it's going to be an IETF Standard, it has to have IETF consensus.
This seems consistent with the way individual (i.e., non-WG) submissions
are handled through the IESG.
Leslie.
Pete Resnick wrote:
On 11/7/08 at 9:38 AM -0800, Dave CROCKER wrote:
Sam Hartman wrote:
It seems quite
Under no circumstances should any kind of Blacklists or Whitelists be
accepted by IETF as standards-track documents. These lists are
responsible for huge numbers of illegitimate delivery failures. We
should no more be standardizing such lists than to be standardizing spam.
Keith
DNSBLs work to degrade the interoperability of email, to make its
delivery less reliable and system less accountable for failures. They
do NOT meet the no known technical omissions criterion required of
standards-track documents.
The fact that they are widely used is sad, not a justification for
Hi John,
At 09:13 07-11-2008, John Levine wrote:
I think you're talking past each other here. I read SM's message
as adding VBR-Info: to the list of known mail header lines here:
http://www.iana.org/assignments/message-headers/perm-headers.html
Thanks, that's what I meant.
Regards,
-sm
--On Tuesday, 21 October, 2008 08:02 -0700 The IESG
[EMAIL PROTECTED] wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'IESG Procedures for Handling of Independent and IRTF Stream
Submissions '
The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'GEOPRIV PIDF-LO Usage Clarification, Considerations and
Recommendations '
draft-ietf-geopriv-pdif-lo-profile-13.txt as a Proposed Standard
The IESG plans to make a
The IESG has approved the following document:
- 'A Hitchhiker's Guide to the Session Initiation Protocol (SIP) '
draft-ietf-sip-hitchhikers-guide-06.txt as an Informational RFC
This document is the product of the Session Initiation Protocol Working
Group.
The IESG contact persons are
The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Allocation Guidelines for the Address Resolution Protocol (ARP)'
draft-arkko-arp-iana-rules-01.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
The IESG has approved the following document:
- 'A Hitchhiker's Guide to the Session Initiation Protocol (SIP) '
draft-ietf-sip-hitchhikers-guide-06.txt as an Informational RFC
This document is the product of the Session Initiation Protocol Working
Group.
The IESG contact persons are
25 matches
Mail list logo
