Meral, many thanks for the review. Donald, many thanks for the changes. I have balloted no-obj.
On re: conflicts, I understood the sentence as a usual if-all-else-fails clause of specifying which document has precedence in case some conflicts are discovered later. I think that’s fine. Is this your understanding too, Donald? Jari On 21 Oct 2015, at 17:20, Meral Shirazipour <meral.shirazip...@ericsson.com> wrote: > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
