...
I think it would be a good idea for the IETF to either pick an IPR
standard or to require WGs to specify what their IPR standard will be
when they begin a WG. I would be quite happy for the IETF to adopt the
same IPR policy as W3C and require all standards to meet that standard
of being open
Title: Re: Enough RE: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)
The issue is not so much restrictive as different. Corporate lawyers work from precedent, if they have already agreed to a set of terms they do not need further review.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Frank Ellermann
Hallam-Baker, Phillip wrote:
I note that the W3C policy is distributed under a creative commons
license. I suggest that future WGs adopt it as is when they
make their
charter proposals. Otherwise they
Given all (2)822 header fields as they are, ignoring the trace
header fields, the PRA algorithm is the only possible way to
divine a purported responsible address from this zoo. It's
not new, it's read and understand RFC 822 as published 1982.
actually, no. It's a perversion of RFC 822 which
Keith Moore wrote:
It's a perversion of RFC 822 which contradicts both the
intent and the way it has been used in practice.
It's probably clear that I hate PRA, because it's a kind of
FUSSP (worldwide add Resent-Sender at places where that
was never before required), because it claims
From: Sam Hartman [mailto:[EMAIL PROTECTED]
If we standardize a technology, we are saying that technology
solves some problem. and that its usage has well understood
and accepted consequences.
Ergo since Microsoft and many others have already said they are going to
be using PRA type
If we standardize a technology, we are saying that technology
solves some problem. and that its usage has well understood
and accepted consequences.
Ergo since Microsoft and many others have already said they are going to
be using PRA type techniques it follows that they had better be
From: Keith Moore [mailto:[EMAIL PROTECTED]
However that doesn't mean that IETF should necessarily
endorse, or even
document, any of these technologies.Sometimes it's a disservice to
the community to document a bad idea.
The protaganists in this matter have already conceeded the
From: Keith Moore [mailto:[EMAIL PROTECTED]
However that doesn't mean that IETF should necessarily
endorse, or even
document, any of these technologies.Sometimes it's a disservice to
the community to document a bad idea.
The protaganists in this matter have already conceeded
Keith However that doesn't mean that IETF should necessarily
Keith endorse, or even document, any of these technologies.
Keith Sometimes it's a disservice to the community to document a
Keith bad idea.
I'm from the school that believes documenting existing behavior is
always
Keith == Keith Moore moore@cs.utk.edu writes:
The point I am making here is that nothing that the IETF can do
will create a situation where the sender of an email will be
able to ensure that recipients do not filter the email using a
particular technology.
Keith True.
Hallam-Baker, Phillip wrote:
I note that the W3C policy is distributed under a creative
commons license. I suggest that future WGs adopt it as is
when they make their charter proposals. Otherwise they are
likely to find themselves in the same position that MARID
did.
FWIW, I looked into the
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, Do we have to go through this yet again? The
Hallam-Baker, entire premise of spam filtering is that the
Hallam-Baker, recipient is not prepared to deliver mail to a
Hallam-Baker, user's mail box
Title: Re: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)
Do we have to go through this
yet again?
The entire premise of spam filtering is
that the recipient is not prepared to deliver mail to a user's mail box unless
the sender
In message [EMAIL PROTECTED]
om, Hallam-Baker, Phillip writes:
Do we have to go through this yet again?
The entire premise of spam filtering is that the recipient is not
prepared to deliver mail to a user's mail box unless the sender
convinces the recipient of their bona fides.
No. The
On Tue, 13 Dec 2005, Douglas Otis wrote:
The reduction to 111 DNS lookups is not a resounding impact with
respect to this concern.
You can do setup that involves multiple CNAME and NS redirections
with DNS and it all could come to those 100 lookups. In practice
these setups do not exist
On Wed, 2005-12-14 at 07:06 -0800, william(at)elan.net wrote:
On Tue, 13 Dec 2005, Douglas Otis wrote:
You can do setup that involves multiple CNAME and NS redirections
with DNS and it all could come to those 100 lookups.
Few would expect this to work, nor would that be a _required_ depth.
On Wed, 14 Dec 2005, Douglas Otis wrote:
Actually there was case that came close to this limit by an access
provider, but was rewritten into CIDR notation to reduce the number of
records, increasing their chances for error. At the email
authentication summit in NY, there was a large company
william(at)elan.net wrote:
in practice SES/BATV cryptographic MAILFROM should not be
looked at an alternative to RMX/SPF method. In fact they
both are stronger when combined together, however
unfortunately the different proponents fail to point this
fact to the wider audience (plus BATV
On Dec 14, 2005, at 9:38 AM, Frank Ellermann wrote:
Anybody experimenting with combinations will be delighted to
learn that (s)he's now expected to opt out from PRA first.
The opt-out of PRA is actually opt-in using the spf2.0/pra ?all
record.
This PRA record would likely still fall
Douglas Otis wrote:
The opt-out of PRA is actually opt-in using the
spf2.0/pra ?all record.
No, the PRA spec. claims that you SHOULD get PRA for a pure
v=spf1 policy, and if you don't want PRA for whatever reasons
you have to opt-out from PRA with a dummy spf2.0/pra policy.
That's opt-out
On Mon, 2005-12-12 at 13:51 -0600, wayne wrote:
Well, I can see coming back some day and trying to create an update to
the SPF protocol. I can't see trying to change SPF version 1.
The problem with SPF draft is there is no spf2.0/mfrom. This has little
to do the IETF, but rather a
Douglas Otis wrote:
The problem with SPF draft is there is no spf2.0/mfrom.
One week from draft-ietf-marid-mailfrom-00 to the termination
of MARID was a bit short. And after that the next draft was
again v=spf1 draft-lentczner-spf-00 (same author). Actually
an emergency draft, because the
In [EMAIL PROTECTED] Frank Ellermann [EMAIL PROTECTED] writes:
Whatever you think, but your complaints about the theoretical
upper limit of DNS queries in an attack scenario resulted in
some of the most interesting post-MARID changes (Wayne's I-Ds).
This is bunk.
The DoS limits that are in
I have, in the past, argued to the IESG that I did not think the SPF
I-D should be marked Experimental because I did not see it being an
experiment. It has been out for 2 years now and it is far too widely
deployed to make significant changes. Instead, I thought it should be
standard track.
On Dec 13, 2005, at 11:07 AM, wayne wrote:
However, his complaints could not have possibly had any impact on
the current limits in the SPF spec.
The reduction to 111 DNS lookups is not a resounding impact with
respect to this concern. Defending this sequential lookup
requirement will
In [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] writes:
wayne == wayne [EMAIL PROTECTED] writes:
wayne In [EMAIL PROTECTED] Bob Braden
wayne [EMAIL PROTECTED] writes:
This thread has contained several suggestions that publication
of an RFC in the Experimental category
wayne == wayne [EMAIL PROTECTED] writes:
wayne In [EMAIL PROTECTED] Bob Braden
wayne [EMAIL PROTECTED] writes:
This thread has contained several suggestions that publication
of an RFC in the Experimental category constitutes an IETF
experiment.
wayne This is, in
Frank == Frank Ellermann [EMAIL PROTECTED] writes:
Frank Bob Braden wrote:
I cannot find any evidence from RFC 2026 that there is any such
thing as an IETF experiment or IETF-sanctioned experiment.
Frank Yes, that's tricky. Some folks including me were surprised
Frank
On Fri, 9 Dec 2005, Pekka Savola wrote:
Basically the IESG decided that accurate documentation of the running code
is more important than documenting something that does not exist, and maybe
never will exist.
That's certainly an understandable tradeoff to make, and it gets back to the
more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pekka Savola wrote:
There seem to be three options going forward:
1) make no changes to the spec. The spec (assumably) documents the
existing behaviour, even if it is conflicting.
2) make the spec to disallow that. The
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no running code that
actually interpreted v=spf1 as spf2.0/mfrom,pra.
Perhaps you shouldn't have said that. Sendmail's sid-milter has used
v=spf1
In [EMAIL PROTECTED] Julian Mehnle [EMAIL PROTECTED] writes:
Pekka Savola wrote:
Basically the IESG decided that accurate documentation of the running
code is more important than documenting something that does not exist,
and maybe never will exist.
As my appeal[1] pointed out, at the time
In [EMAIL PROTECTED] william(at)elan.net [EMAIL PROTECTED] writes:
However SID drafts are going for EXPERIMENTAL status and are NOT purely
documentation of running code but rather IETF sanctioned internet-wide
experiment with possible intention to move to standard if experiment
is successful.
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no running code that
actually interpreted v=spf1 as spf2.0/mfrom,pra.
Perhaps you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dick St.Peters wrote:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00
was submitted for experimental status, there was no running code
that actually interpreted v=spf1 as spf2.0/mfrom,pra.
Perhaps
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no running code that
actually interpreted v=spf1 as spf2.0/mfrom,pra.
Perhaps you
wayne writes:
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no running code that
actually interpreted v=spf1 as spf2.0/mfrom,pra.
Pekka Savola wrote:
1) make no changes to the spec. The spec (assumably)
documents the existing behaviour, even if it is
conflicting.
SPF (both v=spf1 and spf2.0, there is no v=pf2.0) allows
to log DNS queries. That's documented in the v=spf1 draft:
With SPF's exists:-mechanism it's
On Fri, 9 Dec 2005, Dick St.Peters wrote:
Do you know if Sendmail Inc. is committed to conforming to the RFCs
and will change if the RFCs change?
You'll have to ask them. However, I suspect it's safe to say that
they will conform to any RFCs that become standards.
SPF SID document if
In [EMAIL PROTECTED] Frank Ellermann [EMAIL PROTECTED] writes:
Result of this experiment (last state that I've heard of):
Absolutely nobody evaluates spf2.0/pra.
fyi;
There have been a couple of people who have run stats on the usage of
spf2.0/pra vs SPF. It *is* being used, but no where
wayne == wayne [EMAIL PROTECTED] writes:
wayne Isn't the time to fix the problem now? Before the
wayne experiment is run?
Can you convince the sender ID authors to do so and to change their
implementations?
I don't think the IETF or IESG could accomplish that. If you can then
I
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
wayne writes:
In [EMAIL PROTECTED] Dick St.Peters [EMAIL PROTECTED] writes:
Julian Mehnle writes:
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no
On Fri, 9 Dec 2005, Sam Hartman wrote:
wayne == wayne [EMAIL PROTECTED] writes:
wayne Isn't the time to fix the problem now? Before the
wayne experiment is run?
Can you convince the sender ID authors to do so and to change their
implementations?
I don't think the IETF or IESG could
wayne wrote:
For example, the SenderID I-D talks about DNS zone cuts and
such, which were in earlier drafts of the SPF spec, but were
removed from the final draft
Their May 2005 draft still references your December 2004 state:
| If the PRA version of the test is being performed and no
|
wayne wrote:
There have been a couple of people who have run stats on the
usage of spf2.0/pra vs SPF. It *is* being used, but no where
near as much as SPF.
I was referring to your article in spf-discuss some months ago,
where you found that a dummy spf2.0/pra opt out is apparently
not
This thread has contained several suggestions that publication of
an RFC in the Experimental category constitutes an IETF experiment.
I cannot find any evidence from RFC 2026 that there is any such thing
as an IETF experiment or IETF-sanctioned experiment. Section 4.2.1
of RFC 2026 explains what
Bob Braden wrote:
I cannot find any evidence from RFC 2026 that there is any
such thing as an IETF experiment or IETF-sanctioned
experiment.
Yes, that's tricky. Some folks including me were surprised
that there's no IETF last call for experimental RFCs, unless
they are the product of an IETF
In [EMAIL PROTECTED] Bob Braden [EMAIL PROTECTED] writes:
This thread has contained several suggestions that publication of
an RFC in the Experimental category constitutes an IETF experiment.
This is, in part, due to the directions of the IESG. For example, the
IESG note that will be placed
The IESG decided:
while we have found merit in Julian Mehnle's technical
concerns, we will not change our decision to publish the
draft as an Experimental RFC without change to its technical
content.
The IESG did consider this conflict in its original
discussions, and that is one of the
On Thu, 8 Dec 2005, Frank Ellermann wrote:
The IESG did not consider this an appropriate action to take
in this case.
Well, you are wrong, and everybody can see it. If one draft
says SHOULD do x, and another draft says SHOULD NOT do x,
then something has to give.
There seem to be three
I would appreciate not hearing the same arguments again and again.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
In [EMAIL PROTECTED] Andrew Newton [EMAIL PROTECTED] writes:
But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.
I asked for the IESG to not consider the SPF I-D
In [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] writes:
wayne == wayne [EMAIL PROTECTED] writes:
wayne I asked for the IESG to not consider the SPF I-D to be
wayne experiemental. It was turned down. According to Ted,
wayne *none* of the IESG members expressed interest in
On Aug 26, 2005, at 7:53 AM, wayne wrote:
In [EMAIL PROTECTED] Andrew Newton
[EMAIL PROTECTED] writes:
But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.
I
On Fri, 2005-08-26 at 10:23 -0700, Hallam-Baker, Phillip wrote:
snip
I do not believe that one group should be able to block a proposal they
do not like by alleging a non-existent conflict.
A conflict does exist interpreting v=spf1 records in a PRA scope. I had
a customer who was a victim of
On Aug 26, 2005, at 12:56 PM, wayne wrote:
In [EMAIL PROTECTED] Douglas
Otis [EMAIL PROTECTED] writes:
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an
I request that people who want to discuss technical issues and proposals,
rather than the narrow issue of the appeal itself, please drop
ietf@ietf.org from their messages or change the subject to a relevant
technical topic.
Thanks
Brian Carpenter
In [EMAIL PROTECTED] Andrew Newton [EMAIL PROTECTED] writes:
On Aug 25, 2005, at 2:08 PM, Bill Sommerfeld wrote:
In this case, the two experiments interpret the same codepoints in the
DNS in subtly different ways.
A mail-sending domain indicates that it is participating by publishing
On 8/26/05, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote:
Let me phrase it this way: the IESG should not sanction conflicting
experiments by publishing conflicting specifications,
I agree.
But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this was accepted
Julian,
The IESG will consider your appeal as soon as reasonably
possible.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
IETF Chair
Julian Mehnle wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
IESG Chair Brian Carpenter,
as per the Internet
wayne wrote:
The SHOULD check HELO was added in 2004, not 2005.
This was changed to RECOMMENDED in 2005.
SHOULD is the same as RECOMMENDED (2119 section 3). BTW, the
first three sections together need only ten lines including
two blank separator lines, that could be a record.
Date: 2005-08-26 10:45
From: Andrew Newton [EMAIL PROTECTED]
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
-andy
The stated goal of draft-schlitt-spf-classic is to document SPF,
basically as it was before the IETF got involved.
On Sun, 28 Aug 2005, Bruce Lilly wrote:
The Historic category of published RFCs can be used for documents which
specify a protocol or technology which is known to be harmful to the
Internet. However, RFC 2026 appears to have no provision for getting to
Historic except via the Standards Track
John Glube wrote in mxcomp:
I should have written:
|The underlying benefit of e-mail authentication for senders
|interested in e-mail delivery is to establish a framework that
|supports certification and reputation services, both external
|and internal to facilitate the delivery of ham,
In [EMAIL PROTECTED] Frank Ellermann [EMAIL PROTECTED] writes:
John Glube wrote in mxcomp:
I should have written:
|The underlying benefit of e-mail authentication for senders
|interested in e-mail delivery is to establish a framework that
|supports certification and reputation services,
In [EMAIL PROTECTED] Bruce Lilly [EMAIL PROTECTED] writes:
This is an important point; the SPF-classic draft was announced to the
ietf-822 and ietf-smtp mailing lists where there was some discussion on
that very point. While the ID-tracker state indicated intended status of
Experimental, the
Thomas Gal wrote:
Well clearly IANA won't accept 2 differing registrations that
overlap on this matter. Certainly it is the IETF/IESG/IAB's
job to rectify that incongruity?
There's IMHO no IANA problem, using the same DNS RR type 99 is
possible / desirable.
For the IESG to say Change your
JFC (Jefsey) Morfin wrote:
On 21:25 25/08/2005, Stephane Bortzmeyer said:
If the IESG were to refuse to publish the Sender-ID document as it is,
it would not police everything: anyone can still do what he wants on
the Internet.
The only thing than the IETF can do is to bless or not the
At 13:08 26/08/2005, Brian E Carpenter wrote:
JFC (Jefsey) Morfin wrote:
just a remark here. In the RFC 3066bis Last Call case the IETF has
the capacity not only to police but to impose and force. This
is the case when a memo documents a IANA registry. In the case of a
standard track memo,
On Fri, Aug 26, 2005 at 08:47:17AM -0400,
Andrew Newton [EMAIL PROTECTED] wrote
a message of 21 lines which said:
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
It is an absolutely incredible request since SPF uses these records
since its
On Aug 26, 2005, at 9:15 AM, Stephane Bortzmeyer wrote:
On Fri, Aug 26, 2005 at 08:47:17AM -0400,
Andrew Newton [EMAIL PROTECTED] wrote
a message of 21 lines which said:
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
It is an absolutely
JFC (Jefsey) Morfin wrote:
At 13:08 26/08/2005, Brian E Carpenter wrote:
JFC (Jefsey) Morfin wrote:
just a remark here. In the RFC 3066bis Last Call case the IETF has
the capacity not only to police but to impose and force. This
is the case when a memo documents a IANA registry. In the case
Let me phrase it this way: the IESG should not sanction conflicting
experiments by publishing conflicting specifications,
I agree.
But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this was accepted by the WG right up to the point where
people started to complain
In [EMAIL PROTECTED] Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
I do not think that the IESG should block a proposal citing a conflict
when the real animus here is entirely due to the IPR issue.
There are certainly people who have problems with introducing
technology into a core Internet
wayne == wayne [EMAIL PROTECTED] writes:
wayne In [EMAIL PROTECTED] Andrew
wayne Newton [EMAIL PROTECTED] writes:
But since you brought this up: if you (the author of the
document) do not consider this to be an experiment, then
perhaps the IETF should not publish SPF as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip Hallam-Baker wrote:
Let me phrase it this way: the IESG should not sanction conflicting
experiments by publishing conflicting specifications,
I agree.
But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this
In [EMAIL PROTECTED] Douglas Otis [EMAIL PROTECTED] writes:
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an historic track. ; )
RFC2026 says:
4.2.4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip Hallam-Baker wrote:
Since all these 'failures' are simply known properties of the PRA check
there is absolutely no value in changing the version string.
Of course there is. The fact alone that S-ID has different failure
modes than SPF
Hallam-Baker, Phillip wrote:
But I do not believe that SPF and Sender-ID conflict in any
way whatsoever and this was accepted by the WG
What you believe is your business, but this was never accepted
by the WG, because it's plain wrong, see also reference [12]
in the appeal:
Brian == Brian E Carpenter [EMAIL PROTECTED] writes:
Brian JFC (Jefsey) Morfin wrote:
At 13:08 26/08/2005, Brian E Carpenter wrote:
JFC (Jefsey) Morfin wrote:
just a remark here. In the RFC 3066bis Last Call case the
IETF has the capacity not only to police but to impose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Newton wrote:
Wayne Schlitt wrote:
Andrew Newton wrote:
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
The stated goal of draft-schlitt-spf-classic is to document SPF,
basically as
Behalf Of Sam Hartman
Fundamentally, though,
it is their desire to have interoperability that drives them
to work with the IETF. That is the only power we have.
Ergo the attempt to force Sender-ID to use v=2.0 in order to create an
unnecessary interoperability failure is utterly doomed to
Hallam-Baker, Phillip wrote:
I do not think that the IESG should block a proposal citing a
conflict when the real animus here is entirely due to the IPR
issue.
Hogwash, I've proposed a way to fix PRA to avoid at least
the worst incompatibility (a default Sender derived from
the Return-Path in
Dear Sam,
thank you for this analysis. This is exactly my concern. There are in
addition a few points:
1. the WG-ltru involves employees of the industry dominant actors. I
feel they will not want to make a costly error for their corporation
and for them. But Layer 8 strategy errors are
Dotzero wrote:
Writing a standard which subverts the intent of individuals
publishing to a different and existing standard is simply
unethical and wrong.
+1
What happened was essentially a political move because people
chose not to publish SPF2 records for PRA. So, the response
was to
Andrew Newton wrote:
I stated that the SPF and Sender ID experiments should not
use the v=spf1 records to avoid conflict.
Yes, you are a prominent part of this embrace and extend
strategy also known as steal or destroy.
if you (the author of the document) do not consider this to
be an
wayne wrote:
Informational might also be appropriate.
Not from my POV, I wanted this beast under IETF control.
That's why I pushed for an RfC, and later after reading
the fine print 2026 for standards track.
Informational is something the authors could update
whenever it pleases them. There
In [EMAIL PROTECTED] Douglas Otis [EMAIL PROTECTED] writes:
On Aug 26, 2005, at 12:56 PM, wayne wrote:
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, [...]
There isn't a
Stephane Bortzmeyer wrote:
It is an absolutely incredible request since SPF uses these
records since its beginning (a long time before Sender-ID
existed) and since there is (unlike SenderID) actual
deployment, which can not be called back.
SPF is also older than Caller-ID, a patented
Spencer Dawkins wrote:
of course, the idea of the IESG policing anything that
happens on the Internet has to be kind of silly, given that
two consenting endpoints can send just about anything to
each other, especially above the IP layer, and our obvious
lack of any enforcement mechanism.
Julian,
not speaking for anyone but myself.
one matter of principle:
are you of the opinion that the IESG should try to police which experiments
get run on the Internet by refusing to publish RFCs documenting
possibly-conflicting experments?
Both of these documents were published at
On Thu, 2005-08-25 at 13:14, Harald Tveit Alvestrand wrote:
are you of the opinion that the IESG should try to police which experiments
get run on the Internet by refusing to publish RFCs documenting
possibly-conflicting experments?
It depends on the form of the conflict.
I believe that the
On Thu, 2005-08-25 at 13:14, Harald Tveit Alvestrand wrote:
are you of the opinion that the IESG should try to police which experiments
get run on the Internet by refusing to publish RFCs documenting
possibly-conflicting experments?
It depends on the form of the conflict.
I believe that
On Thu, 2005-08-25 at 14:26, [EMAIL PROTECTED] wrote:
In any case, I support this appeal to the extent that I believe the conflicts
need to be resolved prior to publication. I take no position on the means
by which the conflict is resolved as long as a resolution is reached.
And I
In any case, I support this appeal to the extent that I believe the conflicts
need to be resolved prior to publication. I take no position on the means
by which the conflict is resolved as long as a resolution is reached.
All of this raises the obvious question of the purpose in having the
Harald Tveit Alvestrand wrote:
Julian,
not speaking for anyone but myself.
one matter of principle:
are you of the opinion that the IESG should try to police which
experiments get run on the Internet by refusing to publish RFCs
documenting possibly-conflicting experments?
Both of
On Thu, Aug 25, 2005 at 10:14:39AM -0700,
Harald Tveit Alvestrand [EMAIL PROTECTED] wrote
a message of 41 lines which said:
are you of the opinion that the IESG should try to police which
experiments get run on the Internet by refusing to publish RFCs
documenting possibly-conflicting
On Thu, Aug 25, 2005 at 09:25:29PM +0200, Stephane Bortzmeyer wrote:
If the IESG were to refuse to publish the Sender-ID document as it is,
it would not police everything: anyone can still do what he wants on
the Internet.
The only thing than the IETF can do is to bless or not the document,
On Aug 25, 2005, at 11:26 AM, Ned Freed wrote:
A mail-sending domain indicates that it is participating by
publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment. This renders any
claimed results
1 - 100 of 104 matches
Mail list logo
