Subject: Re: [manet] DLEP-17: Extensions

From: Rick Taylor <[email-masked]>
Date: Wed, 9 Mar 2016 10:04:48 +0000

Hi Ran, All,

As part of my belated deep pass of all the DLEP review comments, in 
light of draft-20 being posted, I'll attempt to answer some of your 
comments.

As an overall comment: We have taken a lot of your suggestions on board 
and updated the text to reflect.  There's has been some bulk re-ordering 
of sections and section content in order to improve the readability and 
to ensure that normative text is centralized as much as possible.

Inline...

On 24/11/15 15:11, RJ Atkinson wrote:
>
> Extensions are more clear to me now, but the document itself
> is not crystal clear.  So I propose adding additional text
> to make their existence/use/concept crystal clear to a naive
> reader of the DLEP specification.
>
>
> Concern:
>    Neither Section 1.0 nor Section 1.1 mention that DLEP is
>    extensible.  This begs the question in the mind of the
>    first-time reader and leads to a surprise when the reader
>    reads about Extensions (e.g. in Section 5) before their
>    existence has been mentioned and they have been defined.
>
> Proposed additional text at the end of Section 1.1:
>
>    While the base DLEP specification defined here is believed to be
>    sufficient, DLEP is extensible as described in Section 6 below.
>    A DLEP extension can be used to define new behaviors, message types,
>    data items, and/or status codes.

We believe draft-20 addresses this issue by promoting the text to Section 1.

>
>
> Concern:
>    While on-list clarifications have been helpful, the actual
>    specification is not crystal clear about how Extensions work.
>    I have paraphrased previous on-list comments from others to
>    create the new paragraph below.
>
> Proposed additional paragraph for Section 6:
>
>    A single extension might contain zero or more new behaviors, zero or
>    more new message types, zero or more data items, and/or zero or more
>    new status codes.  A single extension MUST contain at least one new
>    behavior, new message type, new data item, or new status code.
>

How extensions function is intentionally not defined here.  All we do is 
introduce to the reader that extensions are possible.

More in the next mail...

Rick