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(_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.)
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.
-- 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"
-- 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.
[...]