Re: several messages

[Matthias Leisi]

[trimmed the Cc: list]

Dean Anderson schrieb:

> In fact, the people who use these DNSBL blacklists do so only for a
> short time, until they get burned and stop using them. That's what

Where do you get this "fact" from? I'd be very interested to learn about
this, because I see overwhelming evidence of the contrary - that well
managed DNSBLs are used by all but a minority of email receiving systems.

> happens routinely with SORBS.  I call a few people a month about SORBS.  
> Very little mail is actually blocked by most of these lists. But what
> little that is blocked is blocked in error. 

Can you back up this statement with some data?

> In the 1990s, I found ORBS and Osirusoft scanning for open relays and 

We have 2008. I don't think that some misguided individuals back in the
1990s have a lot of significance to the Internet of today.

> But DNSBLs can't solve the problem when spam is sent via botnets. By the

The Spamhaus XBL and Spamhaus PBL are pretty useful in denying
connections from botnets. You should try them - in the arsenal of
spam-fighting tools, they are the probably most effective ones.

-- Matthias

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC

[Dave Cridland]

On Tue Nov  4 14:28:19 2008, The IESG wrote:
The IESG has received a request from an individual submitter to  
consider

the following document:

- 'DNS-Based Service Discovery '
as an Informational RFC


I note that this document is Informational, yet forms the basis for  
standards track documents both in the IETF and other SDOs. It would  
be, therefore, more useful to tidy up this document and move it to  
the standards track rather than short-cutting it to an Informational.


In the course of reviewing XEP-0174 changes for the XSF, I reviewed  
this document in detail, particularly on the subject of record  
formatting. The following are my own views, however, not those of the  
XSF.


I believe the document is exceedingly unclear, and as such unsuitable  
for publication in its present form. It is badly laid out, and  
contains a mixture of specification, rationale, marketing, and  
confusing reiteration of other documents, making the document much  
harder to extract useful information from than it needs to be.


I'm also unconvinced that this represents the state of the protocol  
as deployed by various Apple devices anyway. If this is to be a  
serious attempt to document a working protocol, it must reflect  
reality.


Section by Section:

1) The last two paragraphs of the Introduction can largely be snipped.

2) Use of RFC 2119 language in an Informational document is a curious  
one - I'm not against its use, but in general terms, the document  
does not appear to use these terms in quite the way I'd expect. In  
particular, the terms appear to be used to express designer's  
preferences rather than actual interoperability requirements.


3) Seems okay.

4) Okay.

4.1) The parenthesis in the second paragraph is superfluous - one  
expects that any reader would surely understand DNS to this level.


From about the top of page 6, however, it gets really bad. Only the  
top paragraph, diagram, and first two sentences of the subsequent  
paragraph are needed here. The rest of the page is waffle and  
repetition.


Page 7 is mostly okay - it could probably be condensed.

I'd question the purpose of Punycode here, though, if the records are  
already usefully deployed in UTF-8, since the records are only to be  
found by querying in the first place. Is this actually supported in  
the field? (As in, do clients try punycode?)


4.2) I'm always a little wary of UI detail in IETF documents, but the  
suggestions seem reasonable.


4.3) As near as I can tell, the backslah-escaping of DNS-SD instance  
names is done externally as well as internally, so this section is  
exceedingly misleading.


4.4) Appears to be largely marketing, or rationale, and is confusing  
in this section.


4.5) Appears to be largely rationale.

5) Reiterates SRV

6) Okay, although I don't understand the point of mandating an empty  
TXT record, it being about the only portion of the document not  
backed up by twenty-five pages of rationale including words like  
"compelling". I'm guessing it might be to avoid negative caching,  
thus placing the statement "This service has no parameters" under the  
control of normal TTL, etc. That would, naturally, be a compelling  
reason.


It's a shame that several TXT records for services are absent on  
dns-sd.org, then, but "it's only a SHOULD" - ho, ho.


6.1) Massively confusing, since it reiterates RFC 1035 in such a way  
that without referring to RFC 1035 to gain the context, one is led to  
believe that the actual strings must follow this format, instead of  
it merely being wire format.


6.2) All jolly good, although I note that several Apple devices  
appear to use a single TXT string containing a comma seperated list  
of values, that is, if you forgive my pseudo-ABNF:


txt_value = txt_record
txt_record = keypair ["," keypair]

Instead of the apparent specification:

txt_value = "" / (1*txt_record)
txt_record = keypair

I wonder whether this is an earlier version of the specification, or  
a non-standard usage of a non-standard, or whether even Apple people  
can't glean the single useful fact from this entire page of prose.


6.3) Astonishingly, this section is reasonably concise, and contains  
information which is, dare I say it, useful. Thankfully it, too,  
appears to be ignored by various Apple devices.


6.4) This section could usefully be folded into 6.2, and the  
resultant prose condensed into perhaps a paragraph or two, and  
potentially use ABNF for clarity:


keypair = key ["=" value]
key = 1*key_char
key_char = %x20-%x3C / %x3E-%x7E
value = *OCTET

6.5) I seem to have inadvertantly included much of this in my ABNF  
above in 6 characters. The last two paragraphs seem superfluous -  
specifications for debugging tools?


6.6) Describes the wire format, which strikes me as very much less  
than useful. Again, I've seen serious confusion result from this.  
Zone file format records would be much more useful to most people.


6.7) It's deeply unclear, to me, wh

RE: IP-based reputation services vs. DNSBL (long)

[Lawrence Rosen]

> Not to belabor the totally painfully obvious, but DNSBLs are a
> protocol for communicating email sender reputation that are
> implemented in open source software without patent encumbrances and
> have been for a deacade.

Wonderful! /Larry



> -Original Message-
> From: John Levine [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 10, 2008 1:38 PM
> To: ietf@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: Re: IP-based reputation services vs. DNSBL (long)
> 
> >I hope the charter, unlike the previous one, will require the
> >development of a protocol for communicating email sender reputation
> >that can be implemented in email products without known patent
> >encumbrances that are incompatible with open source software. Email
> >is simply too important to allow otherwise.
> 
> Not to belabor the totally painfully obvious, but DNSBLs are a
> protocol for communicating email sender reputation that are
> implemented in open source software without patent encumbrances and
> have been for a deacade.
> 
> What would be the point of yet another WG to reinvent this wheel?
> 
> R's,
> John

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Punycode at ASCII for IDN & MDN via Y2K Project Management

[linuxa linux]

--- On Sun, 9/11/08, Ruszlan Gaszanov <[EMAIL PROTECTED]> wrote:

> From: Ruszlan Gaszanov <[EMAIL PROTECTED]>
> Subject: RE: Punycode at ASCII for IDN & MDN via Y2K Project Management
> To: [EMAIL PROTECTED], ietf@ietf.org
> Date: Sunday, 9 November, 2008, 10:21 PM


> ..ASCII domain names *are* in fact
> punycode domain names
> by definition. 

That's the problem and the reason for Punycode2 allowing ASCII registrations to 
be Punycoded via Punicode2.

> As soon as you want to encode ASCII characters with
> something else, you'll
> need a new parallel DNS infrastructure and at this point a
> new version of
> DNS protocol that works...

You got this wrong because when you Punycode via Punycode2 ASCII registrations 
you will have ASCII letters however they will be in machine  code, same as IDN 
thus equal virtue and for ASCII registrations to be viewed they will be viewed 
similarly as IDN (Internationalized Domain Names / Internationalised Domain 
Names) and here also equal virtue.

> ...But the bottom line is that there is no
> way to develop a
> "new punycode" encoding ASCII domain names with
> something else then ASCII
> and implement that on existing DNS infrastructure without
> completely
> breaking the Internet, period.  

Again you are putting something which I have not said for Punycode2.  While you 
wait for learning curve developments, I suggest you use ASCII based letters for 
Punycode 2 however you machine code the ASCII registrations like you are doing 
with IDN. 

I am not a technical expert, however based on what I have gleaned can I suggest 
the 2 IDN algorithms: ToASCII and ToUnicode perhaps would need tweaks hence 
ToASCII2 and ToUnicode2 with perhaps ASCII registrations needing also an ACE 
sort prefix, say yn-- similar to xn-- that are put for IDN.  This development 
could then allow MDN (Multilingual Domain Names) that would help the users that 
are multilingual / would like multilingual text at domain name platform. 

I hope this signals to you the urgency that is required for implementing.



Regards


Meeku




  
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART Last Call review of draft-ietf-tsvwg-rsvp-proxy-proto-07.txt

[Spencer Dawkins]

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: draft-ietf-tsvwg-rsvp-proxy-proto-07.txt
Reviewer: Spencer Dawkins
Review Date: 2008-11-10
IETF LC End Date: 2008-11-14
IESG Telechat date: (not known) 


Summary: Ready for publication as Proposed Standard

Comments: none

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[SM]

Hi Jari,
At 03:33 10-11-2008, Jari Arkko wrote:
The issue is that mere conflict with work in a WG is not a 
sufficient reason to recommend against publishing. The IESG needs to 
make a judgment call that such publication would actually be harmful 
to the standardization process in the WG. For instance, in a recent 
case we approved an independent publication even if the document was 
clearly in the domain of a WG because we felt the circumstances 
supported it. You have to consider a number of aspects, where the WG 
is in its process, whether the particular submission is likely to 
confuse the process, etc.


I see your point.  I do expect the IESG to make a judgement call and 
not turn down a work merely because it may have some relation to the 
work being carried out in a Working Group.  Although I don't like the 
word "harmful", I see the rationale for that word in the text.


I don't care so much what words we use to say this, but I would like 
to see that the ability to make this judgment call is retained. This 
is why I like the current text more than the proposed one above.


I agree with you.

Regards,
-sm


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[SM]

Hi Russ,
At 14:10 09-11-2008, Russ Housley wrote:
Not all Informational and Experimental documents are 
standards-related.  Some are.  Not all Informational and 
Experimental documents are published as part of the IETF 
stream.  Some are.  I'm not sure what text change would help add clarity.


I understand that.  You provided some text in a later message which 
sounds better.


This is very similar to the point raised by John Klensin.  Since 
"harmful" is the term used in RFC 3292, I have asked Harald to 
provide some insights before making any changes to this wording.  I 
understand your point, but I want to make sure that I'm not missing 
some historical context.


Jari's message provided me an insight of why the word is used and 
about documents on which the IESG reaches conclusion 5.


The RFC Editor, in agreement with the IAB, shall manage mechanisms 
for appropriate technical review of independent submissions. 
Likewise, the IRSG, in agreement with the IAB, shall manage 
mechanisms for appropriate technical review of IRTF submissions.


That sounds better.

Regards,
-sm  


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IP-based reputation services vs. DNSBL (long)

[John Levine]

>I hope the charter, unlike the previous one, will require the
>development of a protocol for communicating email sender reputation
>that can be implemented in email products without known patent
>encumbrances that are incompatible with open source software. Email
>is simply too important to allow otherwise.

Not to belabor the totally painfully obvious, but DNSBLs are a
protocol for communicating email sender reputation that are
implemented in open source software without patent encumbrances and
have been for a deacade.

What would be the point of yet another WG to reinvent this wheel?

R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IP-based reputation services vs. DNSBL (long)

[Lawrence Rosen]

> > 2. Ask IETF to charter a working group tasked with developing a protocol
> > for communicating email sender reputation.   The group can consider
> > DNSBL as a possible solution but should not be bound by a requirement to
> > be compatible with it, or to use DNS at all.
> 
>Lisa and Chris have stated that they're open to consider chartering
> new WG if there seems to be consensus on a charter.
> 
>What about it, folks?

As one of the people who objected when the previous spam WG was under way, I
now support this proposal to form a new WG to address the technical problem.

I hope the charter, unlike the previous one, will require the development of
a protocol for communicating email sender reputation that can be implemented
in email products without known patent encumbrances that are incompatible
with open source software. Email is simply too important to allow otherwise.

Best,

/Larry


Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243
Skype: LawrenceRosen
Author of "Open Source Licensing: Software Freedom and 
Intellectual Property Law" (Prentice Hall 2004)

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> John Leslie
> Sent: Monday, November 10, 2008 12:38 PM
> To: Keith Moore
> Cc: IETF
> Subject: Re: IP-based reputation services vs. DNSBL (long)
> 
>I find myself in complete agreement with Keith's major points:
> 
> Keith Moore <[EMAIL PROTECTED]> wrote:
> >
> > 1. Several people have argued (somewhat convincingly) that:
> >...
> > It's important to keep these in mind, as they appear to make a
> > compelling case for some kind of standardized reputation service.
> 
>I might add that we don't need to standardize anything if we're
> happy with what we already have.
> 
> > 2. Several people have also related experiences of valid messages being
> > blocked by such reputation services, and of the difficulty of routing
> > around them and getting their reputations corrected.
> >...
> 
>Many "ordinary" folks are abandoning email rather than even _try_
> to fix such problems.
> 
> > 3. An informal protocol for reporting reputations using DNS has been in
> > use for several years, and such use has become widespread.  An IRTF
> > group (ASRG) began a useful effort to document this protocol.
> 
>Such an effort is clearly useful for research purposes, and should
> also be useful for any future attempts at standardization.
> 
> > 4. At some point ASRG decided that the protocol should be on the IETF
> > standards track and has requested such.
> 
>This is where we went wrong.
> 
>Well, actually we went wrong quite a while ago, when a prior IESG
> decided not to have a WG considering the spam problem in general. I
> can't entirely blame the folks who have latched onto IRTF's ASRG in
> the absence of an appropriate IESG forum.
> 
>(And now we're carrying out a flame-war here -- a clear indication
> IMHO that we need an IETF (not IRTF) list to move this discussion to.)
> 
> > This process that produced this proposal reminds me of several patterns
> > I've seen come up often in IETF.
> >
> > 1. The first pattern is when an author or group gets confused between
> > the goal of writing an informational document to describe existing
> > practice, and the goal of writing a standards-track document that
> > describes desirable practice.
> 
>This is human nature. IETF has developed protections againt this
> (which do not require flame-wars). We should use them.
> 
> > 2. The second pattern is when people insist that a widely deployed
> > protocol is inherently deserving of standardization, without further
> > vetting or changes, merely because it is widely deployed.
> 
>This is commercial nature. IETF could use better protections against
> this...
> 
> > 3. The third pattern is when a closed industry group, or an open group
> > that is not chartered to develop a standard protocol, insists that its
> > product merits standardization by IETF because it has gained consensus
> > of that group.
> 
>This is not necessarily bad. But IESG (usually) tries to avoid the
> situation getting this far -- by giving widespread notice of a WG charter
> and encouraging cross-area review _before_ IETF last-call.
> 
> > Such efforts can be considered in the IETF process as individual
> > submissions, but they need a great deal of scrutiny...
> 
>I entirely agree, even though the necessary scrutiny is easy to
> misinterpret as personal attacks by folks who "don't understand the
> situation".
> 
> > The main point to be made here is that the consensus of an external
> > group means nothing in terms of either IETF consensus or judgment of
> > technical soundness.  In particular, external groups often have a much
> > narrower view of protocol requirements than IETF does.
> 
>This is important! It's worth readin

Gen-ART review of draft-irtf-asrg-dnsbl-07

[Spencer Dawkins]

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: draft-irtf-asrg-dnsbl-07Reviewer: Spencer DawkinsReview Date: 
2008-11-10IETF LC End Date: 2008-12-02IESG Telechat date: (not known) 
Summary: Ready for publication as Proposed StandardComments: I'm not 
addressing meta-issues in this review that have already popped up during 
Last Call comments... 



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IP-based reputation services vs. DNSBL (long)

[John Leslie]

   I find myself in complete agreement with Keith's major points:

Keith Moore <[EMAIL PROTECTED]> wrote:
> 
> 1. Several people have argued (somewhat convincingly) that:
>...
> It's important to keep these in mind, as they appear to make a
> compelling case for some kind of standardized reputation service.

   I might add that we don't need to standardize anything if we're
happy with what we already have.

> 2. Several people have also related experiences of valid messages being
> blocked by such reputation services, and of the difficulty of routing
> around them and getting their reputations corrected.
>...

   Many "ordinary" folks are abandoning email rather than even _try_
to fix such problems.
 
> 3. An informal protocol for reporting reputations using DNS has been in
> use for several years, and such use has become widespread.  An IRTF
> group (ASRG) began a useful effort to document this protocol.

   Such an effort is clearly useful for research purposes, and should
also be useful for any future attempts at standardization.

> 4. At some point ASRG decided that the protocol should be on the IETF
> standards track and has requested such.

   This is where we went wrong.

   Well, actually we went wrong quite a while ago, when a prior IESG
decided not to have a WG considering the spam problem in general. I
can't entirely blame the folks who have latched onto IRTF's ASRG in
the absence of an appropriate IESG forum.

   (And now we're carrying out a flame-war here -- a clear indication
IMHO that we need an IETF (not IRTF) list to move this discussion to.)

> This process that produced this proposal reminds me of several patterns
> I've seen come up often in IETF.
> 
> 1. The first pattern is when an author or group gets confused between
> the goal of writing an informational document to describe existing
> practice, and the goal of writing a standards-track document that
> describes desirable practice.

   This is human nature. IETF has developed protections againt this
(which do not require flame-wars). We should use them.

> 2. The second pattern is when people insist that a widely deployed
> protocol is inherently deserving of standardization, without further
> vetting or changes, merely because it is widely deployed.

   This is commercial nature. IETF could use better protections against
this...

> 3. The third pattern is when a closed industry group, or an open group
> that is not chartered to develop a standard protocol, insists that its
> product merits standardization by IETF because it has gained consensus
> of that group.

   This is not necessarily bad. But IESG (usually) tries to avoid the
situation getting this far -- by giving widespread notice of a WG charter
and encouraging cross-area review _before_ IETF last-call.

> Such efforts can be considered in the IETF process as individual
> submissions, but they need a great deal of scrutiny...

   I entirely agree, even though the necessary scrutiny is easy to
misinterpret as personal attacks by folks who "don't understand the
situation".

> The main point to be made here is that the consensus of an external
> group means nothing in terms of either IETF consensus or judgment of
> technical soundness.  In particular, external groups often have a much
> narrower view of protocol requirements than IETF does.

   This is important! It's worth reading again.

> All of these patterns are associated with delays in accepting a
> standard.  They are also associated with poorer quality standards.

> So my recommendation to ASRG (and this document's authors) is as follows:
> 
> 1. Abandon the effort to publish draft-irtf-asrg-dnsbl as a standards
> track document, and instead commit to publishing it as an Informational
> document as an accurate description of existing practice.  Be sure to
> document observed limitations of existing practice.

   This is really easy to do, and wouldn't cause any delays.

> 2. Ask IETF to charter a working group tasked with developing a protocol
> for communicating email sender reputation.   The group can consider
> DNSBL as a possible solution but should not be bound by a requirement to
> be compatible with it, or to use DNS at all.

   Lisa and Chris have stated that they're open to consider chartering
new WG if there seems to be consensus on a charter.

   What about it, folks?

--
John Leslie <[EMAIL PROTECTED]>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC

[Stuart Cheshire]

On 4 Nov, 2008, at 07:50, Cyrus Daboo wrote:


Hi,

--On November 4, 2008 6:28:19 AM -0800 The IESG [EMAIL PROTECTED]> wrote:


The IESG has received a request from an individual submitter to  
consider

the following document:

- 'DNS-Based Service Discovery '
as an Informational RFC


The IANA section of the dns-sd draft describes a process for  
registration of SRV service identifiers, but there is another draft  
doing the same thing: .


So which of these two drafts is meant to define the actual SRV  
service type registry?


--
Cyrus Daboo


That text has been in DNS-SD since the start, back in 2001 when it  
was called "Discovering Named Instances of Abstract Services using  
DNS" (draft-cheshire-dnsext-nias-00.txt).


I have absolutely no ego at stake over ownership of that issue -- I  
simply put it in because someone pointed out that RFC 2782 failed to  
define an IANA registry for its service names, and since DNS-SD/NIAS  
depends on SRV records and identifying service types by name instead  
of number, without an IANA registry the specification would be  
somewhat handicapped.


Stuart Cheshire <[EMAIL PROTECTED]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Tony Finch]

On Mon, 10 Nov 2008, Keith Moore wrote:
>
> okay.  I found myself wondering if the change in address space size, and
> in granularity of assignment, might make DNSBLs less reliable.  Which is
> a different kind of scalability.

IPv6's bigger address space affects more security mechanisms than just
DNSBLs, such as defensive port scanning, traffic auditing, etc.

http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-implications-02.txt

Tony.
-- 
f.anthony.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
WIGHT PORTLAND PLYMOUTH: SOUTHWEST VEERING WEST 6 TO GALE 8. ROUGH OR VERY
ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT
FIRST.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Keith Moore]

Tony Finch wrote:
> On Mon, 10 Nov 2008, Keith Moore wrote:
>> Tony Finch wrote:
>>
>>> In any case, DNSBLs should scale roughly according to the size of the
>>> routing table, not the size of the address space.
>> What does it mean for a DNSBL to "scale"?
> 
> I was referring to the number of entries that have to be maintained.

okay.  I found myself wondering if the change in address space size, and
in granularity of assignment, might make DNSBLs less reliable.  Which is
a different kind of scalability.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Trust Decision on "Legal Provisions for IETF Documents" (datedOctober 16, 2008)

[TS Glassey]

Yeah - there is a flaw in the logic. The issue is really tricky with
Standard's Document's who's precursor document's are all done under
different copyright and license agreement's as would be the case for a
process in the IETF which took several years to start and complete with all
the changes over the last couple of years in regard to the IPR.

Bluntly without a Hold-Harmless clause in this contract - I think the IETF 
and its lawyers are in for a world of hurt... but that's just my 2 cents.



Todd Glassey

- Original Message - 
From: "Ed Juskevicius" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: "Trustees" <[EMAIL PROTECTED]>; "IETF Discussion" ;
<[EMAIL PROTECTED]>
Sent: Thursday, October 30, 2008 6:31 PM
Subject: IETF Trust Decision on "Legal Provisions for IETF Documents"
(datedOctober 16, 2008)


This message is an announce the IETF Trustees have reached consensus on
a policy entitled "Legal Provisions Relating to IETF Documents".

The Trustees met via telechat during October to review all "last call"
comments on the draft policy, and to approve the Policy.  Thank you for
all of your inputs to our deliberations, and for your patience with
process.  We are done!

Attached to this message, please find a marked version of the final
policy document as it was reviewed by Trustees in October, and a clean
version of the approved Policy document (dated October 16th) with all
changes incorporated.

FYI, the approved Policy will become effective on the same day that the
RFC Editor publishes two new RFCs as follows:

 RFC 5377 (from draft-ietf-ipr-outbound-rights-07)
 RFC 5378 (from draft-ietf-ipr-3978-incoming-09

I understand that publication of both these RFCs is imminent.  As soon
as they are published, I will close the loop by sending one more e-mail
message on this subject, and by uploading the approved and adopted
Policy document to the IETF Trust webpage.

Best Regards,


Ed  Juskevicius, on behalf of the Trustees
[EMAIL PROTECTED]







___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf








No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.5/1757 - Release Date: 10/30/2008
2:35 PM

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Tony Finch]

On Mon, 10 Nov 2008, Keith Moore wrote:
> Tony Finch wrote:
>
> > In any case, DNSBLs should scale roughly according to the size of the
> > routing table, not the size of the address space.
>
> What does it mean for a DNSBL to "scale"?

I was referring to the number of entries that have to be maintained.

Tony.
-- 
f.anthony.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
MALIN HEBRIDES: CYCLONIC BECOMING NORTHWEST 7 TO SEVERE GALE 9. VERY ROUGH OR
HIGH. SQUALLY SHOWERS. MODERATE OR POOR.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Keith Moore]

Tony Finch wrote:
> On Mon, 10 Nov 2008, Keith Moore wrote:
>> I suspect it will be very difficult to make IPv6 DNSxLs work anywhere
>> nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use
>> a different address for every SMTP conversation.
> 
> I expect that attack will make /48 or /64 listings common. This has the
> obvious downside of an increased risk of one infected host spoiling email
> connectivity for its immediate neighbours, even more than is already the
> case for IPv4 DNSBLs. Perhaps ISPs and hosting providers can mitigate that
> by enforcing address allocation policies.

Or perhaps enterprise networks will be forced to outsource their mail
submission to third parties with supposedly "trustworthy" addresses.
Which IMHO would not be a desirable result.

> In any case, DNSBLs should scale roughly according to the size of the
> routing table, not the size of the address space.

What does it mean for a DNSBL to "scale"?

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Tony Finch]

On Mon, 10 Nov 2008, Keith Moore wrote:
>
> I suspect it will be very difficult to make IPv6 DNSxLs work anywhere
> nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use
> a different address for every SMTP conversation.

I expect that attack will make /48 or /64 listings common. This has the
obvious downside of an increased risk of one infected host spoiling email
connectivity for its immediate neighbours, even more than is already the
case for IPv4 DNSBLs. Perhaps ISPs and hosting providers can mitigate that
by enforcing address allocation policies.

In any case, DNSBLs should scale roughly according to the size of the
routing table, not the size of the address space.

Tony.
-- 
f.anthony.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
FISHER: SOUTHWEST 6 TO GALE 8 BACKING SOUTH 5 OR 6. VERY ROUGH BECOMING
MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Keith Moore]

der Mouse wrote:
> [Keith Moore]
>>> The fact that [DNSBLs] are widely used is sad, not a justification
>>> for standardization.
> 
> True.  The justification is not simply that they are widely used; it is
> that they are widely used, they are often done wrong, they are of
> tremendous value when done right, and of actively negative value when
> done wrong.

I agree that this might be a justification for standardizing some sort
of reputation protocol.  But it's not at all clear the document at hand
describes a protocol which is technically sound, and it certainly
doesn't have rough IETF consensus.  I'm willing to defer judgment about
whether such a protocol might reasonably resemble DNSxL, or whether it
can reasonably use DNS at all - but I have reason to doubt it.

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Keith Moore]

Steve Linford wrote:

> I certainly agree that there are hundreds of small DNSBLs run from kid's
> bedrooms which list on incomprehensible wildly over-broad policies and
> that such DNSBLs are both antagonistic and useless and as a result are
> used by almost nobody - that's 'market force'. But to pretend that the
> dozen major DNSBLs make listings based on "unauthenticated rumor" or
> "because the IP did not have 'mail.' or 'mx.'" is just silly
> mud-slinging itself based on equally "unauthenticated rumor" and is
> especially odd if it's coming from within IETF itself.

It's only odd if you refuse to recognize our experiences as valid.

> The fact some DNSBLs are in widespread use (I can speak only for
> Spamhaus, our DNSBLs are today used by something in the region of 2/3 of
> internet networks) is good reason why it's important to publish a
> standard and format for the technology.

Wrong.  Read RFC 2026 and stop demanding that we change our technical
criteria just for you.

> Like everyone we'd like to see poorly managed, arrogant or anonymous
> DNSBLs given a high standard to attain ('shape up or ship out'), since
> an irresponsible DNSBL listing something for little discernible reason
> is what creates "I hate all DNSBLs" poster children. Lets have the
> technology, standards and how to do it correctly published for the
> future and leave aside silly "I once had a client blacklisted"
> arguments. The question "are DNSBLs bad for the world" or "are DNS
> queries a bad use" is irrelevant to the need for draft-irtf-asrg-dnsbl
> and a false argument against it.
> 
> I can see no legitimate reason for IETF not publishing
> draft-irtf-asrg-dnsbl.

The proposal has neither technical soundness nor rough consensus of the
community.

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[der Mouse]

[Keith Moore]
>> The fact that [DNSBLs] are widely used is sad, not a justification
>> for standardization.

True.  The justification is not simply that they are widely used; it is
that they are widely used, they are often done wrong, they are of
tremendous value when done right, and of actively negative value when
done wrong.

[John C Klensin]
> Sadly, I have to agree with Keith.   While these lists are a fact of
> life today, and I would favor an informational document or document
> that simply describes how they work and the issues they raise,
> standardizing them and formally recommending their use is not
> desirable at least without some major changes in our email model and
> standards for what gets addresses onto --and, more important, off
> of-- those lists.

And this, I mostly disagree with.

Just because something is something we'd rather not have around does
not mean standardizing it is a bad idea.  SSH is an example; I would
much rather the net were still the open, friendly place it was back in
the ARPAnet and NSFnet days, where SSH was unnecessary.  But that's no
longer today's net, and SSH or something like it is necessary; I think
standardizing it is a Good Thing (indeed, a necessary thing in the case
of SSH).

Similarly, I too find DNSBLs' necessity regrettable.  But I do find
them necessary, and I think we're better off standardizing those
aspects that are currently agreed-upon enough to standardize.

I do not think that standards for how addresses get onto and off of
DNSBLs is even desirable.  As long as the list is technically well-run
and adheres to what it tells its users its (de)listing policies are,
exactly what those policies are is entirely up to the list; a wide
variety of policies is good because there is an equally wide variety of
receiving sites' desires - and because the price to the net of a DNSL
nobody uses is so close to zero as no matter, so there's no harm in
having a wide variety available to pick from.

And that "technically well-run" is the part that I think not only can
be standardized but should be standardized.

Not that my opinion counts for all _that_ much, since I'm not the one
doing the work.  But it's not total randomness; email operations and
administration has been part of my paid job for some 18 of the last 25
years, and I was on the CAUCE Canada board before we merged with CAUCE
USA.  (I think I'm actually still technically on CAUCE North America
board, but I've been trying to get out of abuse-fighting for a year or
two now).

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTML[EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Last Call: draft-ietf-geopriv-pdif-lo-profile (GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations) to Proposed Standard

[creed]

To whom it may concern.

Please consider the following recommended changes to the document. I am
not sure of how to provide comments as I have not provided official
comments to an internet proposed standard before - I have always done so
much earlier in the process.

In general, an excellent easy to read and understand document.

Thanks

Carl Reed, PhD
CTO
Open Geospatial Consortium

===
In the abstract change:



To



Reason: Many readers may not know what the GML TLA means. Further, there
are several versions of GML and it is there fore important to refer to the
correct version. Finally, there should be a normative reference to the
appropriate GML document. The reference would be:

[OGC GML 3.1.1] Portele, C., Cox, S., Daisy, P.,Lake, R., Whiteside, A.
Geography Markup Language (GML) 3.1.1. July 2003.
http://portal.opengeospatial.org/files/?artifact_id=4700


In the introduction change:

GMLv3

to

GMLv3.1.1


In the introduction second paragraph Target is not defined.



In Using Location Information section 3

The use of the word "chunks". Never seen this is any standard before :-)
Anyway, perhaps a few words on exactly what is meant by a chunk, such as
"A chunk is a discrete location element".

--

3.1.  Single Civic Location Information

Suggest also providing an example XML snippet showing how the civic
location is encoded.

--

Section 5, bottom of page 14 there is a reference to an OGC URN. URN
urn:ogc:def:crs:EPSG::4326.

I would suggest that two references be stated.

[RFC 5165] Reed, C.  A Uniform Resource Name (URN) Namespace for the Open
Geospatial Consortium (OGC). April 2008

[OGC CRS URN Usage] Whiteside, A. GML 3.1.1 Common CRSs Profile. November
2005. http://portal.opengeospatial.org/files/?artifact_id=13204

Reason: Background information and guidance on the use and resolution of
OGC URNs.



Section 5.1 bottom of page 15 - dimensioanl - misspelling.

Also, this is just a thought for future work - a maximum of 15 points is
very restrictive in terms of the geospatial and location services domain.
So, is good that the document states "SHOULD" on this restriction.

---

Section 5.2 point:

Suggest changing: geodetic LI to geodetic location information (LI) as
this is the first use of LI.

---







___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Tony Finch]

On Sun, 9 Nov 2008, Tony Hansen wrote:
>
> Does anyone have issues with the use of this protocol for WHITE lists?

DNSWLs already exist and are used by e.g. SpamAssassin.

Tony.
-- 
f.anthony.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
TYNE DOGGER FISHER: SOUTHWEST 6 TO GALE 8, BACKING SOUTH 5 OR 6 IN FISHER.
ROUGH OR VERY ROUGH, OCCASIONALLY MODERATE LATER. SHOWERS. MODERATE OR GOOD.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Steve Linford]

I'm coming in a bit late into this strange argument, but from what  
I'm reading it sounds like someone *from IETF* is contesting the need  
for DNSBLs and thus the need for draft-irtf-asrg-dnsbl and on grounds  
which are misguided at best.


I certainly agree that there are hundreds of small DNSBLs run from  
kid's bedrooms which list on incomprehensible wildly over-broad  
policies and that such DNSBLs are both antagonistic and useless and  
as a result are used by almost nobody - that's 'market force'. But to  
pretend that the dozen major DNSBLs make listings based on  
"unauthenticated rumor" or "because the IP did not have 'mail.' or  
'mx.'" is just silly mud-slinging itself based on equally  
"unauthenticated rumor" and is especially odd if it's coming from  
within IETF itself.


The fact some DNSBLs are in widespread use (I can speak only for  
Spamhaus, our DNSBLs are today used by something in the region of 2/3  
of internet networks) is good reason why it's important to publish a  
standard and format for the technology.


Like everyone we'd like to see poorly managed, arrogant or anonymous  
DNSBLs given a high standard to attain ('shape up or ship out'),  
since an irresponsible DNSBL listing something for little discernible  
reason is what creates "I hate all DNSBLs" poster children. Lets have  
the technology, standards and how to do it correctly published for  
the future and leave aside silly "I once had a client blacklisted"  
arguments. The question "are DNSBLs bad for the world" or "are DNS  
queries a bad use" is irrelevant to the need for draft-irtf-asrg- 
dnsbl and a false argument against it.


I can see no legitimate reason for IETF not publishing draft-irtf- 
asrg-dnsbl.


  Steve Linford
  The Spamhaus Project
  http://www.spamhaus.org




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Russ Housley]

John:

In the previous note from me, I responded to you and Jari on your 
main points.  In this note, I am responding to your editorial points.



Textual nit-picking

* The second full paragraph of the Introduction ("The IETF is
responsible..."), second sentence, should read "..., and any
other IETF-generated Informational or Experimental documents".
Otherwise, one may suck most of the Independent Submission
stream into the IETF stream, contradicting the rest of the
document. Part of the problem with the text that is now in the
document is that there is no clear definition of
"standards-related".


I agree.  The revised sentence reads: "These RFCs, and any other 
IETF-generated Informational or Experimental documents, are reviewed 
by appropriate IETF bodies and published as part of the IETF Stream."



* The document is confused about tense and mood of particular
words  and the general tone of the language used.  For example,
Section 1 Paragraph 5, last sentence, says "...was a
considerable drain... this is not" and should probably should
have been "...this was not".   As another example, consider the
numbered list in Section 3.  The first item says "has not
found", but the others are "The IESG finds".  Note also the
difference between "a finding" and the result of an unsuccessful
search ("we looked for it and didn't find it"). Personally, I
believe that the notion of the IESG making "findings"
excessively judicial -- several of these items are really
statements about the IESG's beliefs--  but that is a matter of
taste.


Agree: s/this is not/this was not/

To make them all parallel in structure, the first numbered item in 
section 3 becomes: "1. The IESG finds no conflict between this 
document and IETF work."


In RFC 3932, these numbered items (except the first one, which is the 
same until the modification above) begin "The IESG thinks"  During 
pre-Last-Call-review, I received feedback that "The IESG finds" was a 
better.  Now, you propose "The IESG believes".I do believe that 
the current wording is better than the original.  I'm willing to 
change it to something else if there is consensus to do so.  What do 
other reviewers find/think/believe/prefer?



* The assertion in paragraph 7 of Section 1 is not correct.
While it probably was the case in the years _immediately_
preceding 2006, there was a period of several years in which the
IAB performed a (sometimes pro-forma) review of IRTF
Informational and Experimental documents and then published them
as IAB documents, with minimal or no interaction with the IESG.
Of course, IRTF submissions onto the standards track (if not
entirely prohibited) are outside the scope of this document.


I suggest the following change to the first sentence in that 
paragraph: "Prior to 2006, documents from the IRTF were treated as 
either IAB submissions or individual submissions via the RFC Editor."



* If you really want to right to claim "harmful to the
Internet", then Section 6 is incomplete, because some of the
classes of harm that you might be trying to prevent involve
security.


Are you talking about this paragraph?

   If the IESG does not find any conflict between an independent
   submission and IETF work, then the RFC Editor is responsible for
   judging the technical merits for that submission, including
   considerations of possible harm to the Internet.  If the IESG does
   not find any conflict between an IRTF submission and IETF work, then
   the IRSG is responsible for judging the technical merits for that
   submission, including considerations of possible harm to the
   Internet.


* Finally, unless the omission from the Acknowledgments was
intended as an editorial comment, I call your attention to the
rather extensive discussion I participated in about this
document among Jari, Olaf, yourself, and sometimes Leslie and
Harald in early October.   Although I identified the historical
problem with the description of IRTF processes there (a comment
that was apparently ignored, since the problematic text is still
present), several of my comments made it into the document.  I
believe that that the IETF's IPR rules, as well as ordinary
courtesy, require that set of contributions (which certainly
include Jari's) be reflected in the Acknowledgments.   That is
clearly a nit and, at some level, I don't care.   But it also
suggests, especially in context with some of the issues raised
above, that this document has been handled somewhat less
carefully that might be appropriate for something of its
importance.


The acknowledgements now include these names:  Jari Arkko, Leslie 
Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, and Olaf 
Kolkman.  My apologies to anyone who was inadvertently omitted.  If 
others ought to be included as well, please speak up.


Russ 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Russ Housley]

John & Jari:

Let me start off by saying that RFC 3932 is already a part of the 
daily procedures we operate on. Draft-housley was written to make an 
incremental improvement on it. This incremental improvement is the 
publication of the headers and boilerplates document, which allows 
us to simplify the process for independent submissions and requires 
less use of IESG notes. I believe we both share the opinion that 
these are necessary and useful improvements. And, given that the 
headers and boilerplates change is going forward I hope we can 
accomplish the 3932 revision at the same time.


Some more detailed answers:


(1)  The IESG should never make an assertion that is known to be
false.  ...  Even if the IESG has not
reviewed a document, it doesn't imply that "the IETF" has not.


I agree that some independent submission stream documents have been 
in the IETF discussions. The issue is whether any sort of final 
review occurred. I'd be happy to see a wording change here. E.g., 
"Documents published in streams other than the IETF Stream are not 
reviewed by the IETF for such things ..." => "Documents published in 
streams other than the IETF Stream do not get a full review and are 
not required to get any review by the IETF for such things ..."


Even if such a document started in the IETF process, it did not 
complete the IETF process.


I can imagine a situation where a document goes to IETF Last Call 
that demonstrates that there is not consensus, and that document ends 
up being published in the individual submission stream, but that has 
not happened in my memory.  It certainly is not the normal situation.


I suggest: "Documents published in streams other than the IETF Stream 
do not receive full review by the IETF for such things as security, 
congestion control, or inappropriate interaction with deployed protocols."



The second sentence of that paragraph should be
removed entirely unless the IESG wants to deprive itself of
flexibility to formally ask for community input by prohibiting
the use of Last Calls on Independent Submission drafts (a
flexibility that language in 4846 was intended to preserve).


As I commented to SM, I do believe the IESG needs to have the room 
to make judgment calls. In the case that I mentioned in that e-mail, 
we actually did ask for community input (after first getting some 
unsolicited input :-), though not in the form of document review or 
a last call. Again, I would like to see a change in the document on this.


I suggest a replacement sentence: "Generally, there is no attempt for 
IETF consensus or IESG approval."



(2) The numbered list in Section 3 is the substantive core of
this document.  "Harmful" in Item 3 is "potentially damaging to,
or problematic for, the IETF Standards Process", not "harmful to
the Internet".


Yes. And this is what is says: "harmful to the IETF work".


"Potentially" is important there too.  The IESG
should not be expected to foretell possible futures or provide
an analysis of how damage might occur: it should merely have to
have a reasonable basis for believing that WG or other standards
process disruption might occur or that an end-run is being
attempted.


I agree and I support adding this word.


The revised sentence says: "The IESG finds that publication is 
potentially harmful to the IETF work done in WG  and recommends 
not publishing the document at this time."


On your sweeping issue: I believe most of the practical 
applicability of RFC 3932 has been in the area of checking for 
conflict with WG process (response 3) and IANA rules (response 4). 
Again, response 3 text is IMHO already clear. That being said, I do 
believe there should be an opportunity check for possible harm as 
stated in response 5 as well. From my perspective that item is 
reserved for the cases where we, e.g., old protocols for which no 
IANA procedures have been defined. The practical reality is that we 
find such cases daily. We could make the text more specific, require 
more last calls and steps before such claims can be made. But 
frankly, I do not want to turn the independent submission process 
into a one that requires IETF review; it seems counter-intuitive. 
The IESG should make a quick check as described in the document, and 
if they screw up, the next step should be an appeal or talking to 
the nomcom. Of course, as I already explained I don't mind stating 
that a last call might be a useful tool in some special cases.


This was the whole point of RFC 3932 and the subsequent creation of 
the RFC Editorial Board.


The IESG received the following comment.  I think it is okay to share 
here with the sender's identity removed.


|  I think the draft is good as it is. I don't plan to respond in detail to
|  John Klensin's comments, but my bottom line is that I think the proposed
|  wording is correct. I do support the independence of the Independent stream,
|  but I don't think that deprives the IESG of the right to speak for the
|  IETF

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Dave CROCKER]

Steven M. Bellovin wrote:

My concern is centralization of power.  If used properly, white lists
are fine.  If used improperly, they're a way to form an email cartel,
forcing organizations to buy email transit from a member of the inner
circle.



Steve,

Email reputation lists have been around for a very long time.  The current 
specification codifies this existing practice.  So we have plenty of track 
record to test your concern.


Perhaps you know of some pattern that validates that concern, but I don't.

Such services have always been easy to set up and, indeed, there is a wide range 
of reputation services. (Positive reputation services are more recent so there 
is a smaller set to evaluate... so far.)


A standard reduces switching costs, so that consumers of reputation data are not 
locked in to their current reputation provider.


Hence, standardizing the details for obtaining reputation data -- postivie or 
negative -- ought to mitigate against centralization.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Keith Moore]

John Levine wrote:

> As I said a few messages up in this string, although the structure of
> IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs aren't
> that mature yet and one of my goals was to make them interoperate
> equally well so, for example, if you find you're using cruddy ones you
> can easily switch to better ones.

I suspect it will be very difficult to make IPv6 DNSxLs work anywhere
nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use
a different address for every SMTP conversation.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Livingood, Jason]

> -Original Message-
> From: Keith Moore [mailto:[EMAIL PROTECTED] 
>
> > Keith - I encourage you to consult with several very large 
> scale email domains around the world to see if they think 
> that DNSxBLs are useful, effective, and in widespread use or not.
> 
> Jason - I encourage you to consult with users whose mail 
> isn't getting delivered, and see whether they think DNSBLs 
> are useful and effective, or whether their mail is 
> effectively being bounced by third parties who aren't 
> accountable for their actions.

The buck ultimately stops with any mail admin (or user of any particular
technology), not the DNSxLs and any other filtering tools they may
choose to employ.  As for consulting with users, you will find me (and
my team) posting (and reading of course) almost daily on the Comcast
section of BroadbandReports and our customer support forum's email
section (http://forums.comcast.net).  I could give you countless other
examples of how I am my team works with senders and customers, and works
to increase our transparency (such as http://postmaster.comcast.net). I
work hard to be in touch with customers, and consider it a centrally
important part of my job to understand how my team's use of technology
affects our customers and other users on the Internet.  Also, I am sure
you would not be surprised to know there is a correlation betewen spam
effectiveness and user satisfaction with email.  Yes, there are always
individual sender problems, but no matter the tool or technology you
always have exceptional use cases that must be worked through.

Regards
Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[John Levine]

> That's a rather narrow view. Very large numbers of people think that
> Instant Messaging is a far superior alternative to DNSBLs, not to
> mention VoIP, web forums and other variations on the theme.

I can certainly believe that there are people who think that, but if
those very large numbers of people aren't even aware that IM, VoIP,
and web forums also use DNSBLs and DNSWLs to manage their abuse
problems, it's hard to see how their impressions would be helpful
here.

> I think it is a positive thing to document the technology of DNSBLs
> but I have no idea why this has come to the IETF.

As I said a few messages up in this string, although the structure of
IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs aren't
that mature yet and one of my goals was to make them interoperate
equally well so, for example, if you find you're using cruddy ones you
can easily switch to better ones.

R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Jari Arkko]

John,

That was a long list of issues.

Let me start off by saying that RFC 3932 is already a part of the daily 
procedures we operate on. Draft-housley was written to make an 
incremental improvement on it. This incremental improvement is the 
publication of the headers and boilerplates document, which allows us to 
simplify the process for independent submissions and requires less use 
of IESG notes. I believe we both share the opinion that these are 
necessary and useful improvements. And, given that the headers and 
boilerplates change is going forward I hope we can accomplish the 3932 
revision at the same time.


Some more detailed answers:


(1)  The IESG should never make an assertion that is known to be
false.  ...  Even if the IESG has not
reviewed a document, it doesn't imply that "the IETF" has not.


I agree that some independent submission stream documents have been in 
the IETF discussions. The issue is whether any sort of final review 
occurred. I'd be happy to see a wording change here. E.g., "Documents 
published in streams other than the IETF Stream are not reviewed by the 
IETF for such things ..." => "Documents published in streams other than 
the IETF Stream do not get a full review and are not required to get any 
review by the IETF for such things ..."



The second sentence of that paragraph should be
removed entirely unless the IESG wants to deprive itself of
flexibility to formally ask for community input by prohibiting
the use of Last Calls on Independent Submission drafts (a
flexibility that language in 4846 was intended to preserve).


As I commented to SM, I do believe the IESG needs to have the room to 
make judgment calls. In the case that I mentioned in that e-mail, we 
actually did ask for community input (after first getting some 
unsolicited input :-), though not in the form of document review or a 
last call. Again, I would like to see a change in the document on this.



(2) The numbered list in Section 3 is the substantive core of
this document.  "Harmful" in Item 3 is "potentially damaging to,
or problematic for, the IETF Standards Process", not "harmful to
the Internet".


Yes. And this is what is says: "harmful to the IETF work".


"Potentially" is important there too.  The IESG
should not be expected to foretell possible futures or provide
an analysis of how damage might occur: it should merely have to
have a reasonable basis for believing that WG or other standards
process disruption might occur or that an end-run is being
attempted.
  


I agree and I support adding this word.

On your sweeping issue: I believe most of the practical applicability of 
RFC 3932 has been in the area of checking for conflict with WG process 
(response 3) and IANA rules (response 4). Again, response 3 text is IMHO 
already clear. That being said, I do believe there should be an 
opportunity check for possible harm as stated in response 5 as well. 
From my perspective that item is reserved for the cases where we, e.g., 
old protocols for which no IANA procedures have been defined. The 
practical reality is that we find such cases daily. We could make the 
text more specific, require more last calls and steps before such claims 
can be made. But frankly, I do not want to turn the independent 
submission process into a one that requires IETF review; it seems 
counter-intuitive. The IESG should make a quick check as described in 
the document, and if they screw up, the next step should be an appeal or 
talking to the nomcom. Of course, as I already explained I don't mind 
stating that a last call might be a useful tool in some special cases.


Jari


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Jari Arkko]

SM,

Thanks for your review and thank you Russ for the edits. I'll just 
comment on the one remaining issue:



"3. The IESG finds that publication is harmful to the IETF work done
in WG  and recommends not publishing the document at this time."

I don't think that harmful is appropriate here. I gather that the aim 
is to prevent circumvention of the IETF process and conflicts with 
work being carried out by the Working Group.


It could be phrased as:

The IESG finds that this work is related to IETF work done in WG 
and recommends not publishing the document at this time.


The issue is that mere conflict with work in a WG is not a sufficient 
reason to recommend against publishing. The IESG needs to make a 
judgment call that such publication would actually be harmful to the 
standardization process in the WG. For instance, in a recent case we 
approved an independent publication even if the document was clearly in 
the domain of a WG because we felt the circumstances supported it. You 
have to consider a number of aspects, where the WG is in its process, 
whether the particular submission is likely to confuse the process, etc.


I don't care so much what words we use to say this, but I would like to 
see that the ability to make this judgment call is retained. This is why 
I like the current text more than the proposed one above.


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of draft-ietf-behave-dccp-04

[Christian Vogt]

Rémi Denis-Courmont wrote:


endpoint independent mapping and filtering enables address referrals
between application instances (which use the same port number).  This
advantage is independent of the transport protocol and the connection
model.  The exceptions you are listing are special cases for NAT'ing
in general, not only with regard to the usefulness of endpoint
independent mapping and filtering.


I don't disagree... Lets say that endpoint independent mapping is  
one half
of a solution. We need another half: either a "simultaneous hole  
punching"

mechanism, (and/)or endpoint independent _filtering_...


Maybe that was our misunderstanding:  Yes, we need both, endpoint- 
independent
mapping /and/ filtering.  But re-read my email; I in fact talked about  
both.


- Christian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of draft-ietf-behave-dccp-04

[Rémi Denis-Courmont]

On Monday 10 November 2008 09:39:31 ext Christian Vogt, you wrote:
> endpoint independent mapping and filtering enables address referrals
> between application instances (which use the same port number).  This
> advantage is independent of the transport protocol and the connection
> model.  The exceptions you are listing are special cases for NAT'ing
> in general, not only with regard to the usefulness of endpoint
> independent mapping and filtering.

I don't disagree... Lets say that endpoint independent mapping is one half of 
a solution. We need another half: either a "simultaneous hole punching" 
mechanism, (and/)or endpoint independent _filtering_. With neither of these, 
address referrals from endpoint independent mappings are essentially 
unusable.

As we have painfully learned in MMUSIC, this is not completely obvious. It 
works rather well for UDP, but it is poorly supported for TCP in the real 
world. And then DCCP had to be explicitly extended, as it did not support it 
at all.

If we assume that all IETF transports will support simultaneous hole punching, 
then yes, endpoint independent mapping.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf