IETF conflict review for draft-chroboczek-babel-extension-mechanism
conflict-review-chroboczek-babel-extension-mechanism-00

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-chroboczek-babel-extension-mechanism@ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-chroboczek-babel-extension-mechanism-03

The IESG has completed a review of
draft-chroboczek-babel-extension-mechanism-03 consistent with RFC5742.


The IESG has no problem with the publication of 'Extension Mechanism for
the Babel Routing Protocol'
as an Experimental
RFC.


The IESG has concluded that there is no conflict between this document
and IETF work.


The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-chroboczek-babel-extension-mechanism/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-chroboczek-babel-extension-mechanism/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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.