[Gen-art] A *new* batch of IETF LC reviews - 2016-09-01

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC end  Draft
-
Dan Romascanu 2016-09-13  draft-ietf-mptcp-experience-06


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 updated template is included below.

Thanks,

Jean

---

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

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

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-mpls-entropy-lsp-ping-04

[Carlos Pignataro (cpignata)]

Dear Peter,

Many thanks for taking the time to go through the document with an editorial 
fine-tooth comb.

Although your summary, labeled [Ready with nits], says:
> I really have no problems with the documents other than some mostly
> inconsequential nits.

I took the time to fix every single one of the small nits you identified. 
That’s the least we could do, out of respect of you taking the time and helping 
the document improve.

Our working copy incorporates fixes to all these nits. Thank you.

I must share with you that the real value of your thorough review is in the 
Major and Minor categories, and that General-Area technical review — not in the 
editorial nit identification. It was excruciatingly hard to identify some of 
these nits, given that you use “Page x, Section y.z, n-th bullet point, m-th 
sentence” locators, which are not present in the (submitted) XML source. I 
expect the RFC Editor might find a couple more, as part of the copy edit, at 
that final stage before publication when it makes more sense.

Thanks again,

— Carlos.



> On Aug 29, 2016, at 11:26 PM, Peter Yee  wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.  For background on Gen-ART,
> please see the FAQ at
> 
> 
> Document: draft-ietf-mpls-entropy-lsp-ping-04
> Reviewer: Peter Yee
> Review Date: August 26, 2016
> IETF LC End Date: August 26, 2016
> IESG Telechat date: September 1, 2016
> 
> Summary: This draft is basically ready for publication as a Proposed
> Standard, but has some nits that should be fixed before publication. [Ready
> with nits]
> 
> This draft expands the ability to perform MPLS LSP Ping and Traceroute
> operations in the presence of Entropy Labels when LSRs use disparate load
> balancing methods.
> 
> I really have no problems with the documents other than some mostly
> inconsequential nits.
> 
> The items below are the same as given in the LC review.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits:
> 
> General:
> 
> Page 3, Section 1.1: delete the periods after each definition.
> 
> Change "ELI/EL pushing" to "ELI/EL-pushing".
> 
> Specific:
> 
> Page 1, Abstract, 1st paragraph, 3rd sentence: expand LSRs here as this is
> the first use of the term.  Put LSRs in parenthesis.
> 
> Page 1, Abstract, 1st paragraph, 4th and 5th sentences: change "non-EL
> based" to "non-EL-based".
> 
> Page 3, FEC definition: change "Equivalent" to "Equivalence".
> 
> Page 4, Section 1.2 , 2nd paragraph, last sentence: append a comma after
> "e.g.".
> 
> Page 4, Section 1.2, 3rd paragraph, second sentence: change "to not be"  to
> "not being".
> 
> Page 4, Section 1.2, 1st bullet point, 1st sentence: insert "the" before
> "label".
> 
> Page 5, Section 2, 2nd paragraph, 2nd sentence: append a comma after "y".
> 
> Page 5, Section 2, 3rd paragraph, 5th sentence: change "(outgoing
> interface)" to "(outgoing) interface".
> 
> Page 6, 1st sentence: insert "The" before "Current" after making it lower
> case.  Insert "the" before "following".
> 
> Page 6, 3rd bullet point, 1st sentence: delete the comma after "ECMP".
> 
> Page 6, 4th bullet item, 1st sentence: delete the comma after "ECMP".
> Insert "the" before "associated".
> 
> Page 6, 3rd asterisk bullet item: change "based on EL" to "based on the EL".
> 
> Page 6, 4th asterisk bullet item: insert "an" before "ELI".
> 
> Page 7, Section 3, 1st paragraph, 1st sentence: change the space between
> "label" and "based" to a hyphen.
> 
> Page 7, Section 4, 2nd paragraph, 1st sentence: change "PW-FEC" to "PW FEC".
> 
> Page 9, Section 6, 1st paragraph, 2nd sentence: append a comma after "one".
> 
> Page 9, L flag definition, 2nd sentence: insert "to one" before "in the echo
> reply".  Or consider working with the definition of "set" to mean "using a
> value of one" and "clear" to mean using a value of "zero" as you have done
> in other parts of the document.
> 
> Page 9, E flag definition, 2nd sentence: insert "to one" before "in the echo
> reply".
> 
> Page 11, Associated Label Multipath Information definition, 1st asterisk
> bullet item: change "16 bit" to "16-bit".
> 
> Page 12, 1st and 2nd asterisk bullet points: there is no previous mention of
> an "IP Associated Label Multipath Information".  You probably want to drop
> "IP" to match Figure 2.  Whatever you decide, make the change consistently
> throughout the document as there are other instances of "IP Associated Label
> Multipath Information", some in mixed case.  This is the only nit of real
> consequence.
> 
> Page 12, 3rd bullet item: insert "an" before "echo".  Insert "the" before
> "DS".
> 
> Page 13, Section 9, 1st paragraph after numbered items, 1st sentence: change
> "to not" to "not to".  (That 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-hip-multihoming-10

[Gonzalo Camarillo]

Hi Tom,

I did not get your email. Nevertheless, if the next steps are clear to
everyone, all is good.

Cheers,

Gonzalo

On 31/08/2016 3:49 PM, Tom Henderson wrote:
> On 08/31/2016 12:41 AM, Gonzalo Camarillo wrote:
>> Hi Tom,
>>
>> could you please address Meral's review below?
> 
> Gonzalo, I replied on this yesterday (summary:  most suggested changes
> will be in the next update).  Please let me know if the email failed to
> be delivered.
> 
> - Tom

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-tram-turn-server-discovery-08

[Ralph Droms]

RI just completed a quick review of draft-ietf-tram-turn-server-discovery-08.  
The DNS Service Discovery section is much improved.  I have a couple of 
comments on the revised text:

I suggest adding a reference to the IANa "Service Name and Transport Protocol 
Port Number Registry", 
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=Turn,
 as the source of the service  names "turn" and "turns".

While the example DNS records for "exampleco TURN Server" are technically 
correct, they would most likely be generated by the DNS-SD/mDNS library in a 
server, rather than appearing in a DNS server zone file somewhere.  For 
clarity, it might be better to use the unicast DNS versions of the DNS-SD 
records by substituting "example.com" for "local".

In my opinion, the details in section 5.1 are redundant with and (possibly) not 
identical to the specification in RFC 6762 and RFC 6763.  Specifically, Figure 
1 includes a typo; there should be separate A/ query and reply messages.  
More generally, DNS-SD/mDNS servers may return the SRV, TXT, A and  records 
in the first reply, as an optimization.  I think it would be better, in this 
document, to specify simply that TURN servers and clients use the message 
exchanges specified in those RFCs for TURN server discovery.  

- Ralph

> On Sep 1, 2016, at 4:05 AM, Jari Arkko  wrote:
> 
> Ralph, Tiru — thanks for the updates and the review. I’ve looked at the 
> change draft and I think it is fine now.
> 
> Jari
> 
> 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART telechat review of draft-hardy-pdf-mime-02

[Jari Arkko]

Many thanks for the review, Dan.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Review of draft-seantek-ldap-pkcs9-06

[Jari Arkko]

thanks for the review!

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Telechat Review of draft-ietf-httpauth-extension-08

[Jari Arkko]

Matt: Many thanks for your detailed review. Much appreciated.

Authors, can you take these notes into account?

Jari

On 01 Sep 2016, at 05:15, Matt Miller  wrote:

> * There is at least a couple of mentions of the
> "Authentication-Info" header, but no reference to RFC 7615 in which
> it is defined.  I think an informational reference is warranted
> here.
> 
> * Just reading sections 4.5. "Location-when-logout parameter" and
> 4.6. "Logout-timeout parameter", it is unclear how these are meant
> to interact to inform a client the user's authentication session.
> Frankly, I think the text in section 4.5 is too vague about how
> a client can detect termination of a user's authenticated session,
> and could use more of a hint on how "logout-timeout" is involved
> to accomplish it. At the least, I think both sections 4.5. and
> 4.6. need pointers to section 5. to help readers get a
> sense of how to apply them.
> 
> * In section 4.7. "Username parameter", I think there should be
> an explicit pointer to the Security Considerations to warn about
> potential issues this parameter presents.  I also recommend
> separating that portion of the Security Considerations about
> "username" into its own subsection to make such a callout
> better.
> 
> * Since this document is acknowledging that cookies are used for
> authentication, and
> 
> Nits/editorial comments:
> 
> * In section 2.1. "Terms for describing authentication protocol
> flow", the word "distinguishable" should instead be "distinguished"
> in the phrase "it can't be distinguishable from a non-authenticated
> response."
> 
> * In section 3. "Optional Authentication", the word "be" is missing
> in "Optional-WWW-Authenticate header MUST NOT sent on 401
> responses".
> 
> * In section 3.1. "Note on Optional-WWW-Authenticate and use of
> WWW-Authenticate header with non-401 status", the word "is" should
> be replaced with "are" in the phrase "clients which is unaware of
> this extension will ignore the header".
> 
> * Also in section 3.1., the word "authentications" should be
> "authentication" in the phrase "secondary fallback method of
> authentications".
> 
> * Also in section 3.1., the word "ignores" should be "ignore" in
> the phrase "just ignores the WWW-Authenticate headers".
> 
> * Also in section 3.1., all instances of the word "implementer"
> should be replaced with "implementers" in the phrase "the authors
> propose implementer of the standard HTTP/1.1 specification
> (especially implementer of this extension)".
> 
> * In section 4. "Authentication-Control header", the word "an"
> should be "a" in the phrase "and MUST be sent in an plain".
> 
> * In section 4.1. "Non-ASCII extended header parameters", the
> interoperability note as a number of grammatical challenges.
> I believe the following addresses the grammar issues while
> retaining its meaning:
> 
>"""
>Interoperability note: [RFC7235], Section 2.2, defines the "realm"
>authentication parameter which cannot be replaced by the "realm*"
>extend parameter.  It means that the use of non-ASCII values for an
>authentication realm is not the defined behavior in HTTP.
>Unfortunately, some people currently use a non-ASCII realm parameter
>in reality, but even its encoding scheme is not well-defined.
>Given this background, this document does not specify how to handle
>a non-ASCII "realm" parameter in the extended header fields.  If
>needed, the authors propose to use a non-extended "realm" parameter
>form, with a wish for maximum interoperability.
>"""
> 
> * In section 4.2. "Auth-style parameter", the word "preferences"
> should be replaced with "preference" in the phrase "server's
> preferences for user interface behavior".
> 
> * In section .4.4. "No-auth parameter", the word "authentications"
> should be replaced with "authentication" in the phrase "content is
> desired before authentications".
> 
> * In section 4.6. "Logout-timeout parameter", the word "from" should
> be removed in the phrase "has passed since from the time this header
> was received".
> 
> * In section 5.3. "When to use Cookies", the first sentence has some
> grammatical challenges, which I believe the following text addresses:
> 
>"""
>In current Web sites using form-based authentication, Cookies
>[RFC6265] are used for managing both authorization and
>application sessions.
>"""
> 
> * In section 5.4. "Parallel deployment with Form/Cookie
> authentications", the META tag example should be " http-equiv="refresh" ...>" instead of ">META http-equiv="refresh"
> ...<".
> 
> * In section 7. "IANA Considerations", the word "documents" should
> be "document" in the phrase "a publicly-accessible documents".



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-Art review of draft-ietf-6man-ipv6-mibs-obsolete-01

[Jari Arkko]

Jouni, Bill,

Thanks for the review and updates. I posted no-objection for this draft.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ice-dualstack-fairness-03

[Jari Arkko]

Thanks for the reviews & fixes!

Jari

On 04 Aug 2016, at 17:57, Meral Shirazipour  
wrote:

> Hi,
>   Many thanks.
> 
> Best,
> Meral
> 
> From: Pal Martinsen (palmarti) [mailto:palma...@cisco.com]
> Sent: Wednesday, August 03, 2016 11:55 PM
> To: Meral Shirazipour 
> Cc: draft-ietf-ice-dualstack-fairness@tools.ietf.org; gen-art@ietf.org
> Subject: Re: Gen-ART Last Call review of draft-ietf-ice-dualstack-fairness-03
> 
> 
> On 05 Jul 2016, at 17:46, Meral Shirazipour  
> wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the 
> IETF Chair.  Please treat these comments just like any other last call 
> comments.
> 
> For more information, please see the FAQ at 
> .
> 
> 
> Document:  draft-ietf-ice-dualstack-fairness-03
> Reviewer: Meral Shirazipour
> Review Date: 2016-07-05
> IETF LC End Date:  2016-07-08
> IESG Telechat date: NA
> 
> 
> Summary:
> This draft is ready to be published as BCP RFC but I have some comments.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> -[Page 2], “arguable be better">"arguably be better"
> Fixed
> 
> -[Page 2], “types know">"types known"
> Fixed
> 
> -[Page 8], Section 7.1 and 7.2 have the same title, is that by choice?
> Sort of. Theee sections are implementation details and will be removed in the 
> published RFC.
> 
> 
> -[Page 9], Section 10.1, first reference ([I-D.ietf-ice-rfc5245bis])to be 
> updated to latest version.
> -Also on [Page 4] Reference to “section 4.1.2.1" of 
> [I-D.ietf-ice-rfc5245bis], it would be good to list the section title too (in 
> case the numbering changes in the final version).
> Good point. Fixed.
> 
> 
> New version uploaded. It also contains fixes from the secdir review.
> 
> .-.
> Pål-Erik
> 
> 
> 
> Best Regards,
> Meral
> ---
> Meral Shirazipour
> Ericsson Research
> www.ericsson.com
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-tram-turn-server-discovery-08

[Jari Arkko]

Ralph, Tiru — thanks for the updates and the review. I’ve looked at the change 
draft and I think it is fine now.

Jari




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-tram-turn-mobility-03

[Jari Arkko]

Pete, Tiru,

Thanks for the reviews & updates. Much appreciated. I have balloted no 
objection for this document.

Jari




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art