Hi Ben,
Thanks for your review. See responses below.
On Thu, May 31, 2012 at 6:08 PM, Ben Campbell <ben(_at_)nostrum(_dot_)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.)
However, neither RFC 6325 nor this document can actually actually bind
the IETF against adopting future standards describing extensions that
do not conform. 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.
-- 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".
-- 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.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?
-- 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.
Nits/editorial comments:
-- section 1:
Please expand TRILL on first mention in the body of the document
(i.e. not just in the Abstract.)
Sure. And all the other acronym expansions requested below are fine so
I won't respond individually to them below although I agree with them.
-- section 2:
Please expand RBridge and IS-IS on first mention.
-- 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.
-- 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.
-- section 2.1, 1st paragraph:
I'm a little confused by a citation for "future documents". Do you
mean the cited document as an example of something that might do
this (in which case a "for example" would help), or do you mean to
say that document will do this?
Yes, the cited work-in-progress references are examples. I'm fine with
adding "for example".
-- section 2.2, 1st paragraph:
Please expand PDU on first mention.
-- section 2.3, first paragraph:
s/modifictions/modifications
OK. Thanks.
-- 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.
Hope the above responses help with the clarification,
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3(_at_)gmail(_dot_)com