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

From: "O'Reirdan, Michael" <[email-masked]>
Date: Wed, 5 Oct 2011 20:21:17 +0000

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

Mike O'Reirdan

http://tools.ietf.org/html/draft-oreirdan-rosenwald-ipv6mail-transition-01

---

From: "John Levine" <[email-masked]>
Date: 8 Oct 2011 05:25:36 -0000

>http://tools.ietf.org/html/draft-oreirdan-rosenwald-ipv6mail-transition-01

That version is dated Sept 12.  Is there supposed to be a newer one?

R's,
John

---

From: "O'Reirdan, Michael" <[email-masked]>
Date: Sat, 8 Oct 2011 17:06:01 +0000

It has been out since then but noone has commented, the previous release was a 00
________________________________________
From: John Levine [[email-masked]]
Sent: 08 October 2011 01:25
To: [email-masked]
Cc: O'Reirdan, Michael
Subject: Re: [apps-discuss] New release of draft-oreirdan-rosenwald-ipv6mail-transition-01

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 20 Oct 2011 12:48:25 -0700

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.

-MSK

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

Mike O'Reirdan