Subject: Re: [manet] DLEP and TLV breakdown

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 27 Apr 2012 23:38:10 +0200

>P.S. My tone may have been a little strong in that email, apologies. I think it is >great to have implementations of the standards we come up in MANET, even more >so if there are several of them. But I think as a WG we should do the right thing >and make sure that our standards, such as RFC5444, are used in the intended >and ideal way. And some DLEP implementations (e.g. Henning's) seem to use >RFC5444 Message-TLVs and address blocks already, so there is also proof that >this works (and does not require to modify the RFC5444 parser).
>Ulrich (probably my last email on the subject)

> "I think as a WG we should do the right thing "

It may be the right thing to do and it may be wrong, we need to be
sure, because still the DLEP did not complete its way through. I think
it is good to base theory on solid-theory, but it is better to make
theory independent first, then think which to make which theory the
base of the other, depending-on/considering their design purposes.

Doing things right doesn't mean to respect the first come first serve,
or leave or take, there may be a gap not seen, and designers take
chances to the best of their purpose. IMHO considering the DLEP
use-case is a new case so it is different from that of the use case of
others, so it is not right to build on old basis for the first stage.
I think it is interesting to use 5444 but it does not mean that it
cannot be updated or modified to a better standard that fulfills other
conditions which was not considered when authors and WG discussed it.

However, I hope DLEP authors can solve this issue, but we never know
in the future new things may come up and change again :)

Regards
Abdussalam Baryun
University of Glamorgan, UK

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Darryl,

I don't believe that to be an argument. I still believe the WG should
do its best job to come up with  the best solution. DLEP is a WG
document and uses RFC5444, but not correctly. That worries me, and the
only real counter-argument to the suggested changes so far has been
"we have an existing implementation and don't want to change it.".

Ulrich

On Apr 27, 2012, at 7:17, dsatterw <dsatterw at cisco.com> wrote:

> I personally have an issue at this stage of the game (we are now on our 3rd
> version of DLEP) of having to completely rewrite our packet format so that
> it better integrates into RFC5444. At this point we have at least 4 working
> implementations of DLEP out there which were all based on our sourceforge
> example of a packet parser that seems sufficient for the ones involved. If
> we, at this point, decide to rewrite the packet formats then everyone that
> has working versions today would have work to do without really any benefit
> IMO. If this objection were brought up in the 00 or 01 version of the draft
> it would be a little easier to accept than year(s) later. To be quite
> honest, I don't think DLEP fits well in RFC5444 in the first place. RFC5444
> states that it should be used by routing protocols for information exchange
> and DLEP is not a routing protocol. I would really rather spend our time
> trying to make sure that the content being exchanged between the radio and
> router is adequate than arguing about packet parsers.
>
> Darryl Satterwhite
> Cisco Systems
>
>
> On 4/27/12 9:31 AM, "Henning Rogge" <hrogge at googlemail.com> wrote:
>
>> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK)
>> <Chris.Dearlove at baesystems.com> wrote:
>>> I think the diff parsers etc. misses the point. If DLEP is to use 5444 then
>>> having a 5444 parser may be taken as the starting point. And without sub-TLVs
>>> that's all the parser you need.
>>
>> Exactly.
>>
>>> I'm afraid I think this is a clear case of design using 5444 without really
>>> appreciating it. And then when people who have greater familiarity with 5444
>>> suggest what is a more natural use of 5444, meeting a resistance that may be
>>> based on several things, but offering a better fit to 5444 and better parsing
>>> options are not among those things.
>>
>> Yes.
>>
>> At the moment DLEP is not using RFC5444 at all... except as a wrapper
>> around its own format. And everything DLEP does at the moment can be
>> expressed in a reasonable way within RFC5444.
>>
>> Henning Rogge
>
> _______________________________________________