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
(Continue reading)

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,

(Continue reading)

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
----------------------------------------------------
Ben Campbell | 15 Jul 00:40 2014

Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06

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-l2vpn-etree-frwk-06
Reviewer: Ben Campbell
Review Date: 2014-07-14
IETF LC End Date: 2014-07-15

Summary: This draft is almost ready for publication as an RFC, but I have a few minor issues and editorial
comments that may be worth consideration prior to publication.

Major issues:

None

Minor issues:

-- I suggest removing the 2119 language. Ignoring the general controversies over whether informational
RFCs should use 2119 language, I don't think it fits for _this_ draft. In particular, all the small number
of normative language instances seems to be either statements of fact or restatements of requirements
that are defined elsewhere. These would all be better served with descriptive language. 

-- Section 4, paragraph after Table 1: "If direct Layer 2 Leaf-to-Leaf communication needs to be
prohibited, E-Tree should be used."

That sounds more like advocacy than architecture/framework. Do you mean to suggest that other potential
solutions (if any) should not be used, or that E-Tree is somehow the best solution?  Or did you mean to say
"E-Trees are appropriate for whenever..."?

-- Similarly, 2 paragraphs down: "An E-Tree service can meet these use case requirements."

That also sounds like advocacy. This draft doesn't seem to do a requirements analysis for those use cases,
beyond an assumption that they need inter-leaf isolation at Layer 2. Something to the effect of "E-Trees
can meet the common requirement to avoid the exchange of frames between Leaf CAs." would be more appropriate.

-- 5.1 and 5.2:

5.2 seems like the same "gap" as discussed in 5.1, just from a perspective of CA role vs forwarding
constraint. Handing around constraints vs roles seem more like solution questions than requirements or
architecture questions.

-- 5.3, First sentence:

The first sentence seems like yet a further restatement of the issue from 5.1 and 5.2.  (The rest of the
section seems reasonably distinct from the others.)

-- Security Considerations:

The security considerations mostly say that e-trees have to act like e-trees. I think there is room for more
discussion. Are the e-tree rules sufficient for scenarios where inter-leaf isolation is critical for
security reasons? Does it remove needs for higher layer protections? (I hope not.) The guidance to use
IPSec if additional security is required is not entirely satisfying here--how would an higher layer
protocol know whether or not it had a fully protected path?

Are there trust issues between PEs? Can one PE assume that another will enforce the leave/root
constraints? Can it trust that the other PE has the same idea of what should be a leaf vs root? Is there a need
for one PE to determine if another supports E-Trees at all?

Nits/editorial comments:

-- 2.2, 4th paragraph: "Furthermore, MEF also defines AC roles. One
   role is Root and another is Leaf."

Are these the same usages as defined in this document? If so, it might be helpful to attribute these in the
terminology section.

-- 2.3, 2nd paragraph: "... distinct differentiation for multicast groups in one VPN."

I suggest "... distinct differentiation among multicast groups in the same VPN."

-- 3: Figure 1

The figure is two pages from the paragraph that describes it. I suggest moving Figure 1 to either before or
after the first paragraph in the section.

-- 3, first paragraph "This implies that an Ethernet frame from CE01, CE02, etc will be treated as a frame
originated from a Root AC; a frame
   from CE03, CE04, etc will be treated as a frame originated from a Leaf AC."

Treated by what? (Consider restating in active voice).

-- 3, last paragraph before Figure 1: " A VSI on a PE corresponds to an E-Tree instance ..."

This can be read to imply a 1-to-1 cardinality between "A VSI on a PE" and "an E-Tree instance". I don't think
that is intended.

Also, is an "E-Tree instance" the same thing as and "E-Tree service instance", as mentioned elsewhere?

-- Section 4, paragraph after Table 1:

Can you provide a reference and/or expansion for LTE X2?  (I think LTE may be on the well-known abbreviation
list, but I'm not sure about X2).

-- Section 4, last paragraph:

Unless you mean to say that broadcast video is a significant driver for this work, this paragraph seems off topic.

-- Section 5 and subsections

Section 5  needs additional proof reading for missing articles and singular/plural mismatches.

-- Normative References:

The two IEEE references seem more like informative rather than normative ones.
Martin Thomson | 11 Jul 02:16 2014
Picon

Gen-ART review of draft-dukhovni-opportunistic-security-01

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-dukhovni-opportunistic-security-01
Reviewer: Martin Thomson
Review Date: 2014-07-08
IETF LC End Date: 2014-08-05
IESG Telechat date: (if known)

Summary: This reads a little like it was rushed.  This needs some work
before it can be considered ready.

(I've cc'd saag here.  That seemed appropriate, strip as you see fit.)

Major issues:

This misses one of the key principles behind opportunistic security:

  Insistence on failure, as opposed to downgrade or some lesser level
of security - a characteristic of non-opportunistic security - elicits
responses from users to work around the problem (accept the bad
certificate, suppress certificate checking, etc...).  The willingness
of an opportunistic security implementation to accept unvalidated
credentials means that it still benefits from resilience against
passive attack.  This is only really noted through an example of a
"design blunder".

In general, a more careful consideration of the document structure is needed.

The document skirts around it's key goal: defining OS.  Section 2
needs to start with a definition. The paragraph that follows the list
in S2 is a reasonable attempt at that and could be tweaked fairly
perform that function.

The Security Considerations is a response to an unstated argument, but
I think that the document needs to be clearer about what that argument
is, i.e.:

  The willingness of an OS implementation to downgrade can be
trivially exploited by an active attacker to strip an opportunistic
mechanisms.

The point that is made here is one that is most applicable in the
aggregate, something that is implied by "users" (in the plural form),
but should be explicit.

Minor issues:

Section 3 is unnecessary in its entirely:

  1. 2119 language isn't really appropriate for this document.  Many
of the statements that rely on this would be much better without that
language.  Some of the uses are actually completely inappropriate:
"When possible, opportunistic security SHOULD provide stronger
security on a peer-by-peer basis."

  2. I think that the description of "unauthenticated encryption" and
"TOFU" belong in the text proper.  TOFU is covered well enough by the
text in S1; unauthenticated encryption needs to be covered in the
description as a first class section, rather than piecemeal (see
above).  MitM and PFS are defined in RFC4949.

Nits/editorial comments:

References are double-bracketed "([ref])" and the "pervasive
monitoring (PM[RFC7258])" reference doesn't need the "PM".

Gmane