Skip to main content

Last Call Review of draft-ietf-trill-rbridge-extension-04
review-ietf-trill-rbridge-extension-04-genart-lc-campbell-2012-06-01-00

Request Review of draft-ietf-trill-rbridge-extension
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-06-05
Requested 2012-05-24
Authors Donald E. Eastlake 3rd , Anoop Ghanwani , Vishwas Manral , Yizhou Li , Caitlin Bestler
I-D last updated 2012-06-01
Completed reviews Genart Last Call review of -04 by Ben Campbell (diff)
Genart Last Call review of -04 by Ben Campbell (diff)
Assignment Reviewer Ben Campbell
State Completed
Request Last Call review on draft-ietf-trill-rbridge-extension by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 05)
Result Ready
Completed 2012-06-01
review-ietf-trill-rbridge-extension-04-genart-lc-campbell-2012-06-01-00
This version looks good to me.

Thanks!

Ben.

On Jun 3, 2012, at 1:35 PM, Donald Eastlake wrote:

> Hi Ben,
>
> Attached is a version incorporating changes to resolve your comments
> and a wdiff against the current -04 version. However, given the
> proximity to the IESG tele chat, I do not plan to upload this version
> before that call.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3 at gmail.com
>
>
> On Sun, Jun 3, 2012 at 9:43 AM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
>> Hi Ben,
>>
>> On Fri, Jun 1, 2012 at 3:18 PM, Ben Campbell <ben at nostrum.com> wrote:
>>> Thanks for the quick response. Further comments inline. I deleted sections
that do not appear to need further discussion. >>> >>> Thanks! >>> >>> Ben. >>>
>>> On Jun 1, 2012, at 10:45 AM, Donald Eastlake wrote: >>> >>>> Hi Ben, >>>>
>>>> Thanks for your review. See responses below. >>>> >>>> On Thu, May 31,
2012 at 6:08 PM, Ben Campbell <ben at nostrum.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 wait for direction from your document shepherd
>>>>> or AD before posting a new version of the draft.
>>>>>
>>>>> Document: draft-ietf-trill-rbridge-extension-04
>>>>> Reviewer: Ben Campbell
>>>>> Review Date: 2012-05-31
>>>>> IETF LC End Date: 2012-06-07
>>>>> IESG Telechat date: 2012-06-07
>>>>>
>>>>> Note: Since this draft is on the agenda of the IESG Telechat on the
>>>>> same day that the IETF last call expires, this review is intended
>>>>> for both purposes.
>>>>>
>>>>> Summary:
>>>>>
>>>>> This draft is almost ready for publication as a proposed standard,
>>>>> but I have some clarification questions and comments that should be
>>>>> considered prior to publication.
>>>>>
>>>>> Major issues:
>>>>>
>>>>> None
>>>>>
>>>>> Minor issues:
>>>>>
>>>>> -- section 2, general:
>>>>>
>>>>> Do the authors assume that all TRILL extensions will follow this
>>>>> spec? Since RFC6325 already specifies an extension mechanism, what
>>>>> stops an extension from ignoring this spec and doing something
>>>>> different? Does it hurt if they do?
>>>>
>>>> I am not aware of any conflicts between this draft and RFC 6325. RFC
>>>> 6325 provides the broadest header option framework, for example
>>>> specifying the field for the length of the options area and the
>>>> initial two critical summary bits. This document fills in the
>>>> structure and allocation mechanism of the remaining bits in the first
>>>> 4-byte word of the options area, consistent with and repeating some
>>>> material from RFC 6325, but leaving specification of the remainder of
>>>> the options area for future documents, which should be consistent with
>>>> both RFC 6325 and this document. (For example, some future version of
>>>> draft-ietf-trill-rbridge-options.)
>>>
>>> I agree there is no conflict--this draft adds details, but doesn't seem to
contradict anything in the RFC. >>> >>>> >>>> However, neither RFC 6325 nor
this document can actually actually bind >>>> the IETF against adopting future
standards describing extensions that >>>> do not conform. >>> >>> Certainly.
Nothing can do that. The IETF can always update a protocol to change normative
language, no matter how strongly it was stated originally :-) >>> >>>> If
future changes do not follow RFC 6325 or this >>>> document, for example
changing the location or interpretation of the >>>> option length field in the
TRILL Header or changing the interpretation >>>> of the critical summary bits
in the first word of the options area, >>>> then this would break hardware and
software implementations that >>>> depend on RFC 6325 and/or this document. But
I trust the IETF to >>>> adhere to its usually high standards for backwards
compatibility. >>>> >>>> Perhaps this draft should, in the first page header,
say "Updates: >>>> 6325", not in the sense that it makes a change but in the
sense that >>>> it fills in more details. >>>> >>> >>> Assuming the additional
details in this draft comprise preferred extension mechanism, then I think it
makes sense to say that somewhere (perhaps a SHOULD strength), and also mark it
as updating 6325. Adding details is still an update. >> >> OK. >> >>>>> --
section 2, 3rd paragraph from end: "Non-critical extensions can >>>>>   be
safely ignored." >>>>> >>>>> Is that intended to be normative? (Seems like it
should be, since >>>>> behavior for critical extensions is normative). >>>>
>>>> I think of it as more like the definition of "non-critical". >>> >>>
Sure--I mainly mention it to be consistent with the text for "critical"
extensions, since it did use normative language about dropping frames. >>> >>>>
>>>>> -- section 2.1, 1st paragraph, last sentence: >>>>> >>>>> Redundant with
normative language in previous section. >>>> >>>> ? There is a normative
requirement to discard frames with any >>>> unimplemented critical hop-by-hop
options present, which might be >>>> thought to require examination of all
options (something manifestly >>>> impossible since the format of options
beyond the first word of the >>>> options area is not yet normatively
specified). The sentence to which >>>> you refer just clarifies that testing
the appropriate crtical summary >>>> bit(s) in the first word of the options
area, if that word is present, >>>> is all that is required. >>> >>> section 2
says "Any RBridge receiving a frame with a critical hop-by-hop extension  that
it does not implement MUST discard the frame...". Section 2.1 says "If an
RBridge does not implement all critical flags in a TRILL Data frame, it MUST
discard the frame..." These really seem like the same MUST (i.e, if you updated
one but not the other, you would have an ambiguous state). The same is true for
the egress bit. >>> >>> I understand that you want to draw the connection
between a "critical extension" and "critical flags", but it's better to avoid
having multiple bits of authoritative text for the same normative requirement.
Perhaps it might be better to say something like "If the RBridge does not
implement all critical flags... it MUST treat the frame as having an
unimplemented critical extension as described in section 2" >> >> I'm OK with
your suggested wording. >> >>>> >>>>> -- section 2.3, first paragraph: >>>>>
>>>>> Is the first sentence intended as normative? >>>> >>>> Yes. When one is
describing part of a protocol and you say that some >>>> particular contiguous
block of bits is some particular field (and then >>>> possibly describe the
sub-structure of that field) isn't that always >>>> normative? >>> >>> Never
mind, I misread the sentence. Sorry for the confusion. >>> >>>> >>>>> --
section 6, last paragraph: >>>>> >>>>> No security implications of this are
mentioned. Is it really a >>>>> security consideration? >>>>> >>>>> Also, is
this more likely to be set incorrectly than all the other >>>>> things that
some implementation might screw up, so that it warrants >>>>> special
treatment? >>>> >>>> I tend to think that a discussion of what happens if bits
are >>>> corrupted or incorrectly set is something reasonable for the Security
>>>> Considerations section, although it could be elsewhere. The second >>>>
paragraph/sentence of this section says that security considerations >>>> for
any bits in the first word of the options area will be in the >>>> document
specifying those bits. This document specifies the critical >>>> summary bits
and the RBridge Channel Alert bits so there is text on >>>> both of those in
its Security Considerations Section. >>> >>> On re-reading the paragraph, I can
see interpreting it to mean that incorrectly set flags explicitly do not cause
a security problem, which I agree is reasonable to say in the security
considerations. So, never mind :-) >>> >>> [...] >>> >>> >>>>> >>>>> -- section
2, bullet list, 2nd bullet: " ... which would only >>>>>   necessarily affect
the RBridge(s) where a TRILL frame is >>>>>   decapsulated" >>>>> >>>>> Does
that mean it always affects the decapsulating RBridge but might >>>>> effect
transit RBridges as well? >>>> >>>> Yes. >>>> >>> >>> Okay, no problem. >>>
>>>>> -- section 2, first paragraph after bullet list: "critical >>>>>  
hop-by-hop extension" >>>>> >>>>> I assume this means an extension with the
critical flag set? If so, >>>>> it would be more precise to say that. >>>> >>>>
This draft was split out of a more general draft that covered >>>> extensions
in general. The three paragraphs after the bullet list on >>>> critical /
non-critical extensions apply to all extensions as well as >>>> the flag bits
in the first word of the options area. So this means >>>> critical header
extensions flags and any other types of critical >>>> options specified in the
future. >>> >>> Okay >>> >>> [...] >>> >>> >>>> >>>>> -- section 5: >>>>> >>>>>
Since section 3 is entirely composed of the referenced table, and >>>>> seems
to exist mostly if not entirely for the purpose of this >>>>> reference, why
not just move the table to the IANA considerations >>>>> section. >>>> >>>>
(Looking at Section 3, I believe the reference there to the IANA >>>>
Considerations Section should be to Section 5 rather than Section 6.) >>>> >>>>
I guess I don't actually see any problem with the current document >>>>
structure that I think flows better for someone reading it from the >>>> start.
I suppose it imposes a tiny burden on someone who is just >>>> looking at the
IANA Considerations Section. I don't see why it would >>>> be better to make it
a tiny bit easier for someone just looking at the >>>> IANA Considerations
Section while imposing a tiny burdne on those >>>> reading through the document
from the start. >>>> >>> >>> Okay. I was interpreting it as existing entirely
for the IANA registration--but if you believe it adds value to the "body" of
the text, I am okay with it. >>> >>> [...] >> >> Thanks, >> Donald >>
============================= >>  Donald E. Eastlake 3rd   +1-508-333-2270
(cell) >>  155 Beaver Street, Milford, MA 01757 USA >>  d3e3e3 at gmail.com >
<re31fftoc.txt><wdiffRE-04vInternal31.html>_______________________________________________
> Gen-art mailing list > Gen-art at ietf.org >

https://www.ietf.org/mailman/listinfo/gen-art