Re: Review Requested: SMTP IPv6 operational experience document

[Pekka Savola <pekkas@netcore.fi>]

Nice to see that Dean made an indepth review of the draft.

Here's my review as an individual WG member.

On Mon, 19 Jan 2004, Pekka Savola wrote:
>    draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt
> 
> Please send comments, preferably in a week, by 26th January, either to
> the v6ops list (preferable), or directly to itojun (acting as the
> editor) and the chairs.

First, I have to say that the beginning of the document (up to section
3 or so), is in an AWFUL English shape.  Please review those in
detail, even though I mention many of the editorial problems.  

I assume that this draft is going for Informational (and not e.g.  
BCP).

bigger issues
-------------

IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4
translators such as [Hagino, 2001] , however, there are no special SMTP
considerations for translators needed; If there is SMTP traffic from an
IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA
will consider this as a normal IPv4 SMTP traffic.  Protocols like IDENT
[St.Johns, 1993] as well as SMTP HELO/EHLO may require special
consideration when translators are used.

==> the latter, esp. SMTP EHLO/HELO is pretty important part of the
scope of this document (aren't we interested of SMTP?), so it should
probably elaborated a bit more.

...

There are several technologies defined for the transition from IPv4 to
IPv6.  This document concentrates on SMTP issues in a dual-stack
environment, e.g. delivery of emails from IPv6-only MTA to IPv4-only MTA
is outside of the scope of the document.

IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4
translators such as [Hagino, 2001] , however, there are no special SMTP
considerations for translators needed; If there is SMTP traffic from an
IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA
will consider this as a normal IPv4 SMTP traffic.  Protocols like IDENT
[St.Johns, 1993] as well as SMTP HELO/EHLO may require special
consideration when translators are used.

The following sections explain how to make IPv4 SMTP and IPv6 SMTP
coexist in a dual-stack environment.

This document does not discuss the problems encountered when the sending
MTA and the receiving MTA have no common protocol (e.g. the sending MTA
is IPv4-only while the receiving MTA is IPv6-only).  Such a situation
should be resolved by making either side dual-stack or by making either
side use a protocol translator.

==> 1, 2 and 4th paragraph seem to be slightly at odds with each another, 
and the third seems out of place.  One should unify the text a bit, e.g.,
officially include discussion of the translators (etc.) or put them in an 
Appendix and refer to that in the introduction.


     example.org.            IN MX   1  mx1.example.org.
                             IN MX   10 mx10.example.org.
     mx1.example.org.        IN AAAA 3ffe:501:ffff::1
     mx10.example.org.       IN AAAA 3ffe:501:ffff::2


==> the IPv6 examples should use something more closely resemling a 
"documentation prefix", at this time, the closest would probably be
2001:db8::/32.


4.  MX configuration in the recipient domain

4.1.  Ensuring reachability for both protocol versions

If a site has dual-stack reachability, the site SHOULD configure both A
and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the
site).  This will help both IPv4 and IPv6 senders to reach the site
efficiently.

==> you use uppercase keyword, but don't define them.  However, for an
operational document (and not a protocol specification, with
interoperability requirements) like this, it would be better to not
use them at all, i.e., s/SHOULD/should/ or the like.

7.  Security considerations

It could be problematic if the route-addr email address format is used
across multiple scope zones.  MTA's would need to reject email with
improper route-addr email address formats.

==> this is the first time you mention "route-addr".  You should provide a 
bit more background to this issue.

References

==> these have to be split to informative and normative.  Also note that an RFC 
obsoleting RFC1886 has been published.


==> this draft should also include the IPR and the copyrights sections at the end.




editorial issues
----------------

==> it would be nice if the text in the sections was indented a couple 
of spaces, for readibility, but this is OK as is too.


      SMTP operational experience in mixed IPv4/IPv6 environements

==> uppercase, s/ements/ments/

This document talks about SMTP operational experiences in IPv4/v6 dual

==> might be worth spelling out SMTP, even though everybody probably knows it..


Deliveries of mail messages to the final mail drop is not always done by

==> s/Deliveries/Delivery/ ?

direct IP communication with submiter and final receiver, and there may

==> s/submiter/submitter/, add "the" times ?

It is not so easy to configure all
the system with consistency since mail message delivery system is rather

==> s/system/systems/, maybe s/with consistency/consistently/ ?

complex on DNS setting than other Internet services.  For the transition

==> s/setting/settings/

For the transition
state from IPv4 to IPv6, both IPv4 and IPv6 interoperability should be
kept more carefully.

==> the latter part of the sentence "kept more carefully" is barely 
english, please reword? :-)

Mail messages on the Internet are delivered based on domain name system
generally. 

==> s/delivered ... generally/typically delivered .../ ?

with domain part of a mail addresse.

==> s/addresse/address/

Similar to the way RFC's for IPv6
DNS lookup [Thomson, 1995] use IN class for both IPv4 and IPv6, IN MX
records will be used for both IPv4 and IPv6 on mail message routing,
hosts which have IPv6 transport and want to be delivered with the IPv6
transport must define IPv6 IP addresses for the host name as well as
IPv4 IP addresses.

==> want *what* to be _delivered with_?  Bad english, please reword, e.g.:

DNS lookup [Thomson, 1995] uses IN class for both IPv4 and IPv6 and 
similarly IN MX records will be used for mail routing for both IPv4 
and IPv6.  Hosts which have IPv6 connectivity and want to have the
mails delivered also using IPv6 must define IPv6 addresses for 
the host name as well as IPv4 addresses.


A MX RR have two data, a preference value and the name of destination
host.

==> s/have two data/has two arguments/ ?

IP addresses for the destination host are also looked up to make
SMTP transport [Partridge, 1986] .

==> s/ ././, s/make SMTP transport/initiate SMTP connection/ ?


In the following sections, how sender side operates with IPv4/IPv6
combined RR definitions (section 3), and how receiver side should define
RRs to keep interoperability with both IPv4 and IPv6 Internet (section
4) are considerd.

==> Start like "In the following section we consider how ..." 


     NOTE: IPv6 addresses for hosts defined by MX records may be
     informed in additional information section of DNS querie's result

==> s/querie's/query's/ or s/querie's/queries'/

    reachable and if a list of MX records is being traversed, try the
     next MX record (go to step (3)).  If there is no list of MX

==> s/))/)/

       condision reported, try the next MX record (go to step (3)).  If an

==> s/condision/condition/

6.  Open issues

o The document should really be integrated into RFC2821 [Klensin, 2001]
  (i.e. RFC2821 should talk about IPv6 cases).


==> I'd reword this a bit, like:

o A future specification of SMTP should be updated to include the 
  information in this memo.


Change history

==> Here you could add something like:

  [[ RFC-Editor: please remove before publication ]]

Author's address

==> replace with Authors' Addresses

2.  Basic DNS resource record definitions for mail routing
3.  SMTP sender algorithm in a dual-stack environment
4.  MX configuration in the recipient domain
4.1.  Ensuring reachability for both protocol versions
4.2.  Reachability between the primary and secondary MX
5.  Operational experience
6.  Open issues

==> The section titles and the document title should be 
"first-character uppercased", like:

2.  Basic DNS Resource Record Definitions for Mail Routing
3.  SMTP Sender Algorithm in a Dual-stack Environment
4.  MX Configuration in the Recipient Domain
4.1.  Ensuring Reachability for Both Protocol Versions
4.2.  Reachability Between the Primary and Secondary MX
5.  Operational Experience
6.  Open Issues

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings