Re: [apps-discuss] New release of draft-oreirdan-rosenwald-ipv6mail-transition-01

"Murray S. Kucherawy" <> Thu, 20 October 2011 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5046B1F0C3D for <>; Thu, 20 Oct 2011 12:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.678
X-Spam-Status: No, score=-102.678 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v7k14+q3NJl9 for <>; Thu, 20 Oct 2011 12:48:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A611321F8AA8 for <>; Thu, 20 Oct 2011 12:48:26 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Thu, 20 Oct 2011 12:48:26 -0700
From: "Murray S. Kucherawy" <>
To: "Michael O'Reirdan @ Comcast" <>, "" <>
Date: Thu, 20 Oct 2011 12:48:25 -0700
Thread-Topic: [apps-discuss] New release of draft-oreirdan-rosenwald-ipv6mail-transition-01
Thread-Index: AQHMg5xWyPFcjUZyOkmPH2zQ7IYUipWFs7Rg
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C14BA6EXCHC2corpclo_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [apps-discuss] New release of draft-oreirdan-rosenwald-ipv6mail-transition-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Oct 2011 19:48:29 -0000

Hi Mike,

I think it's going to be important for documents like this one to exist as ISPs go through these transitions.  I'm glad your team is taking the time to get it started and get people talking about it.  I'd be happy to contribute some text to various sections.

This draft appears to be still pretty young so this is a more cursory review than I would give something approaching a Last Call.  Thus, a few general points:

Sections 1.4-1.6 should be subsections of, or even just paragraphs in, Section 1.1.  You might even consider just including them in the References section.  (And the current RFC for SMTP is 5321.)

Section 1.7 mentions being provisioned a public IP address, but if any kind of NAT is in use inside the service provider, the end user isn't exactly provisioned a public IP address (in the sense that the end user might now be sharing that address).

Section 3 should probably include a note to the RFC Editor to remove it prior to publication.  I imagine when this finally goes up for publication that we would have reached a point where a better understanding of these issues has been attained.

Section 5 might benefit from a brief discussion of Dual-Stack or Dual-Stack Lite.  There might be an RFC or two to reference.

Section 6, paragraph TRANS2: I didn't understand what the last sentence is trying to say, especially that IPv6 services "SHOULD be treated as production by other Internet organizations."  What does that mean, exactly?

Section 7, paragraph POST2: Same.

I expect Sections 8 and 9 will be big.  The next revision might benefit from having an outline in the form of some subsection headings that we can then fill out.

Section 12 should probably be removed.  The details about abuse issues can appear in Section 15 when they become available, and/or in sections to which those details are specific (8, 9, 10, and 11, for example).

Section 13: The RFCs listed there should probably be identified by name or acronym; as presented, most people won't know what they are or why they're relevant.  They should also all appear in the Informative References section.  (And DKIM is now RFC6376.)   I also note that RFC4408 (SPF) is absent; was that intentional?

Also Section 13: Since you mention domain reputation, you might want to reference the REPUTE working group drafts (as works-in-progress) once that group actually forms.

Section 14: Paragraph two refers to "customer residence", but doesn't this document also apply to business customers?

Also Section 14: Paragraph three talks about public announcement of CIDR block sizes.  A lot more needs to be said here, I think.  If we need a mechanism to do this, we should think about creating a design team for such a method and build and test a prototype.  It might also tie in to what the WEIRDS group (not yet a WG) is seeking to provide.

Also Section 14: Paragraph four has one sentence about throttling.  I think this is a topic ripe for expansion and even some BCP-type text.

Also Section 14: Paragraph five (6to4, NAT) doesn't seem clear to me.

Section 15: I think this section will become a lot bigger as IPv6-specific abuse items reveal themselves.  I imagine SECDIR will certainly require something a lot more detailed than what's there now.

Section 16: "PII" needs to be expanded and defined on first use.

General: It seems like this document should refer to RFC6302 (Logging Recommendations for Internet-Facing Servers), and maybe make some suggestions about what ISPs should log in correspondence.


From: [] On Behalf Of O'Reirdan, Michael
Sent: Wednesday, October 05, 2011 1:21 PM
Subject: [apps-discuss] New release of draft-oreirdan-rosenwald-ipv6mail-transition-01

Please take a look at this and comment, it got lots of comments on the 00 version

Mike O'Reirdan