[Babel-users] Babel extension mechanism

[Denis Ovsienko]

> I hope to do something with this (hopefully an experimental RFC), so
> please take the time to review it.

Hello. Suggested diff against revision 00 is below. A few additional points:
* Section 2.3.1 and its subsections would make a good top-level section of its own (3?). This way Section 2 would be focused on one topic consuming less of a reader's stack.
* The passages about the Flags field would be much cleaner with a small bitmap.
* Uncoordinated use of the unassigned 6 bits is asking for trouble when multiple extensions are in place, unaware of each other. It should be either a registry of sorts, or a big warning, or a statement that Flags are not for future extensions at all.

--- draft-chroboczek-babel-extension-mechanism-00.xml.orig	2013-07-02 01:14:34.701697666 +0400
+++ draft-chroboczek-babel-extension-mechanism-00.xml	2013-07-02 01:21:05.024227636 +0400
@@ -7,6 +7,7 @@
 <?rfc sortrefs="yes" ?>
 <?rfc compact="no" ?>
 <rfc category="exp" docName="draft-chroboczek-babel-extension-mechanism-00"
+     updates="6126"
      ipr="trust200902">
 <front>
 <title abbrev="Babel Extension Mechanism">Extension Mechanism for the Babel Routing Protocol</title>
@@ -27,7 +28,7 @@
 <date day="30" month="June" year="2013"/>
 
 <abstract><t>This document defines the encoding of extensions to the
-Babel routing protocol <xref target="BABEL"/>.</t>
+Babel routing protocol, updating, but not superceding RFC 6126.</t>
 </abstract>
 
 </front>
@@ -64,7 +65,7 @@
 arise.</t>
 
 <t>In the rest of this document, we call "base protocol" the protocol
-defined in RFC 6126, and "extended protocol" any extension of the
+defined in <xref target="BABEL" />, and "extended protocol" any extension of the
 Babel protocol that follows the rules set out in this document.</t>
 
 </section>
@@ -94,7 +95,7 @@
 protocol, as well as by other extended implementations of the Babel
 protocol, as long as the TLV types do not collide.</t>
 
-<t>All new TLVs MUST have the format defined in RFC 6126, Section 4.3.
+<t>All new TLVs MUST have the format defined in <xref target="BABEL" />, Section 4.3.
 Additionally, they SHOULD be self-terminating, in the sense defined in
 the next section, and any data found after the main data section of
 the TLV SHOULD be treated as a series of sub-TLVs.</t>
@@ -141,8 +142,8 @@
 <t>Except for Pad1 (see below), a Sub-TLV has exactly the same
 structure as a Babel TLV:</t>
 <figure><artwork><![CDATA[
-0                   1                   2                   3
-0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |     Body...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
@@ -167,8 +168,7 @@
 <section title="Pad1">
 
 <figure><artwork><![CDATA[
-0               
-0 1 2 3 4 5 6 7 
+ 0 1 2 3 4 5 6 7 
 +-+-+-+-+-+-+-+-+
 |   Type = 0    |
 +-+-+-+-+-+-+-+-+
@@ -186,8 +186,8 @@
 <section title="PadN">
 
 <figure><artwork><![CDATA[
-0                   1                   2                   3
-0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type = 1   |    Length     |      MBZ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
@@ -216,7 +216,7 @@
 
 </section>
 
-<section title="The Flags field">
+<section title="The Flags Field of the Update TLV">
 
 <t>The Flags field is an eight-bit field in the Update TLV.  Bits with
 values 80 and 40 hexadecimal are defined in the base protocol, and


-- 
    Denis Ovsienko