Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06

[Donald Eastlake <[e-mail]>]

Hi Jari,

On Thu, Oct 22, 2015 at 8:51 AM, Jari Arkko <[e-mail]> 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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Jari
>
> On 21 Oct 2015, at 17:20, Meral Shirazipour <[e-mail]> 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:[e-mail]]
>>> Sent: Wednesday, October 21, 2015 7:54 AM
>>> To: Meral Shirazipour
>>> Cc: [e-mail]; [e-mail]
>>> 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
>>> <[e-mail]> 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   [phone] (cell)
>>> 155 Beaver Street, Milford, MA 01757 USA  [e-mail]
>>>
>>>> Best Regards,
>>>>
>>>> Meral
>>>>
>>>> ---
>>>>
>>>> Meral Shirazipour
>>>>
>>>> Ericsson
>>>>
>>>> Research
>>>>
>>>> www.ericsson.com
>> _______________________________________________
>> Gen-art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/gen-art
>