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:[email protected]] Sent: June-20-12 15:24 To: Meral Shirazipour Cc: [email protected]; [email protected]; 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 <[email protected]> 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. > - 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 ? ) > 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 [email protected] > Thanks, > Meral > > --- > Meral Shirazipour > Ericsson > Research > www.ericsson.com _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
