Subject: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt

From: [email-masked]
Date: Tue, 23 Oct 2007 13:15:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: Generalized MANET Packet/Message Format
	Author(s)	: T. Clausen, et al.
	Filename	: draft-ietf-manet-packetbb-10.txt
	Pages		: 56
	Date		: 2007-10-23
	
This document specifies a multi-message packet format that may be
   used by mobile ad hoc network routing and other protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-manet-packetbb-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-packetbb-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 30 Oct 2007 20:40:11 +0100

The packetbb-10 version is updated for type/fulltype/type-extension.
Recap:
 - msg-type is 8-bit field
 - tlv-type is 8-bit, the thastypeext indicates the 8-bit tlv-type-ext is
present
    - tlv-fulltype = 256 * <tlv-type> + tlv-type-ext

Now the text could be somewhat confusing, when the word type is being used.
In the msg-type context, there is no problem. 
In the tlv-type or tlv-fulltype context, the text needs some reviewing.
For example, the IANA section is not clear to me (or it could be old text
for type/subtype that needs editing).
I found some other ambiguous text, e.g. 5.5. page 19 line 7: "TLV with a
specific type"  It should be fulltype and not type (I guess). On
tlv-type-ext, page 17 line 5 mentions "<tlv-type-ext> is specifying an
extension of the TLV type (???), specific to the TLV type (???) and kind
(i.e. packet, message, or address block TLV)". I don't know what is meant
here, I hope we kicked out subtypes.

Another issue is that we have gaps in the tlv-fulltypes:
   0: reserved
   1 - 255: ???
   256: some constraints
   257 - 511: ???
   512: some constraints
   ..
   ..
   ..  - 2047: ???
   2048: other constraints
   2049 - 2303: ???
   2404: other constraints
   ...
I could have made some mistakes here, but that is what is wrong here.

A solution would be using tlv-fulltype = tlv-type + 256 * < tlv-type-ext >.
Now the text in the IANA section doesn't need that much updates. All
tlv-types are an overlay of lower 256 tlv-fulltypes (range: 0 to 255) and
have the specified constraints. I think usage of the higher numbers are less
restricted (to be verified). But IANA should register the full range, unless
specified otherwise.
Maybe this proposal has some unwanted effects on the ordering issue.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 12:20:17 -0000

> In the tlv-type or tlv-fulltype context, the text needs some
reviewing.

Thanks for those comments. I don't have the draft in front of me,
but we'll take a look.

> I hope we kicked out subtypes.

Type extension is subtype. There was a preference for changing the
name (actually I preferred subtype, but not strongly).

> Another issue is that we have gaps in the tlv-fulltypes:

I really don't understand what you are suggesting here. I don't
recognise what you are saying at all.

> A solution would be using tlv-fulltype = tlv-type + 256 * <
tlv-type-ext >.

No, that's exactly what we don't want to do. What we have is exactly
what we mean. When you allocate a type you get a sequence of 256
continuous
fulltypes. Typically you only want one, and reserve the rest. Sometimes
you want more. But these are not meant to be 65536 independent types,
they
are 256 types, each allowing up to 256 possibilities.

> Maybe this proposal has some unwanted effects on the ordering issue.

What we have is what we intend.

********************************************************************
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: "Ian Chakeres" <[email-masked]>
Date: Wed, 31 Oct 2007 18:31:24 +0530

Chris, I was under the impression that in the future we could allocate
a larger number of explicit types, although our current specifications
would use the rule you described (1type and 256reserved extended
types).

Please correct me if I'm wrong.

Ian

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 13:14:02 -0000

Ian, yes. You are right we can do either. But we
need it the way round it is in order to be able
to do either.

The basic rule is that you ask for a type, that
defines a new 256 table. Each such table can have
its own allocation rule. So yes, you could ask for
a set of 256 type for miscellaneous functions, and
use it for 256 separate things. But you can also
allocate it for 256 related things. or (as we
currently have) allocate 0 and leave 1-255 reserved.

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 31 October 2007 13:01
To: Dearlove, Christopher (UK)
Cc: Teco Boot; manet
Subject: Re: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt

               *** 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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 13:32:11 -0000

Ian Chakeres gave me an interpretation of what he thinks
you were meaning here. This is my interpretation of his
interpretation, hopefully it will be useful.

We reserve a block of types (a type is 8 bits) for TLVs that
there's a good reason to go first. But the ordering constraints
are in terms of fulltype (16 bits) as it explicitly says. So
obviously when we are allocating 8 types to go early, that's
allowing for a possible 8x256 fulltypes to go early.

A specific example may be a packet or message authentication
TLV. Here I would expect the natural approach to be that IANA
is asked to allocate (say) type 1 for this. Of course there
are many possible signature algorithms, and that's exactly what
the type extension would obviously be used for, building up a
table of those algorithms.

Note that such a TLV doesn't absolutely need to go early. But
there's an argument that this would be good to verify before
parsing (or absolutely minimal parsing) - type 0 might be better,
you can find TLV type 0 in a TLV block, or whether it is absent,
really easily (an argument for sorting). I just used 1 rather
than 0 above as an illustration. This would be to minimise
certain DOS attacks.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 30 October 2007 19:40
To: 'manet'
Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt 

               *** WARNING ***

The packetbb-10 version is updated for type/fulltype/type-extension.
Recap:
 - msg-type is 8-bit field
 - tlv-type is 8-bit, the thastypeext indicates the 8-bit tlv-type-ext
is
present
    - tlv-fulltype = 256 * <tlv-type> + tlv-type-ext

Now the text could be somewhat confusing, when the word type is being
used.
In the msg-type context, there is no problem. 
In the tlv-type or tlv-fulltype context, the text needs some reviewing.
For example, the IANA section is not clear to me (or it could be old
text
for type/subtype that needs editing).
I found some other ambiguous text, e.g. 5.5. page 19 line 7: "TLV with a
specific type"  It should be fulltype and not type (I guess). On
tlv-type-ext, page 17 line 5 mentions "<tlv-type-ext> is specifying an
extension of the TLV type (???), specific to the TLV type (???) and kind
(i.e. packet, message, or address block TLV)". I don't know what is
meant
here, I hope we kicked out subtypes.

A solution would be using tlv-fulltype = tlv-type + 256 * < tlv-type-ext
>.
Now the text in the IANA section doesn't need that much updates. All
tlv-types are an overlay of lower 256 tlv-fulltypes (range: 0 to 255)
and
have the specified constraints. I think usage of the higher numbers are
less
restricted (to be verified). But IANA should register the full range,
unless
specified otherwise.
Maybe this proposal has some unwanted effects on the ordering issue.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 31 Oct 2007 16:12:12 +0100

More on type / fulltype:
Why can't I get allocated just a few fulltypes? (less than 256)
What if many others request this? 
What will happen when we all use some random numbers in the 128-255 range
(private/local) for different purposes, in the same MANET?
Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 15:43:13 -0000

> Why can't I get allocated just a few fulltypes? (less than 256)

You can. You request a new type registry to be open, with
rules on how to allocate further fulltypes in it. You will
probably only actually want some (often only one, but maybe
more) right now, with rules on how to get more. We could
pack logically unrelated fulltypes together under one type.
We'd do that if we were running short. But single octet types
are more efficient, and while we have a limited number of
protocols, we can afford to use them as we are.

> What if many others request this?

If packetbb is so successful that we run into shortage of
TLV types/fulltypes, I will be gratifyingly surprised.

> (private/local) for different purposes, in the same MANET?

There's an inherent contradiction between "private/local" and
"we all". You could ask the same question about any private/local
set of allocations (UDP ports, IP addresses etc.). If you are
clashing with someone else it's not private/local.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 31 Oct 2007 18:32:11 +0100

Comments inline.
Teco.

> protocols, we can afford to use them as we are.

Great. Can you add this instruction in the IANA considerations section?
Now we touch the "gaps" issue in the number space. IANA has to register
fulltypes or an (unmanageable) number of sub-registries.

> TLV types/fulltypes, I will be gratifyingly surprised.

We better prepare for it. In the past, I was involved in costly projects
expanding fields (money, addressing). 

> clashing with someone else it's not private/local.

The problem here is that we design an "ad-hoc" protocol. We do not have
control how these protocols are being used. Protocol designers using the
private/local tlv-types could need a tool protecting their own tlv-type
numberspace. I prefer adding a really long identifier for it, as long as
standard types do not carry large overhead. For example, using 128-255 (high
order bit) MUST use a OUI (tlv-type-oui). Then, each organization can
maintain their own registry. As an alternative, it could be specified that
using private/local is not allowed on public infrastructures.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 17:50:13 -0000

> Great. Can you add this instruction in the IANA considerations
section?

It'a already there.

"If a packet TLV type is allocated then a new registry for
type extensions of that type must be created."

"If a message TLV type is allocated then a new registry
for type extensions of that type must be created."

"If an address block TLV type is allocated then a new
registry for type extensions of that type must be created."   

> fulltypes or an (unmanageable) number of sub-registries.

That's certainly not unmanageable.

> expanding fields (money, addressing).

We have a packetbb version mechanism. That will allow us any such
freedom we need.

> As an alternative, it could be specified that

Well, I'm no expert, but isn't this implicit in what
private/local means?