IETF conflict review for draft-chroboczek-babel-extension-mechanism
conflict-review-chroboczek-babel-extension-mechanism-00
Yes
(Jari Arkko)
(Spencer Dawkins)
(Ted Lemon)
No Objection
(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Stephen Farrell)
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Adrian Farrel Former IESG member
Yes
Yes
(2015-02-28)
Unknown
The following commments about the content of the document may be useful to the authors and the ISE. === Section 2.1 The header of a Babel packet contains an eight-bit protocol version. The currently deployed version of Babel is version 2; To be consistent with the statement at the end of Section 1, I think you need "The original protocol is version 2." Versions 0 and 1 were experimental versions of the Babel protocol This is true, but gives the impression that version 2 is not experimental. Maybe "Versions 0 and 1 were also experimental..." --- Sections 2.2 and 2.3 could use forward references to Section 5 --- Section 2.4 Bits with values 80 and 40 hexadecimal are defined by the original protocol, and MUST be recognised and used by every implementation. It is clear what you mean, but a bit will not have value x80 or x40. Maybe you can find a way to reword. Due to the small size of the Flags field, extensions to the Babel protocol SHOULD NOT use the six unused bits of the Flags field, and no registry of flag assignments is currently being defined. This is a little odd, IMHO. Of course, you are within your rights to make this rule, but you seem to be saying that, because there are so few bits available you might run out, and in order to make sure you don't run out you won't ever use any of the spare bits. On the other hand "SHOULD NOT" allows that they *are* allowed to be used. The absence of a registry then allows for conflicts. So perhaps you are trying for ...other bits are reserved for use in future versions of the Babel protocol and MUST NOT be used in extensions to version 2 of the Babel protocol. But Section 4 has... Using a new bit in the Flags field is equivalent to defining a new sub-TLV while using less space in the Babel packet. Due to the high risk of collision in the limited Flags space, and the doubtful space savings, we do not recommend the use of the Flags field. You are now giving a different reason (and a different strength of advice) for not allocating new bits: there would be no risk of collision if you had a registry. --- Section 3 Length The length of the body, exclusive of the Type and Length fields. In what units? Ditto 3.1.2 --- 3.1. Standard sub-TLVs Given this is an Experimental RFC on the Independent Stream, I think this choice of title is poor. I'd suggest... 3.1. Pad sub-TLVs Or... 3.1. Sub-TLVs Specified in this Document --- I presume that ISE RFCs still need to conform to the rules that you split your references into Normative and Informative.
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
()
Unknown
Ted Lemon Former IESG member
Yes
Yes
()
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
()
Unknown