Vijay K. Gurbani | 2 Sep 23:06 2015

Gen-ART review of draft-ietf-precis-mappings-11

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-precis-mappings-11
Reviewer: Vijay K. Gurbani
Review Date: Sep-02-2015
IETF LC End Date: Not known
IESG Telechat date: Sep-03-2015

This document is ready as an Informational.

Major: 0
Minor: 0
Nits:  1

Nits:

- S2, second to last paragraph.  Is "RECOMMENDED" as in rfc2119?  If so,
  please put rfc2119 in the references.

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
(Continue reading)

Francis Dupont | 2 Sep 12:19 2015
Picon

review of draft-ietf-ecrit-additional-data-34.txt

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

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

Document: draft-ietf-ecrit-additional-data-34.txt
Reviewer: Francis Dupont
Review Date: 20150828
IETF LC End Date: 20150824
IESG Telechat date: 20150903

Summary: Almost Ready

Major issues: None

Minor issues:
 This document uses and even redefines RFC 2119 keywords outside the
*formal* wording of RFC 2119: quoting the RFC 2119 (Abstract):
 "These words are often capitalized."
This formally means a keyword in lower case is still a keyword which
must (MUST :-) be interpreted as described in RFC 2119. IMHO this is
for very old IETF documents: any IETF document published less than 20
years ago uses full upper case keywords when they have to be interpreted
so this statement in the RFC 2119 Abstract is more source of confusion
than clarification.
 If it can be accepted I propose to add an exception for this document
(Continue reading)

Peter Yee | 2 Sep 10:01 2015

Gen-ART Telechat review of draft-bradner-iaoc-terms-04

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 more information, please see the FAQ at

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

Document: draft-bradner-iaoc-terms-04
Reviewer: Peter Yee
Review Date: Sep-01-2015
IETF LC End Date: Jul-27-2015
IESG Telechat date: Sep-03-2015

Summary: This draft is basically ready for publication as a BCP, but has a
nit that should be fixed before publication. [Ready with nits]

The draft updates BCP 101 to fix some issues around the beginning and end
of IAOC terms.

This version simplifies the fix from the previous version I reviewed.  I’m
not entirely certain it covers the vacancy filling case for IAOC members
that appeared in version -01, but given the vigorous arguments that have
already taken place, I’m going to let that slide.

Major issues: None

Minor issues: None

(Continue reading)

Suresh Krishnan | 2 Sep 05:17 2015
Picon

Gen-ART Telechat review of draft-sparks-genarea-review-tracker-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 wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-sparks-genarea-review-tracker-03.txt
Reviewer: Suresh Krishnan
Review Date: 2015/09/01
IESG Telechat date: 2015/09/03

Summary: The draft is ready for publication as an Informational RFC but 
I do have some comments you may wish to address.

* Section 2

Not sure what the "draft's primary email alias" refers to. Is this the 
draft-foo <at> ietf.org or draft-foo.all <at> ietf.org? In either case it may make 
sense to clarify.

* Section 3.3

"A reviewer must be able to configure the tool to remind them when 
actions are due."

It would be nice if the tool would allow the reviewer to set an 
individually customizable lead time here. e.g. Remind 2 days before the 
LC is due or 3 days before the Telechat.

(Continue reading)

Suresh Krishnan | 2 Sep 05:16 2015
Picon

Gen-ART Telechat review of draft-sparks-genarea-review-tracker-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 wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-sparks-genarea-review-tracker-03.txt
Reviewer: Suresh Krishnan
Review Date: 2015/09/01
IESG Telechat date: 2015/09/03

Summary: The draft is ready for publication as an Informational RFC but 
I do have some comments you may wish to address.

* Section 2

Not sure what the "draft's primary email alias" refers to. Is this the 
draft-foo <at> ietf.org or draft-foo.all <at> ietf.org? In either case it may make 
sense to clarify.

* Section 3.3

"A reviewer must be able to configure the tool to remind them when 
actions are due."

It would be nice if the tool would allow the reviewer to set an 
individually customizable lead time here. e.g. Remind 2 days before the 
LC is due or 3 days before the Telechat.

(Continue reading)

Brian E Carpenter | 2 Sep 01:30 2015
Picon

Gen-ART Last Call review of draft-ietf-dice-profile-14

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dice-profile-14.txt
Reviewer: Brian Carpenter
Review Date: 2015-09-02
IETF LC End Date: 2015-09-04
IESG Telechat date:

Summary:  Ready with issues
--------

Comment:
--------

This is complicated and I'm not an expert. I went through the whole document but have to
take most of the details on trust.

Major Issues:
-------------

One thing puzzles me. Unless I have missed it, the profile is neutral on the choice
described in Section 6 (Credential Types): pre-shared secrets, raw public keys, or
certificates. How does this work to help interoperability in multivendor environments?
Wouldn't it be better to RECOMMEND one?
(Continue reading)

Meral Shirazipour | 1 Sep 01:15 2015
Picon

Gen-ART Telechat Call review of draft-ietf-tls-padding-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 wait for direction from your document shepherd or AD before posting a new version of the draft.

 

Document: draft-ietf-tls-padding-02

Reviewer: Meral Shirazipour

Review Date: 2015-08-31

IETF LC End Date: 2015-08-24

IESG Telechat date: 2015-09-03

 

Summary: This draft is ready to be published as Standards Track RFC.

 

Note: LC comments addressed in http://www.ietf.org/mail-archive/web/gen-art/current/msg12082.html

 

 

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
Peter Yee | 28 Aug 23:26 2015

Gen-art LC review of draft-ietf-mpls-tp-oam-id-mib-08

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 background on Gen-ART, please see
the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-mpls-tp-oam-id-mib-08
Reviewer: Peter Yee
Review Date: Aug-27-2015
IETF LC End Date: Aug-27-2015
IESG Telechat date: TBD

Summary: This draft is on the right track but has open issues, described
in the review. [Ready with nits.]

The draft specifies an OAM MIB for the MPLS Transport Profile.

Major issues: None

Minor issues: None

Nits:

General: There are a lot of the definite and indefinite articles missing
in the draft.  Mostly this occurs in description text in the MIB.  These
do help readability, so consider using them going forward.  There are a
few specific cases where I wasn’t certain whether a definite or indefinite
article would have been more appropriate; removing this ambiguity would be
a good thing.

General: fix the footer so that only one space occurs after “Aldrin,”.

Page 1, Abstract: change “MPLS based” to “MPLS-based”.

Page 3, section 1, 1st paragraph, 2nd sentence: append a hyphen after
“Switching”.

Page 3, section 1, 2nd paragraph: consider adding “Tunnel, ” before “LSP”
as the body of the draft also describes tunnel support.  Append a space
after “LSP”.  Append a comma after “Pseudowires”.

Page 3, section 2, 2nd paragraph, 3rd sentence: change “compliant to” to
“compliant with”.  For the STD/RFC list, rewrite as: “STD 58 (RFC 2578,
RFC 2579, RFC 2580)”.

Page 3, section 3.1: change “RFC-2119” to “RFC 2119”.

Page 4, section 4: append a comma after “associated bidirectional LSPs”.

Page 4, section 5: change “IP compatible” to “IP-compatible”.  Change “ICC
based” to “ICC-based”.  Make those changes globally in the document.
Append a comma after “LSPs”.

Page 5, 2nd paragraph: append a comma after LSPs.  Consider your usage of
“Pseudowire” vs. “pseudowire”; there’s some inconsistency in
capitalization.  While the capitalized form makes sense in titles and in
other locations where it derives from a source document that uses it that
way, the remaining uses in the document should aim for consistency.  If
nothing else, it will keep ignorant readers (like me) from guessing if
there’s a hidden meaning to the capitalization.

Page 5, section 6, 2nd paragraph: Remove the “a” before “MEG”.

Page 5, section 6, 3rd paragraph, 1st sentence: change “a MPLS” to “an
MPLS”.

Page 5, section 6, 3rd paragraph, 2nd sentence: change “IP based” to
“IP-based”.  Make that change globally.  Insert “an” before “MPLS”.

Page 7, Contact Info for Sam Aldrin: append “ 94043” after “CA”.  We
denizens of 94043 should be proud of our rare zip code. ;-)

Page 8: Are two “DESCRIPTION” sections allowed?  I am in no way a MIB
doctor, so I ask simply from a consistency standpoint.  If only one is
allowed, then combine the IETF boilerplate/brief overview and the longer
text that more fully describes what this module does into one DESCRIPTION
block.  In either case, append a comma after “Pseudowires”.

Page 9, for the descriptive text for "associated bidirectional LSP” and
“PW”, a space is found in front of Z9.  While this is obviously just text,
it appears inconsistent with other usage, so consider removing the spaces.

Page 11, mplsOamIdMegName DESCRIPTION: insert “a” before “unique”.

Page 11/12: mplsOamIdMegIdCc, mplsOamIdMegIdIcc, and mplsOamIdMegIdUmc
definition: the text starting "This object MUST contain a non-null ICC
value” appears in each DESCRIPTION.  I believe this text should use “CC”,
“ICC”, and “UMC” respectively, twice in each DESCRIPTION.  I’m also not
sure what “octet size 0” means in those DESCRIPTIONs.  Furthermore, the
DESCRIPTIONs note that the ICC is concatentated with the CC to ensure
global uniqueness, but that the UMC is appended to the ICC to form the
MEGID.  It’s ambiguous as to whether that implies the MEGID is ICC+CC+UMC
or ICC+UMC+CC.

Page 12, mplsOamIdMegIdUmc DESCRIPTION: append a comma after “Provider”.
Change “and” to “which”.

Page 13, REFERENCEs: there appear to be at least two different style of
textual references used in the MIB.  Pick one?

Page 14, last partial sentence: insert a space before “(1)”.  up is not a
function. ;-)  Do the same thing for “(2)” at the top of the following
page (15) along with (1) near the bottom of the page.

Page 20, mplsOamIdMeSinkMepIndex DESCRIPTION: insert “to” before “zero”.
Append a space after “Identifiers”.

Page 20, mplsOamIdMeMpType DESCRIPTION, 2nd paragraph: delete an
extraneous space after "mep (1),”.

Page 20, mplsOamIdMeMpType DESCRIPTION, 3rd paragraph: “end nodes” are
mentioned in this paragraph.  Are these the same as the “Egress nodes” in
the previous paragraph.  If so, considering using consistent terminology,
at least between the two paragraphs.

Page 21, mplsOamIdMeServicePointer DESCRIPTION, 2nd paragraph: delete the
first two commas.  Insert “the” before “ME” and “MEG”.

Page 21, mplsOamIdMeRowStatus DESCRIPTION: insert a space before “(1)”.

Page 27, section 8, 1st paragraph, 1st sentence: change “is” to “are”.
Change “has” to “have”.  Yes, really.

Page 28, 2nd full paragraph, 1st sentence: do you mean “Further” as in
“Also”?  Or should you omit the comma to indicate that continued
deployment of older versions of SNMP is deprecated?  If you mean the
latter, delete the comma after “Further”.

Page 30, section 11: append a comma after “Cheng”.

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Elwyn Davies | 28 Aug 19:45 2015

Gen-art LC review of draft-ietf-mpls-mldp-node-protection-05


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

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

Document: draft-ietf-mpls-mldp-node-protection-05
Reviewer: Elwyn Davies
Review Date: 2015/08/28
IETF LC End Date: 2015/09/08
IESG Telechat date: (if known) -

Summary:
Almost ready.  The distinction that (I believe) is the case, between the need for unidirectional bypass LDPs in the non-root case and bidirectional (or two unidirectional) ones in the root case appears to merit some additional explanation.  Otherwise, there are a couple of minor issues  that are only just above the level of nits.  In particular, there doesn't seem to be any explanation of why the PLRs and MPTs have to be directly connected to the protected node (RFC 6388 is happy to find non-directly connected nodes) and I cannot see why direct connection is vital to this specification.  This may of course because I am not an MPLS afficionado!  There are, however, a considerable number of language nits which I have documented - another editorial pass by a reviewer with English mother tongue after fixing the nits I found would probably help.

Major issues:
None.

Minor issues:
s1:  This specification uses LDP capability negotiation (RFC 5561).  The introduction should be clear that nodes involved in the node protection scheme MUST support RFC 5561 negotiations.

s1, para 2:  There is a very dangerous slang phrase here: "most ... should just work"!   Does this have the literal meaning that there are some circumstances in which they might NOT work and/or there are other capabilities that aren't enabled - if so, what are they? Or, I guess more likely, the slang meaning that using this method will allow these capabilities to work without additional effort.  Please use a non-slang phrase and be more precise as to what will/won't work.

s2.1:
The upstream LSR in figure 1 is LSR1 because it is the ***first hop*** along the shortest path to reach the root address.
Does it have to be the 'first hop' (I read this as the first LSR on the path from N towards the root)?
RFC 6388 s2.4.1.1 allows the upstream to be any LSR along the path according to some local selection policy.  Can't the PLR be any such upstream LSR?

s2.2:  Following on from the previous comment, do LSR1..3 *have* to be 'directly connected'?  Can they not be just one from the set of LSRs along each separate LSR emanating from the root?

s2.2:  If I understand correctly, the bypass LSPs have to be bidirectional (or they could be two unidirectional ones) unlike those in s2.1 which will be unidirectional.  I think this ought to be mentioned, assuming I am right - and presumably one could do a bit of optimisation in setup.  This has some knock-on effects as regards what happens when the node fails.  I wonder if there should be some explanation of what happens in an extra sub-section in s4 - just that the various LSRs need to think about what role they are playing depending on where the incoming packets are coming from, I guess.

s2.3, next to last para:
To remove all PLR addresses belonging to the encoded Address Family, an LSR N MUST encode PLR Status Value Element with no PLR entry and "Num PLR entry" field MUST be set to zero.
 This is inconsistent with the statement in the "PLR Status Value Element" figure:
            PLR entry (1 or more)
I guess this last should be 'zero or more'.

Nits/editorial comments:
======================
Abstract: Need to expand LSR on first use.

Abstract and  s1: s/that has been built by/that have been built by the/ (2 places)

s1, para 1: Need to expand RSVP-TE and LFA on first use, and give references for them - probably RFC 5420 for RSVP-TE and RFC 5286 for LDP LFA.

s1, para 2: s/Targetted/Targeted/

s1.2: mLDP probably needs a reference - RFC 6388, I guess

s1, para 2: the concept 'Target(t)ed LDP session' comes from RFC 7060 - please add a reference.

s2: It might be helpful to mention that the tLDP sessions are established over the bypass LSPs from PLR to MPT and reiterate the comments in s1 about how these LSPs might be established to avoid the protected node.

s2: The term 'root node' (presumably from RFC 6388) should be in the terminology section.

s2: s/e.g./e.g.,/

s2.1, s2.2, s5: The use of phrases such as 'we are ...ing' is deprecated for RFCs - please rephrase using, for example, 'this document <does something>'.

s2.1, Fig 1 caption: s/to the LSR2/to LSR2/

s2.1: 'which is feature enabled':  Although it is probably obvious it would be clearer to say 'which has the node protection feature enabled'

s2.1: s/i.e./i.e.,/

s2.1: s/for Capability negotiation/during Capability negotiation/

s2.2, last para: s/don't/doesn't/, s/will help/will help in/

s2.3, para 1: s/with MP status TLV/with an MP status TLV (see Section 5 of [RFC6388])/

s2.3: 'Length' and 'Num PLR entry' fields need a type (presumably 'unsigned integer')

s2.3, "Address Family": s/Address Family/Addr Family/ (for consistency with Figure); also add a reference for the correct IANA registry (http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml)

s2.3, "Num PLR entry":
OLD:
      Element, followed by "Num PLR entry" field (please see format of a
      PLR entry below).
NEW:
      Element as an unsigned, non-zero integer followed by that number of  "PLR entry" fields in the format specified below.
END
(but see issue above, regarding non-zero)

s2.3, "PLR Entry", s/must be zero/MUST be zero/ (I assume). (also applies to Reserved fields in s5.4)

s2.3, 3rd last para: s/is depending on/is dependent on/

s2.3, next to last para:
OLD:
by setting "A bit"
   to 1 or 0 respectively in corresponding PLR entry.
NEW:
by setting the "A bit"
   to 1 or 0 respectively in the corresponding PLR entry.
END

s2.3, last para:  The term "MP FEC TLV" is not defined explicitly anywhere.  I take it from RFC 6388 that it is (probably) a FEC TLV [RFC5036] with a P2MP FEC Element in it.  Please give references and make it clear what is implied.

s3, para 1: s/PLR MP Status/PLR Status/ (there is no such thing as a PLR MP Status.)

s3, "Length": Needs the type defined (unsigned integer presumably); also s/(for Address/for Address/

s3, "Address Family": s/Address Family/Addr Family/ (for consistency with Figure); also add a reference for the correct IANA registry (http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml)

s3, last para: s/Typical/Typically/

s4, para after Fig 3:
The English in this para needs considerable attention. Suggestion:
OLD:
Assume that LSR1 is the PLR for protected node N, LSR2 and LSR3 are MPTs for node N. When LSR1 discovered that node N is unreachable, it can't determine whether it is the 'LSR1 - N' link or node N that failed. In Figure 3, the link between LSR1 and N is also protected using Fast ReRoute (FRR) [RFC4090] link protection via node M. LSR1 MAY potentially invoke 2 protection mechanisms at the same time, redirection the traffic due to link protection via node M to N, and for node protection directly to LSR1 and LSR2. If only the link failed, LSR2 and LSR3 will receive the packets twice due to the two protection mechanisms. To prevent duplicate packets to be forwarded to the receivers on the tree, LSR2 and LSR3 need to determin which upstream node to accept the packets from. So, either from the primary upstream LSR N or from the secondary upstream LSR1, but never both at the same time. The selection between the primary upstream LSR or (one or more) secondary upstream LSRs (on LSR2 and LSR3) is based on the reachability of the protected node N. As long as N is reachable, N is the primary upstream LSR who is accepting the MPLS packets and forwarding them. Once N becomes unreachable, the secondary upstream LSRs (LSR1 in our example) are activated. Note that detecting if N is unreachable is a local decision and not spelled out in this draft. Typical link failure or Bidirectional Forwarding Detection (BFD) can be used to determine and detect node unreachability. NEW: Assume that LSR1 is the PLR for protected node N, LSR2 and LSR3 are MPTs for node N. When LSR1 discovers that node N is unreachable, it cannot immediately determine whether it is the link from LSR1 to N or the actual node N that has failed. In Figure 3, the link between LSR1 and N is also protected using Fast ReRoute (FRR) [RFC4090] link protection via node M. LSR1 MAY potentially invoke both protection mechanisms at the same time, that is redirection of the traffic using link protection via node M to N, and for node protection directly to LSR1 and LSR2. If only the link failed, LSR2 and LSR3 will receive the packets twice due to the two protection mechanisms. To prevent duplicate packets being forwarded to the receivers on the tree, LSR2 and LSR3 need to determine from which upstream node they should accept the packets. This can be either from the primary upstream LSR N or from the secondary upstream LSR1, but never both at the same time. The selection between the primary upstream LSR or (one or more) secondary upstream LSRs (on LSR2 and LSR3) is based on the reachability of the protected node N. As long as N is reachable from an MPT, the MPT should accept and forward the MPLS packets from N. Once N becomes unreachable, the LSPs frpm secondary upstream PLR LSRs (LSR1 in our example) are activated. Note that detecting if N is unreachable is a local decision and not spelled out in this draft. Typically link failure or Bidirectional Forwarding Detection (BFD) can be used to determine and detect node unreachability. END s4.1, caption of Fig 4: s/after N failure/after failure of node N/ s4.1, last para: OLD: Assume that LSR1 has detected that Node N is unreachable and invoked both the Link Protection and Node Protection procedures as described in this draft. LSR1 is acting as PLR and sending traffic over both the backup P2P LSP to node N (via M) and the P2P LSPs directly to LSR2 and LSR3, acting as MPT LSRs. The sequence of events are depending on whether the link 'LSR1 - N' has failed or node N itself. The node's downsteam from the protected node (and participating in node protection) MUST have the capability to determin that the protected node became unreachable. Otherwise the procedures below can not be applied. NEW: Assume that LSR1 has detected that Node N is unreachable and invoked both the Link Protection and Node Protection procedures as described in this example. LSR1 is acting as PLR and sending traffic over both the backup P2P LSP to node N (via M) and the P2P LSPs directly to LSR2 and LSR3, acting as MPT LSRs. The sequence of events is dependent on whether the link from LSR1 to N has failed or node N itself. The nodes downstream from the protected node (and participating in node protection) MUST have the capability to determine that the protected node has become unreachable. Otherwise the procedures below can not be applied. END s4.1.1: s/over the/over to the/; s/that where/that were/ s4.1.2: s/MUST sent a Label/MUST sen a Label/ s5.2, last para: s/the MPT capable/MPT capable/ s5.4, "Length": - unsigned integer again. s5.4, P and M bits: Add 'Set to 1 to indicate...'
_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Brian E Carpenter | 28 Aug 05:55 2015
Picon

Gen-ART telechatl review of draft-ietf-payload-rtp-h265-14

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 more information, please see the FAQ at

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

Document: draft-ietf-payload-rtp-h265-14
Reviewer: Brian Carpenter
Review Date: 2015-08-28
IETF LC End Date: 2015-08-14
IESG Telechat date: 2015-09-03

Summary: Ready

Comment: Thanks for handling my Last Call comments
A. Jean Mahoney | 28 Aug 00:32 2015

Assignments for the 2015-09-03 Telechat

Hi all,

The following reviewers have assignments:

Reviewer            LC end       Draft
----------------------------------------------------------------------------------
Alexey Melnikov   2014-12-01   draft-ietf-grow-irr-routing-policy-considerations-06 *

Brian Carpenter   2015-08-14   draft-ietf-payload-rtp-h265-14 **

Christer Holmberg 2015-08-18   draft-ietf-bess-mvpn-global-table-mcast-02

David Black       2015-07-07   draft-wkumari-dhc-capport-15 *

Francis Dupont    2015-08-24   draft-ietf-ecrit-additional-data-34

Joel Halpern      2015-08-11   draft-ietf-dnsop-onion-tld-00 **

Meral Shirazipour 2015-08-24   draft-ietf-tls-padding-02 *

Paul Kyzivat      2015-07-10   draft-ietf-precis-nickname-18 **

Peter Yee         2015-07-27   draft-bradner-iaoc-terms-03 *

Robert Sparks     2015-08-25   draft-hansen-scram-sha256-04 *

Suresh Krishnan   2015-08-04   draft-sparks-genarea-review-tracker-03
Suresh Krishnan   2015-08-17   draft-iab-crypto-alg-agility-07 **

Tom Taylor        2015-08-04   draft-ietf-httpbis-cice-02 *

Vijay Gurbani     2015-08-04   draft-ietf-precis-mappings-11

Wassim Haddad     2015-08-28   draft-ietf-forces-lfb-subsidiary-management-01

* Earlier draft reviewed
** Already reviewed

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

For your convenience, the review boilerplate template is included below.

Note that reviews should ideally be posted to the gen-art mailing list
by COB on Tuesday:
http://wiki.tools.ietf.org/area/gen/trac/wiki/

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

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

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

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

Gmane