Subject: [Gen-art] A *new* batch of IETF LC reviews - 2015-03-12

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 12 Mar 2015 17:27:09 -0500

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Joel Halpern      2015-04-02   draft-klensin-smtp-521code-05

Martin Thomson    2015-03-20   draft-ietf-radext-dynamic-discovery-13

Meral Shirazipour 2015-03-23   draft-ietf-roll-applicability-home-building-08

Peter Yee         2015-03-23   draft-ietf-oauth-dyn-reg-management-09

Robert Sparks     2015-04-02   draft-ietf-httpbis-auth-info-04

Suresh Krishnan   2015-03-25   draft-ietf-ospf-security-extension-manual-keying-11 *

* 2nd LC

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Mar 2015 20:05:59 -0400

Document: draft-klensin-smtp-521code-05.txt
     SMTP 521 and 556 Reply Codes
Reviewer: Joel M. Halpern
Review Date: 12-March-2015
IETF LC End Date: 2-April-2015
IESG Telechat date: 9-April-2015

Summary: This document is ready for publication as a Proposed Standard.

Major issues:

Minor issues:
     The description of the 556 reply code in section 4 seems to switch 
between refering to the generating entity as a client and as a sesrver. 
  I presume this is because the actual sitaution is an SMTP server is 
trying to pass information onwards, and in that onwards direction it is 
a client which.  But it is still confusing for an SMTP client to make a 
determination and then an SMTP server which is apparently the same 
entity to generate the rror code to some other SMPT client.

Nits/editorial comments:

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Mar 2015 11:19:36 -0700

> Martin Thomson    2015-03-20   draft-ietf-radext-dynamic-discovery-13

I'll try, but that time frame is a little tight.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 16 Mar 2015 23:06:15 -0400

Joel, thanks for the review.

> between refering to the generating entity as a client and as a sesrver.  I
> presume this is because the actual sitaution is an SMTP server is trying to
> pass information onwards, and in that onwards direction it is a client
> which.  But it is still confusing for an SMTP client to make a determination
> and then an SMTP server which is apparently the same entity to generate the
> rror code to some other SMPT client.

You're right about why, and you're right that it's confusing.  I think
the reader and the text would be better served by changing the first
instance of the word "client" (in the second sentence) to "server".
Even though the server is acting as a client when it makes the
determination that sentence is talking about, it's acting as a server
in the sense that it will be returning a 556 to the client that it's
serving.  Calling it a "client" here only confuses things.

Barry

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Mar 2015 10:21:49 -0400

--On Monday, March 16, 2015 23:06 -0400 Barry Leiba
<[email-masked]> wrote:

>>     The description of the 556 reply code in section 4 seems
>>     to switch between refering to the generating entity as a
>> client and as a sesrver.  I presume this is because the
>> actual sitaution is an SMTP server is trying to pass
>> information onwards, and in that onwards direction it is a
>> client which.  But it is still confusing for an SMTP client
>> to make a determination and then an SMTP server which is
>> apparently the same entity to generate the rror code to some
>> other SMPT client.
> 
> You're right about why, and you're right that it's confusing.
> I think the reader and the text would be better served by
> changing the first instance of the word "client" (in the
> second sentence) to "server". Even though the server is acting
> as a client when it makes the determination that sentence is
> talking about, it's acting as a server in the sense that it
> will be returning a 556 to the client that it's serving.
> Calling it a "client" here only confuses things.

Hi.  While I agree that the existing text is confusing (although
correct), the suggested fix just substitutes one confusing
arrangement for another, with "server" used twice in the same
sentence to refer to two different hosts that serve two
different roles.  See if the following rather more complete
rewrite for that second sentence works better:

	When an intermediate SMTP system (typically a relay)
	that would normally attempt to open a mail connection to
	a host referred to in a forward-pointing address can
	determine that the host does not accept mail
	connections, and do so without attempting to open a
	connection to that target host, it is appropriate for it
	to return a reply with a 556 code to the system that
	sent it the message for outbound transmission.

The eliminates the "client" and "server" terminology entirely
and talks instead about actual functions.  I'm tired and there
are probably better ways to stay that, but I think it is an
improvement over both the existing text and the client -> server
patch.

There is a case that the above doesn't cover, but neither does
the original paragraph, and that is when a submission server
(sic) encounters a nullMX record or equivalent on initial
lookup.  When the submission server tries to do that, it is
acting as an SMTP client, but the status of messages it returns
to the submitting MUA is deliberately very flexible in the spec
(see Section 3.2 of RFC 6409).

     john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Mar 2015 10:25:59 -0400

That wording works for me.
Yours,
Joel

---

From: Barry Leiba <[email-masked]>
Date: Tue, 17 Mar 2015 10:53:55 -0400

> That wording works for me.

Yeh.

b

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Mar 2015 11:27:02 -0400

>> That wording works for me.

Incorporated in working draft for -06.  Up to you when I post
that version but my usual preference is between the end of the
LC and the IESG review/vote.

    john