Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-rfc4379bis-07

[Carlos Pignataro (cpignata)]

Deal Elwyn,

Many thanks for a great review!

I just finished addressing all your comments: the major issue (easy to address, 
editorial fix, but with important implications), the minors, and all the nits. 
Surprisingly, I found a few small additional editorials, which I fixed as well.

Rev -08 would address all outstanding issues, from this review, Mirja, and a 
couple others.

Please see inline for a line-by-line set of responses.

On Oct 20, 2016, at 4:42 PM, Elwyn Davies 
> 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-mpls-rfc4379bis-07.txt
Reviewer: Elwyn Davies
Review Date: 2016/10/21
IETF LC End Date: 2016/10/18
IESG Telechat date: (if known) -

Summary: Not ready.  There is one major issue (already notified to authors and 
agreed as an issue) and a considerable number of minor and editorial issues. I 
have worked through the various RFCs and errata that are subsumed into the new 
version and almost everything has been correctly translated AFAICS.  A couple 
of minor points are covered in the comments.

Major issues:

s3.4: A number of items that are used in the normative Downstream Detailed 
Mapping TLV were originally defined in s3.3 (Downstream Mapping TLV format) but 
have been shifted to Appendix A.2.  This appendix is marked as non-normative.  
Thus there are now no normative definitions for the various TLVs used in s3.4 
that are defined in A.2.  I fear that these need to be returned to the 
normative part of the specification.


This is an excellent catch. Thank you. The fix is simple and purely editorial 
but the implication is clear.

I finished addressing this, which you will see posted as the new revision. I am 
super happy with the outcome.

[I think it would be simplest and least error prone to swap the text that was 
in s3.3 of RFC 4379 back out of A.2 and put backward references to the new s3.4 
into A.2 as necessary.]

Minor issues:

Sender/receiver terminology: The document can be somewhat confusing to a naive 
reader.  Sender and receiver are used in multiple contexts.  Where the context 
appears to relate to LSP ping, both senders and receivers are involved in 
sending LSP ping packets.  In general, sender and receiver appear to imply 
sending and receiving of Echo Request messages with their roles reversed with 
respect to Echo Responses, with the receiver stimulated to send an Echo 
Response by receiving an Echo Request.  It would help if this terminology and 
usage was explicitly set out early in the document.  Additionally, some 
instances would be made more comprehensible by making the function explicit in 
the text e.g., in the operation of return codes.

Re-reading after fixing all the nits below, which include some sender 
clarifications, looks good.


s1.4/s3/s6.2.3: The R (Global) flag is defined in RFC 6426.  Unfortunately it 
isn't in the IANA considerations there as was spotted in RFC Erratum 4012.  
Might be worth mentioning the erratum (probably in s1.4?)  Alternatively this 
document can be made to provide the IANA specification for the R flag and the 
erratum closed.

The WG decided to keep the definition of the R Flag in RFC 6426 and not here — 
consequently, there’s little that can really be done as the erratum (which 
really is symbolic since the IANA registry is fixed) applies to RFC 6426 and 
not to RFC 4379.


s2.1/s6: An update to 
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
 is needed to replace RFC 4379 with RFC-to-be for special exceptions to usage 
rules.


Done.

s3.5, Clandestine Channel via Pad TLV:  As specified the value part of a Pad 
TLV can serve as a clandestine channel since the  value field contents are 
ignored.


Added the following to S5:
   The value part of the Pad TLV contains a variable number of octets.
   With the exception of the first octet, these contents, if any, are
   ignored on receipt, and can therefore serve as a clandestine channel.


s3.5, Usefulness of Pad TLV:  Could you explain circumstances in which a Pad 
TLV would be needed please. I can't see any at present.


Sure — when you want to send pings of various sizes for troubleshooting. I’ve 
used it in productions :-)

Nits/editorial comments:
==

Thank for for these. Unless I make a specific follow-up inline, the nit is 
fixed.

General: s/i.e. /i.e., / (two instances  s3.2, last para; s4.5.1, para 3)

s1, para 1: s/methods of reliable reply/methods of providing reliable reply/

s1.4, bullet 4: Need to expand acronym PW on first use.

s1.4, bullet 4: 

Re: [Gen-art] Review: draft-bbf-bbf-urn-02

[Joel M. Halpern]

Thanks Barbarra.

With regard to the assignment process text, what you have would work.  I 
would suggest dropping the text about membership and simply talking 
about going through the BBF document creation and approval process.


Yours,
Joel

On 10/27/16 12:53 PM, STARK, BARBARA H wrote:

Hi Joel,


Major issues:
 RFC 3406 states that the namespace considerations section should indicate
why a new namespace is needed.  While this is pretty obvious, the text does
not actually say anything in that section to explain it.
 In particular, I would expect that section to explain why 3 NIDs are needed
rather than just 1.


Thanks for the comments. I propose adding the following text at the end of Namespace 
Considerations (the mention of the name change is part of a proposal to resolve a 
separate comment asking how "dslforum-org" relates to BBF):
   Three NIDs are defined. The "broadband-forum-org" and "dslforum-org"
   (Broadband Forum changed its name from DSL Forum in 2008) NIDs have
   been used for many years by BBF without formal registration. As they are
   referenced by multiple BBF specifications currently in common use, BBF is
   requesting to formalize them. The new "bbf" NID will be used for new work 
efforts.


Minor issues:
 The template in RFC 3406 indicates the the section in each NID on the
Process of identifier assignment should "detail the mechanism and or
authorities for assigning URNs to resources."  The draft simply says that the
BBF will provide procedures.  Do those procedures exist?  If not, there seems
to be a minor problem.  If they do exist, it would seem sensible to include a
pointer to the place where the BBF publicly documents those procedures, so
that people using this information who might want to register something can
understand what the rules and expectations are. (I realize that the RFC 6289
example this is based on did not include such a pointer, which is why I am
making this a minor comment instead of a major one.)


I'm struggling a bit with this one in trying to figure out what's the best thing to say here. 
At this point in time, URN assignments only happen through creation of a BBF document that 
identifies the URN. BBF processes for document creation are published on the members-only part 
of the website, and only BBF members can participate in creating a BBF document. There is 
currently no plan to allow non-members to register URNs. There is also no plan to allow BBF 
members to register URNs for their own use (creating a BBF document requires interest and 
participation from at least 3 different companies). Would it be appropriate to say "BBF 
procedures for URN assignment are noted at [BBF-RESOURCES] 
" and on that page explain that URN 
assignment requires BBF membership and going through the BBF project and document processes?

Thanks again,
Barbara



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

[Gen-art] Assignments for the 2016-11-03 Telechat

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC endDraft
-
Brian Carpenter   16-11-03  draft-ietf-netmod-routing-cfg-24 **

Christer Holmberg 16-10-17  draft-ietf-netconf-yang-patch-12

Dale Worley   16-09-22  draft-harkins-salted-eap-pwd-07 **

Francis Dupont16-10-10  draft-murchison-nntp-compress-06 *

Matt Miller   16-10-25  draft-ietf-p2psip-share-09

Meral Shirazipour 16-10-25  draft-ietf-httpauth-mutual-10 **

Orit Levin16-10-25  draft-ietf-httpauth-mutual-algo-06

Paul Kyzivat  16-10-28  draft-ietf-l2tpext-keyed-ipv6-tunnel-07 **

Ralph Droms   16-10-06  draft-ietf-stox-7248bis-13 *
Ralph Droms   16-11-01  draft-ietf-stir-certificates-10

Roni Even 16-11-01  draft-ietf-stir-passport-09 **

Vijay Gurbani 16-11-01  draft-ietf-stir-rfc4474bis-14

* 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

.

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

[Gen-art] A *new* batch of IETF LC reviews - 2016-10-27

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC end  Draft
-

Dale Worley   2016-11-09  draft-ietf-justfont-toplevel-03

Dan Romascanu 2016-11-27  draft-ietf-siprec-callflows-07

Francis Dupont2016-11-23  draft-holmberg-dispatch-received-realm-08

Joel Halpern  2016-11-10  draft-ietf-dnsop-resolver-priming-09


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 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] Review: draft-bbf-bbf-urn-02

[STARK, BARBARA H]

Hi Joel,

> Major issues:
>  RFC 3406 states that the namespace considerations section should indicate
> why a new namespace is needed.  While this is pretty obvious, the text does
> not actually say anything in that section to explain it.
>  In particular, I would expect that section to explain why 3 NIDs are 
> needed
> rather than just 1.

Thanks for the comments. I propose adding the following text at the end of 
Namespace Considerations (the mention of the name change is part of a proposal 
to resolve a separate comment asking how "dslforum-org" relates to BBF):
   Three NIDs are defined. The "broadband-forum-org" and "dslforum-org" 
   (Broadband Forum changed its name from DSL Forum in 2008) NIDs have 
   been used for many years by BBF without formal registration. As they are 
   referenced by multiple BBF specifications currently in common use, BBF is 
   requesting to formalize them. The new "bbf" NID will be used for new work 
efforts.

> Minor issues:
>  The template in RFC 3406 indicates the the section in each NID on the
> Process of identifier assignment should "detail the mechanism and or
> authorities for assigning URNs to resources."  The draft simply says that the
> BBF will provide procedures.  Do those procedures exist?  If not, there seems
> to be a minor problem.  If they do exist, it would seem sensible to include a
> pointer to the place where the BBF publicly documents those procedures, so
> that people using this information who might want to register something can
> understand what the rules and expectations are. (I realize that the RFC 6289
> example this is based on did not include such a pointer, which is why I am
> making this a minor comment instead of a major one.)

I'm struggling a bit with this one in trying to figure out what's the best 
thing to say here. At this point in time, URN assignments only happen through 
creation of a BBF document that identifies the URN. BBF processes for document 
creation are published on the members-only part of the website, and only BBF 
members can participate in creating a BBF document. There is currently no plan 
to allow non-members to register URNs. There is also no plan to allow BBF 
members to register URNs for their own use (creating a BBF document requires 
interest and participation from at least 3 different companies). Would it be 
appropriate to say "BBF procedures for URN assignment are noted at 
[BBF-RESOURCES] " and on that page 
explain that URN assignment requires BBF membership and going through the BBF 
project and document processes?

Thanks again,
Barbara

___
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-netconf-yang-patch-12

[Mahesh Jethanandani]

Thanks Christer.

Mahesh Jethanandani
mjethanand...@gmail.com

> On Oct 27, 2016, at 5:38 AM, Christer Holmberg 
>  wrote:
> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> .
> 
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> Document: draft-ietf-netconf-yang-patch-12
> Reviewer: Christer Holmberg
> 
> Review Date:  26 October 2016
> IETF LC End Date: 17 October 2016
> IESG Telechat date:   3 November 2016
> 
> 
> Summary:  The document is well written, and ready for
> publication.
> 
> 
> 
> 
> Major issues:None
> 
> 
> Minor issues:None
> 
> 
> 
> Nits/editorial comments: None
> 
> 
> 

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

Re: [Gen-art] Gen-ART review of draft-weis-gdoi-iec62351-9-08

[Jari Arkko]

Thanks for the review!

Jari

On 27 Oct 2016, at 15:11, Vijay K.Gurbani  
wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-weis-gdoi-iec62351-9-08
> Reviewer: Vijay K. Gurbani
> Review Date: Oct-27-2016
> IETF LC End Date: Unknown
> IESG Telechat date: Oct-27-2016
> 
> This document is ready as an Proposed Standard.
> 
> Major: 0
> Minor: 0
> Nits: 1
> 
> Nits:
> 1/ S1.2: Perhaps a ':' or a '-' to delimit the term being defined and
> the definition itself.
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Nokia Networks
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> 
> ___
> 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

[Gen-art] Gen-ART review of draft-weis-gdoi-iec62351-9-08

[Vijay K.Gurbani]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-weis-gdoi-iec62351-9-08
Reviewer: Vijay K. Gurbani
Review Date: Oct-27-2016
IETF LC End Date: Unknown
IESG Telechat date: Oct-27-2016

This document is ready as an Proposed Standard.

Major: 0
Minor: 0
Nits: 1

Nits:
1/ S1.2: Perhaps a ':' or a '-' to delimit the term being defined and
 the definition itself.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

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

[Gen-art] Gen-art LC review of draft-ietf-netconf-yang-patch-12

[Christer Holmberg]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-netconf-yang-patch-12
Reviewer: Christer Holmberg

Review Date:  26 October 2016
IETF LC End Date: 17 October 2016
IESG Telechat date:   3 November 2016

 
Summary:  The document is well written, and ready for
publication.

 
 
 
Major issues:None
 
 
Minor issues:None
 
 
 
Nits/editorial comments: None
 
 

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

[Gen-art] Gen-art LC review of draft-ietf-payload-rtp-ancillary-06

[Christer Holmberg]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Document:draft-ietf-payload-rtp-ancillary-06
Reviewer:Christer Holmberg

Review Date: 26 October 2016
IETF LC End Date:3 November 2016
IETF Telechat Date:  N/A

Summary:

The document is well written, and is almost ready for publication as
standards track RFC. However, I have some issue regarding the SDP sections
(see below).

Major Issues:   None

Minor Issues:  

Q0: Section 3.1:

The text talks about what the presence of DID and SDID means. But, as
they are optional, what does it mean if they are NOT present?


Q1: Section 3.2:

1) I would suggested that the section is renamed to ³SDP
Considerations², and becomes a level 1 section (i.e., ³4 SDP
Considerations²).

2) Is it allowed to carry both a ³normal² video stream and the ANC RTP
payload within the same m= line? If so, how are they related?

Example:

v=0
o=Al 123456 11 IN IP4 host.example.com
s=Professional Networked Media Test
i=A test of synchronized video and ANC data
t=0 0
m=video 5 RTP/AVP 96 97
c=IN IP4 233.252.0.1/255
a=rtpmap:96 raw/9
a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
a=rtpmap:97 smpte291/9
a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}

3) Is it allowed to use two or more ANC RTP payloads (e.g., each using
a different DID_SDID), either within a single m- line, or within different
m- lines? If so, how are they related?

4) When I indicate DID_SDID, it is something I intend to SEND, or
something I am willing to RECEIVE?

5) If multiple DID_SDIDs are listed, can they be used in any order
during the session? If so, it would be good to explicitly indicate that,
and note that the same payload type value will be used for all of them.

6) Is there a possibility that the receiver does not understand
DID_SDID, or specific DID_SDID values? If so, what shall it do?



Q2: Section 3.2.1:

   The text says:

   "The ANC RTP payload format will often be used in groupings with
   associated video streams.  Any legal SDP grouping mechanism could be
   used."

   1) What is meant by the second sentence (³any legal SDP grouping²)?
Isn¹t the semantic depending on the type of grouping?

   2) What if the SDP group contains two (or more) video m= lines. Is the
ANC RTP payload then associated with all of them?

   3) Could you rename the section title to "Grouping ANC Streams with
Video Streams²?



Q3: Section 3.3:

   1) You should say something about updating the parameters in a
sub-sequent offer (or within an answer to an sub-sequent offer). Are there
any restrictions?

   2) What does it mean if one sends a sub-sequent offer/answer without
some/all parameters. Does it mean they are disabled?

   3) Is it allowed to include ANC RTP in an answer if the offer doesn¹t
contain it?

   4) Is is allowed to include DID_SDID in an answer if not included in
the offer?

   5) Can the DID_SDID values in the answer be different than the ones in
the offer, or are there any restrictions?




Editorial Issues:   None



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

Re: [Gen-art] review of draft-ietf-roll-routing-dispatch-03.txt

[Pascal Thubert (pthubert)]

Dear Francis:

Under Jari 's heavy pressure -  ; )  - , I applied your recommendations and 
published.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-roll-routing-dispatch-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/
Htmlized:   https://tools.ietf.org/html/draft-ietf-roll-routing-dispatch-05
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-routing-dispatch-05

Thanks for your careful review. I need to undertsadn better the attack you are 
referring too. 
Per your suggestion, let us work that out with the sec dir review.

Take care,

Pascal


-Original Message-
From: Francis Dupont [mailto:francis.dup...@fdupont.fr] 
Sent: mercredi 26 octobre 2016 23:48
To: gen-art@ietf.org
Cc: draft-ietf-roll-routing-dispatch@ietf.org
Subject: review of draft-ietf-roll-routing-dispatch-03.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-roll-routing-dispatch-03.txt
Reviewer: Francis Dupont
Review Date: 20161025
IETF LC End Date: 20161019
IESG Telechat date: 20161027

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - 1 page 3: wording:
   to much smaller values than the IPv6 maximum transmission unit (MTU)
   of 1280 bytes.
  this statement doesn't make sense without an extra word as "guaranteed"
  before "IPv6 maximum..."

 - 3.2.2 page 8 and 8 page 25: e.g. -> e.g.,

 - 4.3 page 10: please expand the first occurrence of the DODAG abbrev
  (DODAG is in the RFC-editor abbrev list but is not starred as well known.
   BTW RPL is in the same case but IMHO does not need expansion in the
   Abstract and the intro)

 - 4.3.1 page 10 figure 5: for consistency: Coalesced -> coalesced

 - 4.3.2 page 11: formally the 2 paragraphs beginning by If and Else
  should be indented (ask the RFC Editor to do that)

 - 6.3 page 21: spurious comma in [RFC6550],.

 - 9 page 25: I disagree a bit about decompression to be security neutral
  because an atatcket can use error propagation by a decompressor.
  Now if I understand well there should be a L2 security so attacks
  based on decompression are limited and anyway covered by compression
  RFC (6282)... So I leave this to the security directorate.

 - A.2 page 31: defiend -> defined

 - Authors' Addresses page 35: Please ask the RFC Editor to uniformize
  France/FRANCE case (or put FR :-).

Regards

francis.dup...@fdupont.fr

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

Re: [Gen-art] Gen-ART IETF LC review of draft-ietf-pce-stateful-pce-app-07

[Jari Arkko]

Thanks for the review, Dan!

Jari

On 17 Oct 2016, at 03:51, Zhangxian (Xian)  wrote:

> Dan,
> 
> Thank you for the review. Happy to see no changes needed, J.
> 
> Regards,
> Xian
> 
> 发件人: Dan Romascanu [mailto:droma...@gmail.com]
> 发送时间: 2016年10月16日 17:22
> 收件人: gen-art@ietf.org; draft-ietf-pce-stateful-pce-app@tools.ietf.org
> 主题: Gen-ART IETF LC review of draft-ietf-pce-stateful-pce-app-07
> 
> 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-pce-stateful-pce-app-07
> Reviewer: Dan Romascanu
> Review Date: 10/16/16
> IETF LC End Date: 10/17/16
> IESG Telechat date: 10/27/16
> 
> Summary:
> 
> Ready
> 
>The document describes how a stateful PCE can be used to solve
>various problems for MPLS-TE and GMPLS networks, and the benefits it
>brings to such deployments.
> It is very well written, with solid and detailed argumentation. I find this 
> category of documents very useful both for operators to select their options 
> in their current deployments, as well as for protocol developers to 
> prioritize extensions and future new developments. Congratulations and thanks 
> to the authors.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> ___
> 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

[Gen-art] Gen-ART LC review of draft-ietf-stir-passport-09

[Roni Even]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments you
may receive.

Document:  draft-ietf-stir-passport-09

Reviewer: Roni Even

Review Date:2016-10-27

IETF LC End Date: 2016-11-1

IESG Telechat date:  2016-11-3

 

Summary: This draft is ready for publication as a standard track RFC.

 

 

Major issues:

 

Minor issues:

 

Nits/editorial comments:

I noticed that the in the IANA section the security consideration for the
passport subtype reference RFC7515 yet the security section (10) of this
document does not mention RFC7515. Why is that?

 

 

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