Re: [manet] DLEP Metric drafts

[Abdussalam Baryun <[e-mail]>]

Hi Henning,

We did not continue discussion on the drafts, but in last meeting 117 the
wg_chair mentioned that you will continue to participate drafts in our WG.
I hope we get a presentation at the next WG meeting.

On Fri, Sep 24, 2021 at 9:05 AM Abdussalam Baryun <
[e-mail]> wrote:

>
>
> On Mon, Sep 13, 2021 at 9:06 AM Henning Rogge <[e-mail]> wrote:
>
>> On Sun, Sep 12, 2021 at 11:01 PM Abdussalam Baryun
>> <[e-mail]> wrote:
>> >
>> > Hi Henning,
>> >
>> > In the meeting I showed my interest, but one of the draft I
>> explained/wanted to know the packet format to be added in draft (as you did
>> not prefer to use manet-packet), my reason was that frequency band draft
>> was not important to me only if I have a clear packet format between not
>> only radio-router but also neighbours as a unified format related to
>> frequency selected. However, for the other two draft I support totally.
>>
>> Just as a comment... my drafts are all DLEP (RFC 8175) extension
>> drafts, so they have to comply to the DLEP packet and message
>> format... packetbb (RFC 5444) is the data format for NHDP and OLSRv2,
>> which does NOT apply to RFC 8175. The discussion about what data
>> format we (as the MANET WG) want to use ended with publishing the RFC
>> 8175.
>>
>
> If this draft is using DLEP format only....... then it is fine, so I
> suggest it should mention that more in details. The DLEP draft is mostly
> generalised, it is ok to have generalised extensions but some
> information/details sections to back that up (e.g. DLEP RFC8175 gives some
> guide of using it).
>
>  I am interested to know benefit of the extension for manet, so I needed
> more information.
>

The radio_and_channel_drafts ( updated 23/7) may need more
usecase information.
I remember that there were comments related to short text_drafts with no
suggestions on texts from WG. We may add in future updates.


>
> Therefore,  now the DLEP is not only for MANETs as publishing 8175, so it
> can be used with other IETF-WGs (let us leave it that way), so we can
> discuss to look into more advantages within IETF. Furthermore, I notice
> that rfc8175 does leave things open/general for discussion as it has
> mentioned-assumptions and has things it did not end discussion about.
>

We may need to determine the assumptions/usecase included in
section_5_rfc8175 related to these drafts.

Regards,
AB