Hi Donald, Thank you for considering the changes. Please see in-line for a few more comments.
Best, Meral > -----Original Message----- > From: Donald Eastlake [mailto:d3e...@gmail.com] > Sent: Wednesday, October 21, 2015 7:54 AM > To: Meral Shirazipour > Cc: draft-ietf-trill-rfc7180bis....@tools.ietf.org; gen-art@ietf.org > Subject: Re: Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06 > > Hi Meral, > > On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour > <meral.shirazip...@ericsson.com> wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. > > > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > > > Document: draft-ietf-trill-rfc7180bis-06 > > Reviewer: Meral Shirazipour (was originally assigned to another > > gen-art) Review Date: 2015-10-19 IETF LC End Date: 2015-10-19 IESG > > Telechat date: 2015-10-22 > > > > > > > > Summary: > > > > This draft is ready to be published as Standards Track RFC but I have > > some comments . > > Thanks. See below. > > > Major issues: > > > > > > Minor issues: > > > > -[Page 5], Section 1.1: this section updates section 1.2 of RFC6325. > > The update is about conflict resolution between sections of the RFC. > > > > Shouldn't this bis highlight those conflicts if any? > > I do not believe there are any real conflicts. RFC 6325 has some > general/introductory sections and some detailed technical sections. > The general sections, particularly Section 2, are written with a pedagogical > goal of giving the reader the best general understanding and such general > sections are not necessarily precise and do not, in general, include every > corner case. During the development of RFC 6325, some reader focused on > such general descriptions and claimed that the "conflicted" with the precise, > detailed technical sections. > Thus Section 1.2 was added to RFC6325 to resolve this and make it clear that > the later detailed sections should be followed in case of any such apparent > "conflict". > > I don't really remember exactly what motivated making the material about > precedence of sections in RFC 6325 more complete in RFC 7180 but it was > probably based on some comment. > > The only change from Section 1.1 of RFC 7180 to this Section 1.1 draft-ietf- > trill-rfc7180bis is updating of some other RFC numbers in this section. > [MSh] Would it be possible to add a few sentences to clarify that? or maybe remove the word "conflict" ? > > -[Page 14], Section 3.4. Should this section have a MUST sentence just > > before the last sentence? > > > > "All RBridges in a campus MUST determine distribution trees in the > > same way " > > I don't think so. The mandatory implementation of the distribution tree > computation provisions is elsewhere. The sentence you refer to is just > discussion of the consequences of failure to follow that. > > > -[Page 10], Section 2.4.2.1 , gives an example, then the first bullet > > after the figure explains the problem with that scenario and says > > "MUST NOT be locally distributed in native form ". > > > > Is it possible to clarify what should be done instead? > > This section is about tunneling the frame to a neighbor that is offering the > OOMF service. It could be re-worded a little to use "instead" rather than > "before". The change would be > > OLD > The multi-destination frame MUST NOT be locally distributed in > native form at RB2 before tunneling to a neighbor because this > would cause the frame to be delivered twice. > > NEW > The multi-destination frame MUST NOT be locally distributed in > native form at RB2 because this > would cause the frame to be delivered twice. Instead it is tunneling to > a > neighbor as provided in this section. > [MSh] NEW looks good to me. Thanks. > > -[Page 11], last line, "forwards the packet on that tree." > > > > Just checking if that is supposed to say "packet" or if it should say > > "frame" or "TRILL Data packet"? > > It would be more consistent to say TRILL Data packet. > > > Naming ("frame" or "TRILL Data packet") are used throughout, but it > > would help to mention the convention at the beginning of the draft. > > I believe the intent to is use "frame" for native frames to/from end stations > and "TRILL Data packet" or "packet" for TRILL encapsulated packets between > TRILL switches. This convention could be mentioned in Section 1.3. > [MSh] Thanks agree. > > Nits/editorial comments: > > > > -[Page 6], Section 1.3, "RBridge - An alternative name for a TRILL Switch." > > > > To remain true to RFC7325, better to add Routing Bridge: "RBridge - > > Routing Bridge, an alternative name for a TRILL Switch." > > OK. > > > -[Page 15], Section 3.6 , "can implemented"--typo-->"can implement" > > OK. > > > -[Page 16], Section 3.6.1 , "program their hardware tables", > > > > is it assumed that TRILL fast path will only/always be HW based? > > There are software implementations of TRILL. Probably better to say > "program their forwarding tables." > [MSh] Thanks. > > -[Page 17], "RB1 is show with three ports"--typo-->"RB1 is shown with > > three ports" > > OK. > > > -[Page 34], "then behavior is as specified"---> "the behavior" or > > "then the behavior" > > OK. > > > -[Page 35], Section 10.2.2, "those capabilites"--typo-->"those capabilities" > > OK. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > > > Best Regards, > > > > Meral > > > > --- > > > > Meral Shirazipour > > > > Ericsson > > > > Research > > > > www.ericsson.com _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
