Subject: [manet] PacketBB version pkt-tlv and msg-tlv

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 14 Sep 2007 11:00:09 +0530

I would like to suggest that PacketBB specify a version pkt-tlv and
msg-tlv. These tlvs would allow us to identify future message formats.

Obviously, if the version TLVs are not included, parsing
implementations would assume it is version 1; that which is specified
in the PacketBB document.

What do you think of this idea? Please chime in with positive or
negative feedback.

I see this proposal as adding only a little complexity to the
document, but it definitely helps to future-proofing PacketBB.

Ian Chakeres

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Fri, 14 Sep 2007 09:36:27 +0100

I feel packetbb is entirely the wrong place for
this. packetbb is protocol agnostic, this sort
of protocol-dependent thing belongs outside it.
If something is shared by protocols, but specific
to protocols, then a separate draft is the place
for it (see timetlv).

Note that version isn't straightforward - what if
OLSRv2 (or DYMO) and SMF are sharing NHDP and the
version of one, but not the other, changes? That
indicates that more thought is needed here, and
the whole concept is protocol-dependent.

(This is also part of the architectural issue, that
my reading of the IESG comments on the MANET IANA
draft raise. Depending on how those are handled, that
may be an appropriate place for this.)

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 14 September 2007 06:30
To: manet
Cc: Thomas Clausen; Thomas Heide Clausen (work)
Subject: [manet] PacketBB version pkt-tlv and msg-tlv

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Ian Chakeres

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Fri, 14 Sep 2007 10:09:43 +0100

Sorry, in my last reply to this I misinterpreted the
suggestion as relating to protocol version. I now see
you were referring to packetbb version. The reason
for the confusion is that a TLV for this doesn't work
- it's far too late, you've already done some parsing
that may depend on the version before you get to the
TLV. (This applies even to packet TLVs, to message TLVs
the question doesn't even arise.)

If this feature were to be added, you need this up
front. The most obvious (possibly even the only) place
for it is in the packet semantics octet. There are two
possibilities here, one with two sub-cases

- Reserving a small number of bits (2 or 3, say) for
  version number. That of course gives us a bounded
  number of versions, and the less bounded it is the
  more we cut into those bits for other purposes.

- Reserving a single bit, with current value zero.
  If it is set to 1 then were are using an extension.
  That means

  + Something we haven't defined yet. If it is set then
    this is a later packetbb version, and we note that
    what is different would be specified in that version,
    including how to recognise that version.

  + We add an optional version octet to the packet header,
    before the packet TLV block. If the packet semantics
    octet bit we are discussing is set, this octet is
    present, otherwise not. Value zero of that octet (when
    present) is reserved for the base packetbb version,
    other values TBD (IANA register).

If we went down this route, I would suggest the last of
these. I can see some value in it, although I'm not
currently sold on its necessity. I would be quite against
actually defining multiple versions now (not that anyone
has suggested that).

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 14 September 2007 06:30
To: manet
Cc: Thomas Clausen; Thomas Heide Clausen (work)
Subject: [manet] PacketBB version pkt-tlv and msg-tlv

               *** WARNING ***

Ian Chakeres

---

From: "Justin Dean" <[email-masked]>
Date: Fri, 14 Sep 2007 14:01:54 -0400

I think the inclusion of a packetbb version number in the packet header is
essential.  I would like to propose combining two of Chris's suggestions.
Use two (or 3) semantic bits in the packet header for the version number
with the all ones (or all 0s depending on what makes sense) denoting an
added version field and all other values being the actual version number.
The lack of a packet header would denote the original version.

Justin

> From: Dearlove, Christopher (UK) 
> [mailto:[email-masked]] 
> Sent: Friday, September 14, 2007 5:10 AM
> To: Ian Chakeres; manet
> Subject: RE: [manet] PacketBB version pkt-tlv and msg-tlv
> 
> 
> suggestion as relating to protocol version. I now see you 
> were referring to packetbb version. The reason for the 
> confusion is that a TLV for this doesn't work
> - it's far too late, you've already done some parsing that 
> may depend on the version before you get to the TLV. (This 
> applies even to packet TLVs, to message TLVs the question 
> doesn't even arise.)
> 
> If this feature were to be added, you need this up front. The 
> most obvious (possibly even the only) place for it is in the 
> packet semantics octet. There are two possibilities here, one 
> with two sub-cases
> 
> these. I can see some value in it, although I'm not currently 
> sold on its necessity. I would be quite against actually 
> defining multiple versions now (not that anyone has suggested that).
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 17 Sep 2007 09:05:13 -0700

Hello Ian,

As long as the version TLVs are not mandatory for version 1,
I do not see anything wrong with having them.  I don't see the
need to specify them right now, though.   If there ever were
another version of packetBB, the version TLVs should be
specified at that time.

Regards,
Charlie P.