Subject: [manet] (no subject)

From: Thomas Clausen <[email-masked]>
Date: Wed, 7 Nov 2007 22:50:56 +0100

Russ, All

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

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.

So, since "half is worse than nothing", I'm firmly against "half".

Since the benefits of not having the constraints are unclear but the  
inconveniences are quite considerable, whereas having the constraints  
presents considerable benefits with little or no inconveniences, then  
I see no reasons not to maintain and move forward with the  
constraints in place.

Justin said it elegantly, so I'll cite him:

> I honestly think there is still a lot of misunderstanding on what  
> is and
> isn't possible with the current design.  Most examples which use  
> packetbb
> layout but require a relaxation of the restrictions, seem to me,  
> not to
> actually require restrictions being lifted if a different TLV  
> design/layout
> is used.  And in most cases I have thought about the new design is  
> often
> just as efficient and almost always less ambiguous.

Finaly, to pound back at Russ' last sentence, which went:

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

While the design was still wide open might just have been the time to  
address this -- not weeks AFTER a WGLC of an essentially done and  
widely implemented specification. So one clearly wonders why this was  
brought forward at such a late time....

And now, off to the bbq pork roast (which, if it's burned, I'll blame  
on y'all) -- until tomorrow ;)

Thomas

On 7Nov , 2007, at 10:04 PM, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>> I suggest that the arguments presented for changing the mandates from
>> MUST to MAY have been insufficient, and that the consequences of  
>> doing
>> so have not been fully considered by the proponents of this change.
>>
>> I furthermore note that the current mandates in packetbb in no way is
>> limiting the applicability within the intended problem domain of  
>> MANET
>> protocols, and that therefore -- given the benefits which have been
>> presented elsewhere -- it is timely to move forward with this I-D
>> towards publication.
>
> I would suggest that if the packet ordering constraints are left as  
> they
> are, many protocols will find them to be so restrictive, and so
> unuseful, as to make packetbb unuseful. That would defeat the entire
> purpose of creating a standard in this area, IMHO.
>
> Alternate suggestions have been aired on the list, and roundly  
> ignored.
> For instance, the packet format could have an indicator in the header
> indicating if the TLVs are "in order" or not. Or, the TLV space  
> could be
> divided in half, so that each TLV actually has two TLV numbers, one of
> which must be used in order, the other of which does not. Or, the  
> packet
> could be divided through the use of TLVs so some part of the packet is
> in order, and the remainder is not. Some protocols could place all  
> their
> TLVs in the "in order" section, some could place all their TLVs in the
> "out of order" section, and other protocols could place some in each
> section, as they see fit.
>
> There are a lot of creative solutions lying around here. 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.
>
> :-)
>
> Russ
>

-- 
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 17:00:56 -0500

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

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. 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, 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.

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

:-)

Russ

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 07 Nov 2007 16:36:05 -0800

Hello Thomas,

ext Thomas Clausen wrote:
> 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....

If the protocol specification tells the parser to enforce the 
constraints, then
why cannot the protocol processing rely on the parser enforcing the
constraints?  I really don't see this argument at all.  I'd give it 0.01 
out of ten.

> greatly, as stated elsewhere.
 It would only require that the protocols themselves specify
the constraints.  This is not complicating things "greatly".
> So, since "half is worse than nothing", I'm firmly against "half".
 I think your premise is very difficult to accept, thus I cannot
be sympathetic about your conclusion.

> I see no reasons not to maintain and move forward with the constraints 
> in place.

I think it is very handy that you have admitted that the inconveniences
are quite considerable.  I also think that any protocol designer that
wanted the constraints would be _delighted_ to find that they were
already properly available as a packetBB optional feature.  What
is wrong with this picture?  I just don't see why packetBB has to
mandate something to protect against the future contingency that
some protocol designers might not take their medicine.  Yuck!
>
>> I honestly think there is still a lot of misunderstanding on what is and
>> layout but require a relaxation of the restrictions, seem to me, not to
>> is used.  And in most cases I have thought about the new design is often

I presented a [1..googolplex] example to show that any design
one can really imagine would be specifiable under packetBB.
This does not make it a good thing.  And, to the extent that the
design departs from the logical framework in which the designers
understands their problem space, it is a bad thing even apart
from the inconvenience.

Any example I would propose would immediately become a
puzzle for the packetBB authors to redefine in a way that
is compliant to the ordering constraints.  What fun and all,
but really missing the point that they belong properly in the
protocol specification, not the metaprotocol specification.
> discussed widely within the MANET wg.

 Here is one area where you can fault me.  But I was under the
impression that reviews were earnestly solicited, whether or not
the reviewers had done their homework for the previous year.
Perhaps it was not really the case that close reviews were desired.

> brought forward at such a late time....
 On the other hand, it is true that the constraints were stuck
in there without much fanfare and, as far as I can tell, zero
motivation derived from mailing list discussion.

> on y'all) -- until tomorrow ;)
 Wow, I had leftovers.

Regards,
Charlie P.

---

From: "Justin Dean" <[email-masked]>
Date: Thu, 8 Nov 2007 12:20:50 -0500

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, November 07, 2007 7:36 PM
> To: ext Thomas Clausen
> Cc: manet
> Subject: Re: [manet] (no subject)
The [1..googolplex] is a straw mans argument.  I am sure we can both agree
that although possible it is a bad idea on how packetbb should be used for
almost any set of information.  I am much more interested in
talking/discussing/exploring encoding methods using packetbb with, and
without, the restrictions, using encodings which would actually be used.  I
feel this would help demonstrate the REAL possible effects due to the
restrictions.

> protocol specification, not the metaprotocol specification.
I am sorry you feel this way but specific examples are exactly what I would
need to be convinced that the restrictions are a bad idea.  I also feel that
these "puzzles" would be good for the community to see what is actually
possible with the restrictions still in place and how they really are not
that restrictive.  Furthermore I have a hunch that the ending result would
be just as efficient if not possibly more so within the packetbb framework.
If I am wrong well that would be constructive as well.

Justin

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Nov 2007 09:37:36 -0800

Hello folks,

In the voluminous exchanges from yesterday, I mis-took
the sense of something written by Thomas:

Charles E. Perkins wrote:
> are quite considerable.

... I see now that Thomas meant something other than the meaning
I derived during my too-quick read of this sentence.  Please excuse
my confusion -- but reading through the rest of that email I reckon
that I did not make any further use of this small thought anyway.

Regards,
Charlie P.