Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-clear-correct-03.txt

Donald Eastlake <d3e3e3@gmail.com> Fri, 22 June 2012 00:30 UTC

Return-Path: <d3e3e3@gmail.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 250B511E8091 for <gen-art@ietfa.amsl.com>; Thu, 21 Jun 2012 17:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.509
X-Spam-Level:
X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 3yc9Cu9824Af for <gen-art@ietfa.amsl.com>; Thu, 21 Jun 2012 17:30:29 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7363A11E80A1 for <gen-art@ietf.org>; Thu, 21 Jun 2012 17:30:29 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1235809ghb.31 for <gen-art@ietf.org>; Thu, 21 Jun 2012 17:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jXbom7BtqOv7GxySMvrZ1zEuqUVIvY9kepje9EWh6Lw=; b=SLXm2QYiyCBMxZ551qYpsLxGqmDDsn3t5ZZnOrzN4J2FG+kR+ZAq5WulSEcLDS84ix 6dKhK7WUoiP+OoMoJ5gqNxTO9Q/ACJ3aJ//DjzPtx6OkHETzoh0JA7RhPJgK9ACFsSHP wsrGTgdw7U4QpRESPBTw29YvtwvEpoq2VqLCIwg9HhFFpZTzutFguP4QyrO/++00vz4N 8hIxpUysrr8FES9WfKv6k8Uu8WvTnv8gyRObsZ1p1ysaObDr4IGpm9pHwPrzvtwn/fGR uvAUTOPJT5W/xh5JekAhuqdUpV9V/a+izYNU61vE5RqiVMapwKNsQM1nwau00BUbO1Yt MnUA==
Received: by 10.50.34.200 with SMTP id b8mr158143igj.50.1340325028864; Thu, 21 Jun 2012 17:30:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.16.227 with HTTP; Thu, 21 Jun 2012 17:30:08 -0700 (PDT)
In-Reply-To: <25DC600D0CC1F2479C7053ADEB93004E699DB9D54C@EUSAACMS0703.eamcs.ericsson.se>
References: <25DC600D0CC1F2479C7053ADEB93004E699DAFB0A7@EUSAACMS0703.eamcs.ericsson.se> <CAF4+nEH3XmK=b0nN8Pcozc_6LB2vxajJ6OM4t7VvZ1Q-Fx13hQ@mail.gmail.com> <CAF4+nEEr7Ys4rZt7Ja97ygzy3bQwQ7J6ap2QW90rfi36Xv=X-w@mail.gmail.com> <25DC600D0CC1F2479C7053ADEB93004E699DB9D54C@EUSAACMS0703.eamcs.ericsson.se>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 21 Jun 2012 20:30:08 -0400
Message-ID: <CAF4+nEH=k8BMB+FtJr2gpUXPYoQVcuVFOsak5M7qwwbrBnWzGg@mail.gmail.com>
To: Meral Shirazipour <meral.shirazipour@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-trill-clear-correct.all@tools.ietf.org" <draft-ietf-trill-clear-correct.all@tools.ietf.org>, Ayan Banerjee <ayabaner@gmail.com>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-clear-correct-03.txt
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: Fri, 22 Jun 2012 00:30:31 -0000

Hi Meral,

On Wed, Jun 20, 2012 at 4:32 PM, Meral Shirazipour
<meral.shirazipour@ericsson.com> wrote:
> Hi Donald,
>   Thank you for considering the comments. Please see below.
>
> Best Regards,
> Meral
>
> ---
> Meral Shirazipour
> Ericsson
> Research
> www.ericsson.com
>
>
> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> Sent: June-20-12 15:24
> To: Meral Shirazipour
> Cc: draft-ietf-trill-clear-correct.all@tools.ietf.org; gen-art@ietf.org; Ayan Banerjee
> Subject: Fwd: Gen-ART Last Call review of draft-ietf-trill-clear-correct-03.txt
>
> Hi Meral,
>
> A real response this time...
>
> Thanks for your thorough review. See below:
>
> On Tue, Jun 19, 2012 at 11:51 AM, Meral Shirazipour <meral.shirazipour@ericsson.com> wrote:
>> I am the assigned Gen-ART reviewer for
>> draft-ietf-trill-clear-correct-03.txt. For background on Gen-ART,
>> please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>>
>> Document: draft-ietf-trill-clear-correct-03
>> Reviewer: Meral Shirazipour
>> Review Date: June-18-2012
>> IETF LC End Date: June-20-2012
>> IESG Telechat date: June-21-2012
>>
>>
>> Summary:
>> The document is ready for publication as a standards track RFC,
>> however I have a few comments.
>
> Thanks.
>
>> Minor issues:
>>
>> TRILL-PORT-VER sub-TLV should be "PORT-TRILL-VER" sub-TLV.(there are a
>> few
>> occurrences)
>
> Yes, thanks for spotting that.
>
>> Nits/editorial comments:
>>
>> - Suggestion: [Page 6], line 2, spell out first occurrence LSP
>
> OK.
>
>> - Suggestion: [Page 6], line 5, "overload bit on" ----> "overload bit set"
>
> OK.
>
>> - Clarification:[Page 6], Section 2.1, line 5, add a comma "," after
>> "traffic engineered frames"
>
> OK.
>
>> - Typo:[Page 6], last word, "contain" --missing s--> "contains"
>
> I believe the current wording is correct.
>
> [msh] sorry about that.
>
>> - Suggestion: [Page 7], Section 2.2, line 2, spell out first
>> occurrence of "Reverse Path Forwarding Check" and then use "RPFC" in
>> the rest of the document.
>
> It depends a little on the context but  agree that most can be changed to RPFC.
> [msh] ok
>
>> - Clarification:[Page 10], Section 2.4.2.3, line 5, sentence starting
>> with
>> "RB2 MUST advertise ...": we could omit the second occurrence of "it
>> might use" in that sentence.
>
> OK.
>
>> - Clarification:[Page 10], Section 2.4.2.3, 3rd line from last, "end
>> stations connected to RB": "a RB" or "RBs"?
>
> Should be "end stations connected to RB3".
>
> [msh] ok
>
>> - Typo: [Page 11], Section 3.1,"( j, k)" --remove extra space--> "(j, k)"
>
> OK.
>
>> - Suggestion: [Page 11], Section 3.2, "already in flight" ---->
>> "already in transmission"
>
> I think the current wording is better.
>
> [msh] ok
>
>> - Typo [Page 12]:"many multi-destination frame"--missing s--> "many
>> multi-destination frames"
>
> OK.
>
>> - Clarification:[Page 13], Point 4. , Sentence 2: suggested clarification:
>>
>> "It does so by checking LSPs it receives and updating its link state
>> database for any of its nicknames held with higher priority by another
>> TRILL Switch that is IS-IS reachable."
>
> I have no problem dropping "in" so it says "...checking LSPs..."
> rather than "...checking in LSPs..." but I think the rest of the change you suggest makes it slightly wrong and so would prefer to keep the rest of the wording of that sentence.
>
> [msh] In this case I think keeping the "in" is actually better. I understand the sentence but had to read it a few times.

OK.

>> - Typo [Page 14]:"unicast Channel message"--missing s-->"unicast
>> Channel messages"
>
> OK.
>
>> - Typo [Page 16]: Section 5.2,"Routeing" ----> "Routing"
>
> The spelling used in the ISO 10589:2002 standard's title and the naming of this field therein includes the "e".
>
> [msh] ok
>
>> - Suggestion:[Page 16],last sentence, suggestion: "This safety margin
>> is called "Margin" below."
>
> OK.
>
>> - Typo [Page 18]:"a specified in [RFC6325]"--missing s-->"as specified
>> in [RFC6325]"
>
> OK.
>
>> - Suggestion: [Page 19], spell out first occurrence of EISS
>
> OK.
>
>> - Suggestion:[Page 21], Point 1, not clear what the new text becomes.
>> Suggestion: refer to last paragraph of section 3.1 instead of
>> paragraph before 3.2, and propose the new sentence.
>
> OK.
>
>> - Clarification:[Page 21], Point 2, it is not clear what the change is
>> to section 3.2 of RFC6327.
>
> OK.
>
>> - Clarification:[Page 21], Point 3, it would be clearer to say "bullet
>> A9 is added" (if this is an event like the rest of the bullets in
>> section 3.3 of
>> RFC6327)
>
> Guess this does need clarification as its not an event, its a "o ..." type bullet item "after the list of events". I'll clarify.
>
> [msh]ok
>
>> - Clarification:[Page 22], section 10.1,"disagreement over the
>> Designated VLAN or the like". Suggestion: replace the term "or the
>> like" with other examples or remove the term.
>
> How about replacing "... in the face of partitioned VLANs or disagreement over the Designated VLAN or the like in a link." with "... in the face of decreased VLAN connectivity in a link such as partitioned VLANs, many VLANs disabled on ports, or disagreement over the Designated VLAN."
>
> [msh] ok
>
>> -Typo: [Page 22], section 10.1, "each others frames"---->"each other's
>> frames"
>
> OK.
>
>> -Typo: [Page 24], "DRB SHOULD NOT appointed"---->"DRB SHOULD NOT
>> appoint", "an VLAN"---->"a VLAN", "RBridged"---->"RBridge"
>
> OK.
>
>> -Clarification:[Page 25], Section 11, Point 1, "The previously
>> reserved", reference to document.
>
> OK. The block of nicknames from 0xFFC0 through 0xFFFE is reserved by the TRILL base protocol document [RFC6325].
>
>> - Clarification: [page 19/page 27], Informative References, reference
>> [802], to verify which standard we want to refer to for Canonical Format Indicator:
>>
>> If it is "IEEE Std 802-2001: IEEE Standard for Local and Metropolitan
>> Area
>> Networks: Overview and Architecture", then the date should be 7
>> February 2001."
>
> All copies I have seen clearly say 8 March 2001 on the cover.
>
> [msh] ok, since the reference is only for a definition. I made a typo too, it is 7 Feb 2002 that I saw-maybe I looked at the wrong document: http://standards.ieee.org/about/get/802/802.html ? )

Well, I went back and double checked... And the actual cover date of
the copy I have, which was the one distributed to IEEE 802 members via
the annual CD of all 802 standards, says 8 March 2002, which is what
it actually says in the draft, not 2001 as I typed above. Anyway, I'm
going to leave it as is for now.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

>> However this specific document does not define CIF. You may want to
>> refer to 802.1Q-2005.
> [Should be CFI above.]
>
> [msh] ok
>
> While "IEEE Std 802-2001: IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture" does not define the acronym CFI, it does define "canonical format" and "noncanonical format".
> There is no IEEE Std 802.1Q-2005 any more, it having been replaced by IEEE Std 802.1Q-2011 which does not define the acronym CFI. Doing some searches, although 802.1Q-2011 replaces the CFI bit in Customer VLAN tags with the DEI bit, there are a few occurrences of "canonical" left in 802.1Q-2011, most to say that bridges conformant to 802.1Q-2011 will interoperate with bridges that believe in the CFI bit as long as those bridges don't actually have any Token Ring interfaces so they will always set the CF bit to zero. Quoting from page 3 of
> 802.1Q-2011: "The meanings of the terms Canonical format and Noncanonical format are discussed in IEEE Std 802.".
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
>
>> Thanks,
>> Meral
>>
>> ---
>> Meral Shirazipour
>> Ericsson
>> Research
>> www.ericsson.com