Scott Brim | 27 Jul 20:29 2014
Picon

gen-art review of draft-ietf-karp-bfd-analysis-04

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: draft-ietf-karp-bfd-analysis-04
Reviewer: Scott Brim
Review Date: 2014-07-27
IETF LC End Date: 2014-08-12
IESG Telechat date: not known

Summary: Ready with nits

Nits/editorial comments:

  - Run idnits, there are a couple things to tweak. Otherwise it's a clear draft.

Scott

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Brian E Carpenter | 26 Jul 17:00 2014
Picon

Gen-ART LC review of draft-ietf-tram-auth-problems-02

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: draft-ietf-tram-auth-problems-02.txt
Reviewer: Brian Carpenter
Review Date: 2014-07-26
IETF LC End Date: 2014-08-08
IESG Telechat date:

Summary:  Almost ready
--------

Minor issues:
-------------

In Problem 2, would it be useful to reference RFC 6151, which indicates why
MD5 is problematic?

Problem 6 (Hosting multiple realms on a single IP address is challenging...)
doesn't really seem to be a problem with authentication as such, so while
it's clearly a problem, is it in scope? It isn't quite clear to me that
there's a security threat there.
Black, David | 25 Jul 16:45 2014

Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-06

The -06 version of this draft addresses the topics raised in the Gen-ART
review of the -05 version, except that Section 1 is still missing from
the Table of Contents (possible xml2rfc problem?).

Summary: Ready with nits. 

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Thursday, July 17, 2014 12:39 AM
> To: standards <at> taugh.com; mx0dot <at> yahoo.com; General Area Review Team (gen-
> art <at> ietf.org); ops-dir <at> ietf.org
> Cc: apps-discuss <at> ietf.org; ietf <at> ietf.org; Black, David
> Subject: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-05
> 
> This is a combined Gen-ART and OPS-DIR review.
> Boilerplate for both follows ...
> 
> 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.
> 
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments
> were written primarily for the benefit of the operational area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> Document: draft-ietf-appsawg-nullmx-05
> Reviewer: David L. Black
> Review Date: July 16, 2014
> IETF LC End Date: July 17, 2014
> IESG Telechat Date: August 7, 2014
> 
> Summary: This draft is on the right track, but has open issues
> 		described in the review.
> 
> This draft is a short specification of a NULL MX resource record whose
> publication in the DNS indicates that a domain does not accept email.
> 
> I found one relatively minor issue.
> 
> Minor Issues:
> 
> Something is wrong with this paragraph in the Security Considerations section:
> 
>    In the unlikely event that a domain legitimately sends email but does
>    not want to receive email, SMTP servers that reject mail from domains
>    that advertise a NULL MX risk losing email from those domains.  The
>    normal way to send mail for which a sender wants no responses remains
>    unchanged, by using an empty RFC5321.MailFrom address.
> 
> Why is that treated as a security consideration?  In light of the first
> paragraph in Section 4.3 stating that it's acceptable for SMTP clients to
> not send email to domains that publish NULL MX records, this text ought to
> be recommending that such a domain (legitimately sends email but does not
> want to receive email) SHOULD NOT publish a NULL MX record and SHOULD provide
> an SMTP server that promptly rejects all email delivery attempt.  It can
> then further explain that not following the "SHOULD NOT" causes lost email
> as described in the quoted text, and not following the "SHOULD" causes long
> delivery timeouts as described in Section 2.  I'd also suggest moving this
> discussion to Section 4.3 so that it follows the first paragraph there.
> 
> Nits:
> 
> Section 1 is missing from Table of Contents.
> 
> First paragraph in Section 4.1:
> 	"address is not deliverable" -> "the email is not deliverable"
> 
> Second  paragraph in Section 4.1 assumes that all or most domains that
> do not accept email also publish NULL MX records.  That assumption should
> be stated as part of the first sentence of the paragraph, as the immediately
> preceding paragraph is about the benefits of individual domains publishing
> NULL MX records.
> 
> In Section 4.3, please provide text descriptions of the 550 reply code and
> 5.1.2 enhanced status code.
> 
> OLD
>    550 reply code
> NEW
>    550 reply code (Requested action not taken: mailbox unavailable) [RFC5321]
> 
> OLD
>    5.1.2 enhanced status code
> NEW
>    5.1.2 enhanced status code (Permanent Failure, Bad destination system
> address)
> 
> idnits 2.13.01 didn't find anything to complain about.
> 
> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
> 
> A.1.1  Has deployment been discussed?
> 
> 	Yes, and NULL MX records are already deployed in the DNS.
> 
> A.1.5.  Has the impact on network operation been discussed?
> 
> 	Yes, in general, NULL MX records have significant operational
> 	benefits as described in the draft.
> 
> A.2.  Do you anticipate any manageability issues with the specification?
> 
> 	No.  This is a minor extension to an existing use of DNS resource
> records.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black <at> emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
Elwyn Davies | 25 Jul 03:13 2014
Picon

Gen-art Post-Telechat review of draft-ietf-mmusic-latching-08

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>.

For the sake of completeness - post-telechat check of updates.

Document: draft-ietf-mmusic-latching-05.txt
Reviewer: Elwyn Davies
Review Date: 25 July 2014
IETF LC End Date: 28 May 2014
IESG Telechat date: 29 May 2014

Summary: Ready (Checked the updates from -05 and are now OK). Thanks
A. Jean Mahoney | 24 Jul 23:30 2014

A *new* batch of IETF LC reviews - 2014-07-24

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

Alexey Melnikov   2014-08-09   draft-ietf-l3vpn-pmsi-registry-03

Ben Campbell      2014-08-09   draft-ietf-forces-model-extension-03

Brian Carpenter   2014-08-08   draft-ietf-tram-auth-problems-02

Elwyn Davies      2014-08-07   draft-ietf-savi-dhcp-29 *

Tom Taylor        2014-07-29   draft-ietf-dnsop-rfc6304bis-03

* 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:
Jari Arkko | 24 Jul 21:32 2014
Picon

noticing gen-art reviews

I was on the Gen-ART breakfast, and we observed how well the Gen-ART system works. In a huge majority of cases
the authors and reviewer work out the comments and possible changes well in advance of the telechat, and
the result is overall better quality of the RFCs. That’s great and thanks to everyone who is doing this so well.

We also made the observation that occasionally (p = 0.05 or so) we have reviews where the first person to ask
if there’s a response to the review is the reviewer or AD who asked for the review. I just wanted to
highlight that we all (from authors up the chain) need to be vigilant in ensuring that reviews get
responded to. I don’t mind asking about that, but hopefully the authors, shepherds, and ultimately
sponsoring ADs track the questions that their document receives. Because they are the best persons to
track feedback on their document. Please continue to keep your shepherds and authors aware that they need
to do this.

Jari

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Tom Taylor | 24 Jul 16:19 2014
Picon

Last Call review of draft-ietf-dnsop-rfc6304bis-03

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>.

Document: draft-ietf-dnsop-rfc6304bis-03
Reviewer: Tom Taylor
Review Date: 24 July 2014
IETF LC End Date: 29 July 22014
IESG Telechat date: (if known)

Summary: This is one of the best-written IETF documents I have ever 
read. I have identified no issues, but have only a surface understanding 
of DNS. Hence I cannot pronounce on the technical accuracy of the 
document beyond saying that it is consistent with
draft-ietf-dnsop-as112-dname-04.

Major issues: none.

Minor issues: none.

Nits/editorial comments: none.
Meral Shirazipour | 23 Jul 18:06 2014
Picon

Gen-ART Last Call review draft-ietf-tcpm-fastopen-09

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: draft-ietf-tcpm-fastopen-09

Reviewer: Meral Shirazipour

Review Date: 2014-07-23

IETF LC End Date:   2014-07-23

IESG Telechat date: NA

 

 

Summary:

This draft is ready to be published as Experimental RFC, but I have some comments.

 

Nits/editorial comments:

-Abstract says "thus saving up to one full round trip time (RTT)": by just reading the abstract one would think 1.5 RTT since initial 3WHS is avoided.

Reading the rest of the draft clarifies this though. Suggestion :

 

"

TFO allows data to be carried in the SYN and SYN-ACK packets

   and consumed by the receiving end during 'an' initial connection

   handshake, 'and' saves up to one full round trip time (RTT) compared

   to the standard TCP, ......

"

 

-[page 4] "MSL", to spell out at first use "maximum segment lifetime" (or please consider mentioning reference to key TCP RFCs in Terminology section).

 

-General: Also few other acronyms used without spelling out at first use, please consider those as well.

 

-[Page 7], 'Fast Open Cookie Option', it would be more familiar to IETF community to call "Kind" field "Type", unless there was a reason for this differentiation.

-[Page 10] please remove extra space (page break) if not needed.

 

-[Page 12], typo "connection-sharding"--->"connection-sharing"

 

-[page 14] "as a application"--->"as an application"

 

-[Page 17], typo "Neverthless"--->"Nevertheless"

 

-[Page 18], typo "meet the the"---->"meet the"

 

-[Page 21], typo "in Section Section 4.1.1"---->"in Section 4.1.1"

 

-[Page 21] please remove extra space (page break) if not needed.

 

Best Regards,

Meral

 

 

---

Meral Shirazipour

Ericsson

Research

www.ericsson.com

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Francis Dupont | 20 Jul 21:53 2014
Picon

review of draft-ietf-appsawg-multimailbox-search-01.txt

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: draft-ietf-appsawg-multimailbox-search-01.txt
Reviewer: Francis Dupont
Review Date: 20140717
IETF LC End Date: 20140721
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 first a meta-question: should this kind of documents refer to its
 parent, RFC 6237 (same subject but RFC 6237 is Experimental, the
 I-D is for Standards Track)? IMHO it should not (so the I-D is
 right) because this will be (only) mentioned in the RFC index.

 - ToC page 2 and 9 page 11: Acknowledgements -> Acknowledgments

Regards

Francis.Dupont <at> fdupont.fr
A. Jean Mahoney | 17 Jul 21:57 2014

A *new* batch of IETF LC reviews - 2014-07-17

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

David Black       2014-07-30   draft-ietf-ipfix-text-adt-07 *

Peter Yee         2014-08-01   draft-ietf-appsawg-email-auth-codes-04

Robert Sparks     2014-07-25   draft-ietf-isis-tlv-codepoints-00

Roni Even         2014-07-29   draft-ietf-dnsop-as112-dname-04

Russ Housley      2014-07-29   draft-ietf-dnsop-rfc6304bis-03

Scott Brim        2014-08-12   draft-ietf-karp-bfd-analysis-04

Suresh Krishnan   2014-08-07   draft-ietf-l2vpn-ipls-14

* 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:
Black, David | 17 Jul 06:38 2014

Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-05

This is a combined Gen-ART and OPS-DIR review.
Boilerplate for both follows ...

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.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments 
were written primarily for the benefit of the operational area directors.  
Document editors and WG chairs should treat these comments just like any other 
last call comments.

Document: draft-ietf-appsawg-nullmx-05
Reviewer: David L. Black
Review Date: July 16, 2014
IETF LC End Date: July 17, 2014
IESG Telechat Date: August 7, 2014

Summary: This draft is on the right track, but has open issues
		described in the review.

This draft is a short specification of a NULL MX resource record whose
publication in the DNS indicates that a domain does not accept email.

I found one relatively minor issue.

Minor Issues:

Something is wrong with this paragraph in the Security Considerations section:

   In the unlikely event that a domain legitimately sends email but does
   not want to receive email, SMTP servers that reject mail from domains
   that advertise a NULL MX risk losing email from those domains.  The
   normal way to send mail for which a sender wants no responses remains
   unchanged, by using an empty RFC5321.MailFrom address.

Why is that treated as a security consideration?  In light of the first
paragraph in Section 4.3 stating that it's acceptable for SMTP clients to
not send email to domains that publish NULL MX records, this text ought to
be recommending that such a domain (legitimately sends email but does not
want to receive email) SHOULD NOT publish a NULL MX record and SHOULD provide
an SMTP server that promptly rejects all email delivery attempt.  It can
then further explain that not following the "SHOULD NOT" causes lost email
as described in the quoted text, and not following the "SHOULD" causes long
delivery timeouts as described in Section 2.  I'd also suggest moving this
discussion to Section 4.3 so that it follows the first paragraph there.

Nits:

Section 1 is missing from Table of Contents.

First paragraph in Section 4.1:
	"address is not deliverable" -> "the email is not deliverable"

Second  paragraph in Section 4.1 assumes that all or most domains that
do not accept email also publish NULL MX records.  That assumption should
be stated as part of the first sentence of the paragraph, as the immediately
preceding paragraph is about the benefits of individual domains publishing
NULL MX records.

In Section 4.3, please provide text descriptions of the 550 reply code and
5.1.2 enhanced status code.

OLD 
   550 reply code
NEW
   550 reply code (Requested action not taken: mailbox unavailable) [RFC5321]

OLD
   5.1.2 enhanced status code
NEW
   5.1.2 enhanced status code (Permanent Failure, Bad destination system address)

idnits 2.13.01 didn't find anything to complain about.

--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---

A.1.1  Has deployment been discussed?

	Yes, and NULL MX records are already deployed in the DNS.

A.1.5.  Has the impact on network operation been discussed?

	Yes, in general, NULL MX records have significant operational
	benefits as described in the draft.

A.2.  Do you anticipate any manageability issues with the specification?

	No.  This is a minor extension to an existing use of DNS resource records.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

Gmane