Subject: (ngtrans) ipv6-smtp-requirement comments?

From: Bob Fink <[email-masked]>
Date: Thu, 25 Oct 2001 17:16:50 -0700

ietf-822 & ietf-smtp folk,

The following IETF NGTRANS ipv6-smtp-requirement I-D has just finished WG 
last call for forwarding as an Informational RFC. Randy Bush (our AD) 
suggested that we also circulate it to various groups that might have 
comments otherwise uncovered in ngtrans as it also covers practice.

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt>

So, please let the ngtrans list now if you have any problems with 
forwarding this draft, preferably by 1 November.

	NGtrans List <[email-masked]>

Thanks,

Bob Fink
ngtrans co-chair

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 26 Oct 2001 12:09:34 +0200

Bob Fink <[email-masked]>
> forwarding this draft, preferably by 1 November.

I have one real question and two quibbles.

What should an IPv6-only SMTP sender do if there target domain has no MX,
no AAAA/A6 and one A RR?

The easiest solution might be to mandate that IPv6-only SMTP senders must
be able to use a last-resort relay (which presumably would be a dual-stack
smarthost).

The draft uses 1.x.x.x IP addresses. It might be better to use 192.0.2.x
addresses; they're reserved for use in examples.

Finally, it appears that I sent some comments already and my name was
mispasted.

--Arnt

---

From: [email-masked]
Date: Fri, 26 Oct 2001 08:54:29 -0400

> forwarding this draft, preferably by 1 November.

Technically, I see no major issues - there are a few places where I don't
think we *know* the "best current practice" yet, but those are all carefully
worded with "implementation dependent".

In section 5, there is a discussion of SERVFAIL returns from broken DNS
servers (which I've seen myself in production).  That could use a one-sentence
clarification that the problem is the DNS server only having A records for
an address, and returning SERVFAIL rather than "no data" when asked for AAAA
records.  

We all know who the offender is, and those of us who use Sendmail already
know why 'WorkAroundBrokenAAAA' exists.  I'll let somebody with more RFC-writing
experience than I decide if package-specific "If you run the XYZ MTA, do THIS
to work around it, if you run the ABC DNS server, upgrade to patch 1.15" info
should be included in an "operational requirements" RFC.  RFC1912 mentions
specific releases of BIND, RFC2010 doesn't.

Although Motonori's English is vastly superior to my Japanese,  I still saw
a few places where phrasing was awkward, or verbs had case/tense issues. I'd
consider them not a show-stopper, but if a volunteer from the audience were
to go through and clean them up, the document would benefit (I'll be happy
to do so if nobody else wants to, but consensus calls for a clean-up - but if
nobody else cares, I'll let it slide).

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: [email-masked]
Date: Mon, 29 Oct 2001 09:48:08 +0900

>be able to use a last-resort relay (which presumably would be a dual-stack

	the document specifically talks about operations in IPv4/v6 dual stack
	environment.  IPv4-only server and IPv6-only client (or vice versa)
	have no way to talk with each other, and therefore, either of the
	following is necessary:
	- make either side a dual-stack node.
	- get help from NAT-PT (RFC2766), tcp-udp-relay (RFC3142), and other
	  translation mechanisms.
	it is generic transition issue and is not specific to SMTP operation,
	therefore it is not mentioned in the document.

>Finally, it appears that I sent some comments already and my name was

	sorry for that.

itojun

---

From: [email-masked]
Date: Mon, 29 Oct 2001 09:49:20 +0900

>specific releases of BIND, RFC2010 doesn't.

	i don't think it necessary/required to list the broken implementation.
	i know of a couple of products that behave badly (which is an IP load
	balancing box product), but i don't think i can cover every broken
	implementations.

itojun

---

From: [email-masked]
Date: Mon, 29 Oct 2001 19:39:45 +0900

>I think we're talking past each other. Let me try again, with a clearer,
>better question:
>
>RFC1893 lists a number of status codes to be used when a message cannot be
>delivered. If the target domain exists, but mail cannot be sent there due
>to protocol mismatch, which RFC1893 code should the SMTP sender use? Or
>should an additional status code be defined?

	hmm now I see what you are talking about.  my guess is 444
	(persistent transient/unable to route), but i'm not 100% sure.

>As I read it, the ngtrans draft is about _trans_ition issues, and the
>possibility of protocol mismatch is definitely a transition issue.

	the advice i would like to make in the draft is to configure MTAs
	so that protocol mismatches are less likely.  i understand we may need
	to document what should happen on protocol mismatches.

itojun

---

From: JJ Behrens <[email-masked]>
Date: Mon, 29 Oct 2001 14:28:48 -0800 (PST)

> nobody else cares, I'll let it slide).

I would be happy to be of assistance.  Motonori, shall I begin?

Cheers,
JJ Behrens

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 29 Oct 2001 11:30:08 +0100

--Arnt

---

From: Eric Allman <[email-masked]>
Date: Mon, 29 Oct 2001 16:27:14 -0800

I think there is some ambiguity in section 3.  In particular, the
numbering seems to combine looping and gotos in a confusing way.
For example, consider the case of doing an A (or AAAA) lookup that
returns multiple IP addresses.  Step (6) says to loop from (7) to
(8) on each address returned, but step (8) says to to back to step
(3).  Which one is it?  This is doubly confusing because step (8)
can never be executed more than once in the innermost loop [(7)-(8)],
so really you are looping on step (7) only -- assuming that the goto
(3) takes precedence over the loop (7)-(8).

Now, _I_ know what they are trying to say, but the language could
be cleaned up -- making this either a loop model or a goto model
should fix it.

Also in section 3, step (5) doesn't say what to do if the resulting
list is empty.  The example at the top of the section lists a host
mx10.example.org that is IPv6 only.  If the source MTA is IPv4 only,
then the lookup of mx10.example.org is going to fail with NO_DATA.
Step (5) should address this.

eric