Hi Jari, On Thu, Oct 22, 2015 at 8:51 AM, Jari Arkko <[email protected]> wrote: > 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?
Yes, I would say that sentence is really just a back-stop as you describe. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] > Jari > > On 21 Oct 2015, at 17:20, Meral Shirazipour <[email protected]> > 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:[email protected]] >>> Sent: Wednesday, October 21, 2015 7:54 AM >>> To: Meral Shirazipour >>> Cc: [email protected]; [email protected] >>> 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 >>> <[email protected]> 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 [email protected] >>> >>>> Best Regards, >>>> >>>> Meral >>>> >>>> --- >>>> >>>> Meral Shirazipour >>>> >>>> Ericsson >>>> >>>> Research >>>> >>>> www.ericsson.com >> _______________________________________________ >> Gen-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
