Hi Donald, Ok, thanks for considering the suggestions. BR, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com
> -----Original Message----- > From: Donald Eastlake [mailto:[email protected]] > Sent: June-21-12 20:30 > To: Meral Shirazipour > Cc: [email protected]; [email protected]; Ayan > Banerjee > Subject: Re: Gen-ART Last Call review of draft-ietf-trill-clear-correct-03.txt > > Hi Meral, > > On Wed, Jun 20, 2012 at 4:32 PM, Meral Shirazipour > <[email protected]> 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:[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. > > 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 > [email protected] > > >> 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
