Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC

From: Thomas Clausen <[email-masked]>
Date: Thu, 8 Nov 2007 00:55:39 +0100

On 7Nov , 2007, at 11:00 PM, Russ White wrote:
>
>> The short answer (and a short answer is all I have time for, it's
>> 10:30PM here and I've still not had dinner yet....) to all of the  
>> below
>> is that doing "half" (i.e. having some things be optional, or the
>> type-space divided etc) accomplishes nothing in that one gets all the
>> inconveniences (parsing can not guarantee anything re. unambiguity  
>> etc,
>> nor can it be done linearly in a single pass etc.) with none of the
>> benefits that the ordering and uniqueness constraints would otherwise
>> have. I.e. having half gives us worse-than-nothing....
>
> I strongly disagree. Doing it correctly actually gives you the best of
> all worlds--those protocols that wish to use ordering can use it, and
> those which do not don't use it.
>

And neither would get any benefits and none of the advantages but  
both would get the disadvantages in full.

> I don't see ANY argument that shows how it's more efficient for a
> protocol that does NOT want or need to use in order TLVs will be
> accommidated in this proposal.

As I have mentioned a number of times now, why would the order that a  
TLV appear encoded in a message be of any interest to the protocol,  
then?

The encoding order would be 0, 1, 2, 3, 4, but RRP (Russ' Routing  
Protocol) could specify for itself that every Friday, except if it's  
full moon in which case it depends on the direction of the wind, the  
processing order should be 4, 2, 1, 3 and "0 should be ignored",  and  
all other days  the processing order would be 4, 3, 2, 1, 0.

And this would be ENTIRELY up to the specification of RRP to state,  
of course.

How would having the encoding-order in any way, shape or form impair  
on the ability of RRP to specify its own processing order?

Keeping the encoding-order fixed in packetbb would be a great win for  
RRP -- for an implementer could grab a piece of generic code, for  
example that written by Chris, Justin or myself, and already be  
halfway through writing your protocol implementation. Also, that  
parser will be able to decode the packet/message for you in a single  
linear pass and provide you with a datastructure that you can process  
as you wish in any order you wish. For encoding-purposes, order and  
uniqueness can be done simply, if you have a bit of spare memory then  
through an array and you should be good to go in something like O(n)  
also (so no penalty in complexity there).

I don't see ANY arguments that shows how this is more inefficient for  
a protocol.

> In fact, I have a sneaking suspicion that
>  if this were to become a standard, it would result in a large  
> number of
> threads where sentences like this are sent on list: "Well, our  
> proposal
> is more efficient than yours with the standard (!) packet formatting
> described in RFC XXXX, so the WG should adopt our proposal over yours,
> no matter the other advantages and disadvantages."

And the WG would then reasonably reply as above....

>
>> And, as I have stated repeatedly, I have not seen any tangible  
>> benefits
>> presented of making the ordering and uniqueness constraints go away
>> presented that would outweigh the inconveniences in making them go  
>> away.
>> Rather, removing these constraints complicate things greatly, as  
>> stated
>> elsewhere.
>
> It complicates things for some protocols, and makes life easier for  
> others.
>

Would you be so kind as to explain to me how it complicates things  
for some protocols?

By your own admission it "makes life easier" for some protocols --  
but it has nowhere been made clear why it complicates life for  
others. Justin's point is excellent and so I will repeat it:

>
> The restriction of TLV order only restricts encoding/decoding and not
> protocol processing which can happen in any order.
>
> The single TLV type value per address does not restrict TLVs to  
> carry only
> one 'value' in the value field.  TLV's can be defined to carry an  
> arbitrary
> list of values in one value field which can be used however the  
> protocol
> wishes.
>

>> So, since "half is worse than nothing", I'm firmly against "half".
>
> And I'm firmly against the whole. Either the WG finds a compromise,  
> or I
> will oppose this draft through the entire process. And I think we  
> could
> find enough opposition to squash this draft in it's entirety, in  
> the end.
>

I believe this comment to be entirely out of place.

>>> I don't
>>> understand why none of them have been considered before the draft  
>>> got to
>>> the last call point, nor do I understand how the draft got to  
>>> last call
>>> with this large of an issue outstanding.
>>
>> I will just add that I do not understand why this issue was only
>> addressed only well AFTER (~ 20 days after) the WGLC of this I-D  
>> closed
>> on July 24, and not in the two years preceding where this has been in
>> place IN THE CURRENT FORM in the I-D and the I-D has been discussed
>> widely within the MANET wg.
>
> Actually, I could go back quite a ways and point to emails I've  
> sent to
> the list asking this specific question.

According to the emails I have on my computer, the first email from  
you to MANET on this subject was August 13 2007 -- I have nothing  
before that. The WGLC ended July 24 2007 (if I recall correctly).  
Earlier than that, my archives contain no mention of this issue from  
anyone.

> And I could point to multiple
> emails from others stating the current draft is not acceptable. What I
> don't understand, on the other hand, is how this got so far when there
> were widely known and documented issues with it.
>
> Those emails were roundly ignored. If you ignore objections early  
> in the
> process, then they tend to come back much more forcefully at the  
> end of
> the process.
>

To my knowledge, the first objection(s) that were raised were raised  
by me in the Paris meeting :) -- but I was convinced eventually. The  
next objections that I saw raised were raised ~20 days AFTER the  
packetbb WGLC had closed, i.e. ~2 years after the Paris-meeting.  
Quickly consulting the mailing-list mails on my computer, as well as  
the WG meeting minutes, I see no evidence of this having been brought  
forward before, or else I or any of my co-authors should be aware  
hereof. I specifically note that none of these issues were brought  
forward during the WGLC.

I do not appreciate the insinuation that these are objections which  
were raised early in the process and which were ignored. The  
objections that you present were, as far as I am aware, only raised  
very late in the process, specifically after the WGLC in the summer  
2007.

Which leads me to wonder -- again -- why this issue was brought up  
only so late in the process, that the WGLC had closed, and not before  
-- at least before or in the days immediately following the closure  
of the WGLC? Or, at the Chicago-meeting (also after the WGLC)?

-- 
Thomas Clausen
[email-masked]
http://www.thomasclausen.org/
http://hipercom.thomasclausen.org/

-- 
Thomas Clausen
[email-masked]
http://www.thomasclausen.org/
http://hipercom.thomasclausen.org/

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

---

From: Russ White <[email-masked]>
Date: Wed, 07 Nov 2007 19:02:24 -0500

> And neither would get any benefits and none of the advantages but both
> would get the disadvantages in full.

Baloney.

> TLV appear encoded in a message be of any interest to the protocol, then?

Then why does it matter if it's in this draft? Why not put it in the
drafts of the protocols that require this?

> How would having the encoding-order in any way, shape or form impair on
> the ability of RRP to specify its own processing order?

*sigh* This is a red herring. The order of the TLVs in the packet
necessarily determines the processing order, in any realistic
implementation.

> I don't see ANY arguments that shows how this is more inefficient for a
> protocol.

I don't see ANY arguments that shows how the required ordering will be
more efficient for all possible protocols in all possible implementations.

>>  if this were to become a standard, it would result in a large number of
>> threads where sentences like this are sent on list: "Well, our proposal

But it would be too late, wouldn't it, because, after all--the packet
format is now a standard. You seem awful eager to limit future
innovation in favor of a current protocol, for some reason. Particularly
when that packet ordering could easily be specified elsewhere--in the
protocol specific draft--if it's so important.

>> And I'm firmly against the whole. Either the WG finds a compromise, or I
>> will oppose this draft through the entire process. And I think we could
>> find enough opposition to squash this draft in it's entirety, in the end.
>>
> 

I believe it's entirely in place, since I'm a member of the routing area
directorate, and someone who works for a large implementor of such
protocols.

Russ

- --
[email-masked] CCIE <>< Grace Alone