Elwyn Davies | 31 Oct 20:47 2014

Gen-art LC review of draft-ietf-mpls-mldp-in-band-wildcard-encoding-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-mpls-mldp-in-band-wildcard-encoding-02.txt
Reviewer: Elwyn Davies
Review Date:  2014-10-31
IETF LC End Date: 2014-10-27
IESG Telechat date: (if known) -

Summary:
Almost ready.  There are a couple of clarifications around how IPv4 and 
IPv6 trees can or cannot be merged on a single MP-LSP that would be 
advantageous.  Also the error handling in the parent RFCs
(6388, 6826) is a bit sketchy resulting in messy handling if an LSR that 
does not support the wildcard
encoding is accidentally sent the TLVs from this draft.  I am not sure 
if this can be cleaned up (and maybe there is no thought to be a problem 
- I am not sufficiently expert in LDP signalling).

PS Apologies for the late review - Overtaken by holidays.

Major issues:
None.

Minor issues:
(Continue reading)

A. Jean Mahoney | 30 Oct 21:58 2014

A *new* batch of IETF LC reviews - 2014-10-30

Hi all,

The following reviewers have assignments:

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

Francis Dupont    2014-11-06   draft-ietf-opsawg-mibs-to-ieee80231-01

Joel Halpern      2014-11-10   draft-ietf-bmwg-bgp-basic-convergence-04

Martin Thomson    2014-11-18   draft-dukhovni-opportunistic-security-05 *

Meral Shirazipour 2014-11-10   draft-ietf-opsawg-capwap-hybridmac-06

Robert Sparks     2014-11-25   draft-mcdonald-ipps-uri-scheme-15

* 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 | 30 Oct 14:49 2014
Picon

Re: Gen-ART review of draft-ietf-softwire-4rd-08.txt

Thanks for the review, Christer, and thanks Remi for volunteering to address these.

jari

On 06 Oct 2014, at 13:40, Christer Holmberg <christer.holmberg <at> ericsson.com> wrote:

> 
> 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-softwire-4rd-08.txt
> 
> Reviewer:                 	Christer Holmberg
> 
> Review Date:            	6 October 2014
> 
> IETF LC End Date:       	10 October 2014
> 
> IETF Telechat Date:      	16 October 2014
> 
> Summary:                         The document is well written, and almost ready for publication, but there are some editorial
nits that I ask the authors to address before publishing.
> 
> Major Issues: None
> 
> Minor Issues: None
> 
> Editorial nits: None
> 
> 
> QGEN_1:
(Continue reading)

Alexey Melnikov | 30 Oct 12:05 2014

Review of draft-ietf-rtcweb-data-protocol-08.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-rtcweb-data-protocol-08.txt
Reviewer: Alexey Melnikov
Review Date: 30 October 2014
IETF LC End Date: 24 October 2014
IESG Telechat date: 30 October 2014

Summary: Ready (with nits)

Major issues: None

Minor issues: None

Nits/editorial comments:

On page 6 the first reference to UTF-8 needs a Normative Reference.
Jari Arkko | 30 Oct 09:54 2014
Picon

.all and non-wg-chair shepherds

We recently had a case where a document shepherd did not receive a review, because he didn’t happen to be
one of the WG chairs.

Gen-ART reviewers tend to send their reviews to draft-foo.all address. Shepherd names are available in
the tracker, but we do not normally dig them up.. because normally they are part of .all.

Thoughts on what we should do about this?

Jari

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Vijay K. Gurbani | 29 Oct 21:15 2014

Gen-ART review of draft-ietf-rtcweb-data-channel-12

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-rtcweb-data-channel-12
Reviewer: Vijay K. Gurbani
Review Date: Oct-29-2014
IETF LC End Date: Oct-23-2014
IESG Telechat date: Oct-30-2014

This document is ready as a Proposed Standard.

Major: 0
Minor: 1
Nits: 1

Minor: 1
- S3.1, U-C 1: Why is it important to specify tha "there may be no
  SRTP media channels, or all SRTP media channels may be inactive"?
  It seems to me that all you care about is data channels, not
  media channels.  As such, retaining the last phrase ("there may also
  be reliable data channels in use") suffices, no?

  (Same comment for S3.2, U-C 3).
  (Same comment for S4, Req. 1.  This makes me wonder if I am missing
   something germane here with respect to you listing the availability
   or unavailability of SRTP media streams/channels.  If so, please
(Continue reading)

Francis Dupont | 29 Oct 14:56 2014
Picon

review of draft-ietf-mpls-ipv6-only-gap-03.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-mpls-ipv6-only-gap-03.txt
Reviewer: Francis Dupont
Review Date: 20141025
IETF LC End Date: 20141027
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - ToC page 2 and 5 page 18: Acknowledgements -> Acknowledgments

 - 3.2.6 page 8: singaling -> signaling

 - 3.3.1 page 9: e.g. -> e.g.,

 - 3.3.2.4.1 pages 11 and 12: the conclusion (Gap: None) doesn't seem
  very in phase with the text. Perhaps it is another case of "out of scope
  known gap"?
(Continue reading)

Suresh Krishnan | 29 Oct 06:34 2014
Picon

Gen-ART Telechat review of draft-ietf-bmwg-sip-bench-term-11

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-bmwg-sip-bench-term-11.txt
Reviewer: Suresh Krishnan
Review Date: 2013/10/28
IESG Telechat date: 2013/10/30

Summary: This draft is ready for publication as an Informational RFC.

Thanks
Suresh
Suresh Krishnan | 29 Oct 05:11 2014
Picon

Gen-ART Telechat review of draft-ietf-l2vpn-ipls-15.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-l2vpn-ipls-15.txt
Reviewer: Suresh Krishnan
Review Date: 2013/10/28
IESG Telechat date: 2013/10/30

Summary: This document is ready for publication as a Historic RFC, but I 
have some comments you may wish to address.

* Section 7.1

The Length field of the IP address TLV in case the IP address is IPv6 is 
not defined. It should be defined to be 18 (2 bytes for address family 
and 16 bytes for the IPv6 address)

* Address family reference

The IANA registry at 
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml 
is a much better reference for address families than the currently 
referred RFC3232 that does not contain any of the relevant information.

Thanks
Suresh
(Continue reading)

Suresh Krishnan | 29 Oct 04:31 2014
Picon

Gen-ART Telechat review of draft-ietf-weirds-bootstrap-09.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-weirds-bootstrap-09.txt
Reviewer: Suresh Krishnan
Review Date: 2013/10/28
IESG Telechat date: 2013/10/30

Summary: The document is almost ready for publication as Proposed 
Standard, but I do have a comment you may wish to consider.

* Sections 5.2 and 5.3

-> The document uses some non-documentation addresses (AFAIK) in some of 
the examples. e.g. 28.2.0.0/16 for an IPv4 prefix and 2600::/16 for an 
IPv6 prefix. Is it possible to rewrite these examples using reserved 
documentation addresses? Strangely enough, idnits does not seem to catch 
them either.

Thanks
Suresh
Suresh Krishnan | 28 Oct 23:22 2014
Picon

Gen-ART Telechat review of draft-ietf-ospf-security-extension-manual-keying-09.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ospf-security-extension-manual-keying-09.txt
Reviewer: Suresh Krishnan
Review Date: 2013/10/28
IESG Telechat date: 2013/10/30

Summary: The draft is almost ready for publication as Proposed Standard 
but has some issues that need to be addressed.

* Section 2

-> There is no reference to snmpEngineBoots in the RFC4222 reference. 
Are you pointing to the wrong document here? I would suggest replacing 
the RFC4222 reference with a reference to RFC2574 Section 2.2 that talks 
about replay protection.

-> There is another change to the 64-bit authentication field that is 
not described in the text. The 0 field in the beginning is extended from 
16 bits to 24 bits. Can you please add this.

* Section 5

-> It is unclear from this text what the exact change to the 
authentication trailer is. The only logical explanation I could come up 
(Continue reading)


Gmane