Hi Meral, On Wed, Jun 20, 2012 at 4:32 PM, Meral Shirazipour <meral.shirazip...@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:d3e...@gmail.com] > Sent: June-20-12 15:24 > To: Meral Shirazipour > Cc: draft-ietf-trill-clear-correct....@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.shirazip...@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 d3e...@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 > d3e...@gmail.com > >> Thanks, >> Meral >> >> --- >> Meral Shirazipour >> Ericsson >> Research >> www.ericsson.com _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
