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

[Donald Eastlake <[e-mail]>]

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
<[e-mail]> 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.

> - 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.

> - 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".

> - 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.

> - 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.

> - 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".

> - 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.

> - 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."

> -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.

> However this specific document does not define CIF. You may want to refer to
> 802.1Q-2005.
[Should be CFI above.]

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thanks,
> Meral
>
> ---
> Meral Shirazipour
> Ericsson
> Research
> www.ericsson.com