Peter Yee | 6 May 08:29 2016

A *new* batch of IETF LC reviews - 2016-05-05

Hi all,

The following reviewers have assignments:

Reviewer          LC date     Draft
---------------------------------------------------------------------
Christer Holmberg 2016-05-12   draft-ietf-dime-e2e-sec-req-04

Dale Worley       2016-05-12   draft-ietf-netmod-rfc6020bis-12 (also on the
05-19 telechat)

Dan Romascanu     2016-05-19   draft-ietf-rtgwg-bgp-routing-large-dc-10 ***

Elwyn Davies      2016-05-16   draft-ietf-manet-rfc6779bis-05

Fernando Gont     2016-05-26   draft-hardie-rfc6455-iana-clarification-02

Jouni Korhonen    2016-05-12
draft-ietf-cdni-footprint-capabilities-semantics-18 ** (also on the 05-19
telechat)

** Previous version reviewed
*** No last call apparent, going directly to telechat on 05-19

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

Jari Arkko | 5 May 12:10 2016
Picon

Re: Gen-ART Telechat review of draft-ietf-bfd-seamless-use-case-06

Thanks for the review, Dale, and thanks authors for the edits!

Jari

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Meral Shirazipour | 5 May 08:01 2016
Picon

Gen-ART Telechat Call review of draft-holmberg-dispatch-pani-abnf-03

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-holmberg-dispatch-pani-abnf-03

Reviewer: Meral Shirazipour

Review Date: 2016-05-04

IETF LC End Date: 2016-02-11

IESG Telechat date: 2016-05-05

 

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

 

 

Major issues:

Minor issues:

Nits/editorial comments:

 

 

 

 

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
Jari Arkko | 4 May 22:49 2016
Picon

Re: Gen-ART review of draft-ietf-roll-applicability-ami-12

Thanks for your review, Christer!

Jari

On 29 Apr 2016, at 05:57, Christer Holmberg <christer.holmberg <at> ericsson.com> wrote:

> Hi,
> 
> Please see my follow-up e-mail. It shall be standards track.
> 
> Sorry for the mess :)
> 
> Regards,
> 
> Christer
> 
> 
> On 29/04/16 12:53, "peter van der Stok" <stokcons <at> xs4all.nl> wrote:
> 
>> Hi Christer,
>> 
>> thanks for the review.
>> Do you propose to change the standards track objective to informational?
>> 
>> Peter
>> 
>> Christer Holmberg schreef op 2016-04-29 11:48:
>>> 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 [1]>
>>> 
>>> Document:                         draft-ietf-roll-applicability-ami-12
>>> 
>>> 
>>> Reviewer:                           Christer Holmberg
>>> 
>>> Review Date:                         29 April 2016
>>> 
>>> IETF LC End Date:                 12 April 2016
>>> 
>>> IETF Telechat Date:              5 May 2016
>>> 
>>> Summary:                              The document is well written,
>>> and ready for publication is informational RFC.
>>> 
>>> Major Issues:                        None
>>> 
>>> Minor Issues:                        None
>>> 
>>> Editorial Issues:                    None
>>> 
>>> Links:
>>> ------
>>> [1] http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art <at> ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Francis Dupont | 4 May 15:51 2016
Picon

review of draft-ietf-i2rs-pub-sub-requirements-06.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-i2rs-pub-sub-requirements-06.txt
Reviewer: Francis Dupont
Review Date: 20160429
IETF LC End Date: 20160429
IESG Telechat date: 20160505

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - Abstract page 1, 4.1 page 7 and 4.2.2 page 9: i.e. -> i.e.,

 - ToC page 2 and 2.2 page 5: variants -> Variants

 - ToC page 2 and 7 page 14: Acknowledgements -> Acknowledgments

 - 2.2 page 5: software[sacm-requirements] -> software [sacm-requirements]

Regards

Francis.Dupont <at> fdupont.fr
Romascanu, Dan (Dan | 4 May 12:46 2016

Geb-ART Telechat review of draft-ietf-bfd-seamless-ip-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-ietf-bfd-seamless-ip-04

Reviewer: Dan Romascanu

Review Date: 2016/5/4

IETF LC End Date: 2016/4/12

IESG Telechat date: 2016/5/5

 

Summary: Ready with one issue

 

The document is well written and complete, but requires a good understanding of BFD (RFC 5880, RFC 5881) and of the use-cases (draft-ietf-bfd-seamless-use-case) document.

 

In my initial review I raised two issues. One was accepted and an editorial change was made in draft-04. The second one was:

 

-          This document extends the usage of port 3785 adding the function of being the destination port for the S-BFD echo packets. Should not this be regarded as an update of RFC 5881 and mentioned as such on the front page? 

 

The authors answered the following:

 

-          I do not have a strong opinion one way or another — I will leave this one to the AD’s guidance, and I am happy to mark this document as updating RFC 5881 if that’s the preferred direction

 

No change was made. I would like to make sure that the responsible AD has seen this comment. It’s not a show-stopper, but I still believe that marking this document as an update to RFC 5881 is better.

 

Major issues:

 

Minor issues:

 

Nits/editorial comments:

 

 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Elwyn Davies | 4 May 10:43 2016

Late comment on draft-ietf-bfd-seamless-ip-04

Hi.

While reviewing draft-ietf-l2tpext-sbfd-discriminator-05 for gen-art, I 
came across a
  'common mode' issue with multiple discriminators that lead me to check 
the various other seamless BFD drafts.

In the process I noticed the last paragraph in Section 5.1.1 of 
draft-ietf-bfd-seamless-ip-04 contained the following text:
>     This also requires S-BFD control packets not be dropped by the
>     responder node due to TTL expiry.  Thus implementations on the
>     responder MUST allow received S-BFD control packets taking TTL expiry
>     exception path to reach corresponding reflector BFD session.
This struck me as out of line with (AFAICS) every existing IP 
implementation. TTL expiry checking is typically deep in the stack and 
making an exception for this one case is (IMO) likely to be problematic. 
It may even be a security issue. Have I misunderstood what is going on here?

Regards,
Elwyn
Peter Yee | 3 May 23:02 2016

Gen-ART Telechat review of draft-ietf-isis-node-admin-tag-10

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

Document: draft-ietf-isis-node-admin-tag-10
Reviewer: Peter Yee
Review Date: May 3, 2016
IETF LC End Date: April 29, 2016
IESG Telechat date: May 5, 2016

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has an issue and some nits that should be fixed/considered before
publication. [Ready with issues]

This draft defines a means to carry additional per-node administrative tags
with the IS-IS protocol.  These tags can be used along with local policy to
simplify the management of routing and path selection.  This specification
gives informative examples of such tag usage but does not otherwise
prescribe the meaning of the tags.

Major issues: None

Minor issues:

Page 5, section 4.2, 2nd paragraph, 1st sentence: The sentence states:
"Being part of the Router CAPABILITY TLV, the node administrative tag
sub-TLV MUST be reasonably small and stable."  If you're going to make this
a MUST, you've got to at least give a definition of "reasonably small" and
perhaps even "stable" in the context of this specification.  As it stands,
there's no test for whether the MUST is enforceable or understandable
between parties.

Nits:

General:

The use of capitalization of Node administrative tag varies throughout the
document.  It seems clear that you mean for it to be written as "Node
Administrative Tag" when referring to the name of sub-TLV.  For other uses,
I would suggest using "node administrative tag" (all lower case)
consistently.  Use that to replace "Node administrative tag".

Specific:

 Page 3, 1st paragraph after the labeled items at the top, 3rd sentence:
change the first "TLV" to "sub-TLV".

Page 3, Section 2, 2nd paragraph: append a comma after "another".

Page 3, Section 3, 1st paragraph, 1st sentence: change "a" before "IS-IS" to
"an".

Page 3, Section 3, 1st paragraph, 2nd sentence: change "Capablity" to
"CAPABILITY".

Page 3, Section 3, 1st paragraph, 3rd sentence: change "Operator" to "An
operator".  Change "diiferent" to "different".

Page 3, Section 3, 2nd paragraph, 1st sentence: insert "the" before "Node".

Page 3, Section 3, 2nd paragraph, 2nd sentence: change "topology specific"
to "topology-specific".  (That is to say, swap the space for a hyphen.)

Page 4, Section 3.1, Value definition: insert "node" before
"administrative".

Page 4, Section 4.1, 1st sentence: change "Node" to "node".  (See general
nit.)

Page 4, Section 4.1, 3rd sentence: delete the space after the slash and
before regulations.

Page 5, 3rd full paragraph, 4th sentence: delete the spaces after closing
parenthesis and the terminating period.

Page 6, Section 4.3, 1st paragraph, 2nd sentence: change "Node" to "node".
(See general nit.)  Change the first "TLVs" to "sub-TLVs".

Page 6, Section 4.3, 2nd paragraph, 2nd sentence: delete the space before
the comma.

Page 6, Section 5, 1st paragraph, 1st sentence: change "Node" to "node".
(See general nit.)

Page 6, Section 5, 1st paragraph, 4th sentence: change "Following" to "The
following".

Page 6, Section 5, 1st paragraph, 5th sentence: change "section-3" to
"section 3".

Page 7, Section 6, 2nd paragraph, the comma should be rejoined with the
closing parenthesis.

Page 7, Section 7, 1st paragraph, 3rd sentence: change "is" to "are".

Page 7, Section 8, 1st paragraph, 2nd sentence: delete "The" before "YANG".
With the change in the rest of the sentence, "The" becomes superfluous.

Page 8, Section 9: change "Capabality" to "CAPABILITY".
Alvaro Retana (aretana | 1 May 02:23 2016
Picon

Re: Gen-ART Last Call review of draft-ietf-idr-add-paths-13

On 4/28/16, 4:24 PM, "Meral Shirazipour" <meral.shirazipour <at> ericsson.com> wrote:

Meral:

Hi!

Thank you for your review!

I just posted version –14.

Thanks!

Alvaro.


<!-- /* Font Definitions */ <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} -->

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-idr-add-paths-13

Reviewer: Meral Shirazipour

Review Date: 2016-04-28

IETF LC End Date: 2016-04-29

IESG Telechat date: 2016-05-05

 

 

Summary:

This draft is ready to be published as Standards Track RFC but I have some comments.

 

Major issues:

 

Minor issues:

-[Page 2] The introduction should give a hint of why this extension is necessary. Section 6 (Application) is pretty much empty in content too.

It would be important to add a few lines explaining the use cases and if any draft is started on those to give a pointer to them.

*An "Add-Paths Applications" section would be useful like the one in draft-ietf-idr-add-paths-guidelines-08.

 

 

-[Page 3],

"A BGP

   speaker that receives a route SHOULD NOT assume that the identifier

   carries any particular semantics; it SHOULD be treated as an opaque

   value.

"

*It would be good to justify why this restriction is imposed. If someone is using BGP add-Path internally, why prevent giving some semantics to the encoding?

 

 

-[Page 6], security section refers to Information guideline draft (draft-ietf-idr-add-paths-guidelines-08).

Is this draft also for IBGP only ? this was not clear.

 

 

Nits/editorial comments:

-[Page 7], References should be updated to newer versions.

 

 

 

 

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 | 30 Apr 10:41 2016

Gen-ART LC review of draft-ietf-isis-node-admin-tag-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
comment.  For background on Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-isis-node-admin-tag-08
Reviewer: Peter Yee
Review Date: April 27, 2016
IETF LC End Date: April 29, 2016
IESG Telechat date: May 5, 2016

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has some issues that should be fixed/considered before publication.
[Ready with issues]

This draft defines a means to carry additional per-node administrative tags
with the IS-IS protocol.  These tags can be used along with local policy to
simplify the management of routing and path selection.  This specification
gives informative examples of such tag usage but does not otherwise
prescribe the meaning of the tags.

This review was generated prior to the release of draft -09 (but not keyed
in until April 29th), but many of the issues and nits noted below remain in
draft -09.  Obviously, some of my comments no longer apply.  I'll address
draft -09 specifically for the telechat review, but you should look at the
points here prior to that review to save time.  Given that draft -09
substantially reduces Section 5, I've removed my comments regarding that
section as well as in a few other places.

Major issues: None

Minor issues:

Page 4, last partial paragraph: the number 63 is given for the maximum
number of per-node administrative tags that can be carried in a sub-TLV.
Given the maximum length of a sub-TLV is 250 octets (and 2 octets are
otherwise used by type and length), I would argue that the correct number
here is 62 (62*4 = 248).  Also, I would delete the text starting at "and".
In all cases, when more than 62 tags are used, a single sub-TLV will not
provide sufficient space.

Page 5, 1st partial paragraph, 1st full sentence: Sub-TLV values are given
here as cumulative.  Is there any need or desire to be able to subtract
tags?  How would a router disassociate itself from a tag that was no longer
relevant to the router?  This ability is implied in Section 4.3, 2nd
paragraph, but that conflicts with the statement given here.  In general, I
believe the ability to reset the flooded tags associated with a router or to
delete a tag is underspecified.

Page 6, 1st partial paragraph, 1st sentence: Care to define "reasonably
small"?  Previously, the ability to send more than 63 (or perhaps 62, see
above) tags was specified in section 3.1.  What's the limit to
reasonableness?  (Not that an exact number seems to matter at all for the
purposes of this specification, which is agnostic to the specific number or
the use of the tags.)

Page 6, Section 4.3, 2nd paragraph: This paragraph implies that a large set
(greater than 62 at least) of sub-TLVs will have to be sent in multiple
Router CAPABILITY TLVs and those TLVs must(?) occur in a single Link-State
PDU.  Or how is the receiving router to know that it has the complete set of
tags?  Also, the implication seems to be that while section 3.1 indicates a
strictly cumulative capability, there must be someway of terminating those
cumulative changes and allowing a reset.  What is that signaling mechanism?

Nits:

General:

The use of capitalization of Per-node administrative tag varies throughout
the document.  It seems clear that you mean for it to be written as
"Per-node Administrative Tag" when referring to the name of sub-TLV.  For
other uses, I would suggest using "per-node administrative tag"
consistently.  Use that to replace "Per-node administrative tag".

Separate parenthetical elements from the preceding and following words with
a space.  These aren't function calls. ;-)

Replace any use of "per-node admin tag" with "per-node administrative tag".
The shortening is fine for the document header which would otherwise become
unreadable.

And change all of my references to "per-node" to "node", since draft -09
drops the "per-". :-)

Replace "TLV 242" with "the Router CAPABILITY TLV".  

Specific:

 Page 1, Abstract:  delete the first comma in the Abstract.

Page 3, first paragraph after the lettered items, 3rd sentence: insert "the"
before "Router".

Page 3, Section 2, 1st sentence: change "Tag" to "tag".

Page 3, Section 2, 3rd sentence: insert "a" before "certain".

Page  3, Section 3, 1st paragraph, 1st sentence: change "TLV-242" to "TLV
(IS-IS TLV type 242)" and delete the closing parenthesis after "[RFC4971".

Page 3, Section 3, 1st paragraph, 3rd sentence: change "the same" to "it".
Change "they" to "it".  Change "specfied" to "specified".  Insert "the"
before "originating".  Delete "the" before "other".

Page 3, Section 3, 1st paragraph, 5th sentence: change "are" to "is".

Page 3, Section 3, 1st paragraph, 6th sentence: delete the comma.

Page 3, Section 3, 1st paragraph, 7th sentence: change "Operator" to "The
operator".

Page 4, Section 3, last paragraph, 1st sentence: insert "the" before
"Per-node" (after having changed "per-node" to "Per-node").

Page 4, Section 3, last paragraph, 2nd sentence: change "topology specific"
to "topology-specific".

Page 4, Section 3.1, 1st paragraph, 1st sentence: change "ISIS" to "IS-IS".

Page 4, Section 3.1, Length definition: change "A" to "An".

Page 4, Section 3.1, Value definition: change "sequence" to "set".  Sequence
would seem to imply order which is contradicted by Section 4.1.  Change "4
octets" to "4-octet values".

Page 5, 1st partial paragraph, 1st full sentence: append a comma after
"such" and insert "each" before "occurrence".

Page 5, Section 4.1, 1st paragraph, 1st sentence: change "Meaning" to "The
meaning".

Page 5, Section 4.1, 1st paragraph, 2nd sentence: change "Router" to "A
router".

Page 5, Section 4.1, 2nd paragraph, last sentence: append a comma after
"change".

Page 5, Section 4.1, 4th paragraph, 2nd sentence: delete "The".  Change
"TLVs" to "sub-TLVs".  Change "adminsitrative" to "administrative".

Page 5, Section 4.1, 4th paragraph: the paragraph, starting at "The list of
per-node" is pretty much redundant given the admonition in the first
sentence of the previous paragraph.  Perhaps delete it rather than belabor
the point?

Page 5, Section 4.1, 1st paragraph, 4th sentence: change "well known" to
"well-known".  Change "capability" to "CAPABILITY".

Page 6, 1st partial paragraph, 2nd sentence: insert "the" before
"reachability".

Page 6, Section 4.3, 1st paragraph, 1st sentence: delete "(TLV-242)".

Page 6, Section 4.3, 1st paragraph, 3rd sentence: change "an" to "a".  Based
on Section 3.1, I might change "changes" to "adds to" because Section 3.1
specifies that sub-TLVs are cumulative.

Page 10, Section 7, 1st paragraph, 3rd sentence: change "ISIS" to "IS-IS".
Change "is" to "are".  

Page 10, Section 7, 2nd paragraph, 2nd sentence: insert "the" before "case".
Insert "the" before "forwarding".  Insert a space before "and".

Page 12, Section 8, 2nd sentence: insert "The" before "YANG".

Page 12, Section 8, 3rd sentence: insert "The" before "IS-IS".  Insert "the"
before "routing".

Page 12, Section 9, item i): why is the sub-TLV name hyphenated here and not
elsewhere?

Page 12, Section 10: append a comma after "Chunduri".
Mahesh Jethanandani | 30 Apr 00:47 2016
Picon

Re: Gen-ART review of draft-ietf-netconf-yang-library-05

Thanks Vijay.

On Apr 29, 2016, at 7:57 AM, Vijay K. Gurbani <vkg <at> bell-labs.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>.

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

Document: draft-ietf-netconf-yang-library-05
Reviewer: Vijay K. Gurbani
Review Date: Apr-29-2016
IETF LC End Date: Not known
IESG Telechat date: May-05-2016

This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 0

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> nokia.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq



Mahesh Jethanandani





_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Gmane