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

[Meral Shirazipour <[e-mail]>]

Hi Donald,
   Ok, thanks for considering the suggestions.

BR,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com



> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: June-21-12 20:30
> To: Meral Shirazipour
> Cc: [e-mail]; [e-mail]; 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
> <[e-mail]> 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:[e-mail]]
> > Sent: June-20-12 15:24
> > To: Meral Shirazipour
> > Cc: [e-mail];
> > [e-mail]; 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
> <[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.
> >
> > [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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
> 
> >> 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   [phone] (cell)
> >  155 Beaver Street, Milford, MA 01757 USA
> >  [e-mail]
> >
> >> Thanks,
> >> Meral
> >>
> >> ---
> >> Meral Shirazipour
> >> Ericsson
> >> Research
> >> www.ericsson.com