Re: Gen-ART LC review of draft-ietf-isis-node-admin-tag-08

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Sat, 30 April 2016 09:10 UTC

Return-Path: <pushpasis.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E97112B051; Sat, 30 Apr 2016 02:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShpAqXudY-m4; Sat, 30 Apr 2016 02:10:43 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD2C12B017; Sat, 30 Apr 2016 02:10:43 -0700 (PDT)
Received: by mail-pa0-x22b.google.com with SMTP id bt5so54632106pac.3; Sat, 30 Apr 2016 02:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QG9He10IRV5b9U4UEPty4UZGaiFp6hPd0KgICW4F7Ls=; b=w7R4k1FIauLG5QtQgpbp4mhVpQxc4Q3eUxV2NSXwNVfTO2256hiop+qX1GbQk9A50c iqNJtKqg2IESD/WI5YdmQQCQ/f/OAd7RljDqmQ8/mlpUWV2vkb11dPDUN7GOcnTIKIEk fc2CJgC0x61KVmW4j2hEFTzz3mW5gaQSCO5Z8nXJ5MHLjXxEt1BtPzUuDir50ID5GgUs 4j4fB7CY3QTdWioIh6mwSKF4455BAC6Ou3V1vol8ZHkB7nL1bWEYPReGOL0ySkdcRapa 3nirEicXw6r1kMqNZMMj6pcOfGAucCv/QLZurEfQVQt47KBUlctMT+7bMNOQzUDp2S9N EpoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QG9He10IRV5b9U4UEPty4UZGaiFp6hPd0KgICW4F7Ls=; b=MVF/mVdeYoAmqoLwCNPYaCMDasWDltxZoSY5DKCSTtW6sK+7Aaafzzsv7s9rLWfl3j OGVuOFlI6nD4d4c+1uSFBuWdF8er5+hZ7YzfnmSwDSzNOAd/XFlyZgpnmR1UQg96pnna oWp75qR+CRGH+GIbSOBQixEgPQ6/KWgjrKK7SjQ1WxA4ShTqSQ+6J3d/15tp83RwcAFz 4ffkRo3Qbgp1JhKxSlvTQyI8zW4g6Ti0iG5tfMvcrcjRr+/Eh42TpP4oItfxTKnDwpqW qS3kw4xsQgQa23dr3w1PTf7owPT+j/2DY+9vGc7NpxNThNlU2Tb7/ISHmyJgSFN7wK0M vRww==
X-Gm-Message-State: AOPr4FV8yquB0W4Vt5Af1+k6PeNju0dugCzb4eayib+ORiAy6b2k5M4We4AOmlhTj9Manw==
X-Received: by 10.66.175.110 with SMTP id bz14mr35545105pac.41.1462007442648; Sat, 30 Apr 2016 02:10:42 -0700 (PDT)
Received: from [192.168.1.235] ([103.6.157.63]) by smtp.gmail.com with ESMTPSA id g5sm36648931pac.1.2016.04.30.02.10.40 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Apr 2016 02:10:42 -0700 (PDT)
Subject: Re: Gen-ART LC review of draft-ietf-isis-node-admin-tag-08
To: Peter Yee <peter@akayla.com>, draft-ietf-isis-node-admin-tag.all@ietf.org
References: <00ef01d1a2bc$1e6a0130$5b3e0390$@akayla.com>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Message-ID: <5724768F.9060407@gmail.com>
Date: Sat, 30 Apr 2016 14:40:39 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <00ef01d1a2bc$1e6a0130$5b3e0390$@akayla.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dV6LB_zULsYGCCD62nv16ckiMEs>
Cc: gen-art@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2016 09:10:45 -0000

Hi Peter,

Thanks a lot for the comments. I will address them soon in the next version.

Best Regards,
-Pushpasis

On Saturday 30 April 2016 02:11 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 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".
>