Skip to main content

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