[Gen-art] Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04

Ben Campbell <ben@nostrum.com> Thu, 31 May 2012 22:08 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717CE21F866B; Thu, 31 May 2012 15:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.45
X-Spam-Level:
X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tq+XpNl1WUY; Thu, 31 May 2012 15:08:16 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A0F9B21F8665; Thu, 31 May 2012 15:08:16 -0700 (PDT)
Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4VM8FgH004192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 17:08:15 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 31 May 2012 17:08:14 -0500
Message-Id: <8A72CDEF-BC47-4385-A6E3-B5F4474FC70F@nostrum.com>
To: draft-ietf-trill-rbridge-extension.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, The IETF <ietf@ietf.org>
Subject: [Gen-art] Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2012 22:08:17 -0000

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-trill-rbridge-extension-04
Reviewer: Ben Campbell
Review Date: 2012-05-31
IETF LC End Date: 2012-06-07
IESG Telechat date: 2012-06-07

Note: Since this draft is on the agenda of the IESG Telechat on the same day that the IETF last call expires, this review is intended for both purposes.

Summary: 

This draft is almost ready for publication as a proposed standard, but I have some clarification questions and comments that should be considered prior to publication.

Major issues:

None

Minor issues:

-- section 2, general:

Do the authors assume that all TRILL extensions will follow this spec? Since RFC6325 already specifies an extension mechanism, what stops an extension from ignoring this spec and doing something different? Does it hurt if they do?

-- section 2, 3rd paragraph from end: "Non-critical extensions can be safely ignored."

Is that intended to be normative? (Seems like it should be, since behavior for critical extensions is normative).

-- section 2.1, 1st paragraph, last sentence:

Redundant with normative language in previous section.


-- section 2.3, first paragraph: 

Is the first sentence intended as normative?

-- section 6, last paragraph:

No security implications of this are mentioned. Is it really a security consideration?

Also, is this more likely to be set incorrectly than all the other things that some implementation might screw up, so that it warrants special treatment?


Nits/editorial comments:

-- section 1: 

Please expand TRILL on first mention in the body of the document (i.e. not just in the Abstract.)

-- section 2:

Please expand RBridge and IS-IS on first mention.

-- section 2, bullet list, 2nd bullet: " ... which would only necessarily affect the RBridge(s) where a TRILL frame is decapsulated"

Does that mean it always affects the decapsulating RBridge but might effect transit RBridges as well? 

-- section 2, first paragraph after bullet list: "critical hop-by-hop extension"

I assume this means an extension with the critical flag set? If so, it would be more precise to say that.

-- sectio 2.1, 1st paragraph:

I'm a little confused by a citation for "future documents". Do you mean the cited document as an example of something that might do this (in which case a "for example" would help), or do you mean to say that document will do this?

-- section 2.2, 1st paragraph:

Please expand PDU on first mention.

-- section 2.3, first paragraph: 

s/modifictions/modifications

-- section 5:

Since section 3 is entirely composed of the referenced table, and seems to exist mostly if not entirely for the purpose of this reference, why not just move the table to the IANA considerations section.