Subject: [manet] DLEP-14: Terminology

From: RJ Atkinson <[email-masked]>
Date: Wed, 24 Jun 2015 15:45:03 -0400

(ASIDE:  In this and any other near-term posts I am changing 
the SUBJECT line(s) of the email to try to separate out 
different conversation threads to reduce potential for confusion.)

In common IETF terminology, “extension” or “extensions” can
refer to any proposed addition to an IETF protocol, such as
an additional Data Item or an additional Signal.

As such, using “Extensions” with the special DLEP meaning
of DLEP-14 in Section 3.1, in Section 7.3, and in Section 9.0
tends to create some confusion.

Might I suggest that this special DLEP meaning be renamed
to something else ?     

A straw man replacement term is “Capability Set”.  

I’m flexible, but I am looking for a term that would not be
confusing in ordinary discussions about how a protocol
might be ‘extended’ - for example by adding new Data Items 
or adding new Signals.

Thanks,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Thu, 25 Jun 2015 08:17:55 +0200

> an additional Data Item or an additional Signal.

A DLEP extension is exactly that... a group of (standardized)
additional signals/data-items. The "extension TLV" is just the way to
tell the other side "hey, I am supporting this extension!"

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Thu, 25 Jun 2015 09:25:42 +0000

I must admit that I'm with Henning on this one.

A DLEP Extension is exactly that: a (Standardized) Extension to DLEP.

Rick

On 25/06/15 07:18, Henning Rogge wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 25 Jun 2015 09:15:58 -0400

> On 25  Jun 2015, at 05:25 , Rick Taylor <[email-masked]> wrote:
> 

Hi,

In general, considering IETF protocols, the new Data Item(s) and/or 
the new Signal(s) are most commonly considered to be the actual 
extensions to the specification.

The so-called “Extensions” field is really a mechanism to indicate a 
set of new Data Item(s) and/or new Signal(s) that an implementation 
is capable of supporting.

Regardless, the current terminology is, in practice and as shown during
recent list discussions, confusing.  

Can we please find a more clear term ?  

If folks don’t like “Capability Set”, then maybe “Extensions Set”
or “Extensions Label” (or pick some other term that folks do like 
that also will be more clear to a random reader/implementer in future 
— someone who has not participated in the MANET WG discussions) ?

Thanks,

Ran

---

From: Justin Dean <[email-masked]>
Date: Thu, 25 Jun 2015 10:28:31 -0400

>> tell the other side "hey, I am supporting this extension!"

"Extension Set Supported" vs "Extensions Supported" seems like a nit of a
issue and not really an issue either way.  Although Extension Set does seem
a tad clearer to me.
To the root of the issue can be cleaned up with a bit more clarity for
section 8.7

The Extensions Supported data item MAY be used in both the Peer
   Initialization and Peer Initialization ACK signals.  The Extensions
   Supported data item is used by the router and modem to negotiate
   *additional optional functionality* they are willing to support.  The
   Extensions List is a concatenation of the types of each supported
   extension, found in the IANA DLEP Extensions repository.

to

The Extensions Supported data item MAY be used in both the Peer
   Initialization and Peer Initialization ACK signals.  The Extensions
   Supported data item is used by the router and modem to negotiate
   additional optional functionality they are willing to support.  The
   Extensions List is a concatenation of Extension Types, defined in
   the IANA DLEP Extensions repository.  Each Extension Type
   definition includes which additional signals and data-items are
supported.

---

From: Rick Taylor <[email-masked]>
Date: Thu, 25 Jun 2015 15:13:58 +0000

On 25/06/15 15:28, Justin Dean wrote:
> "Extension Set Supported" vs "Extensions Supported" seems like a nit of
> a issue and not really an issue either way.  Although Extension Set does
> seem a tad clearer to me.
> **additional optional functionality they are willing to support.  The

Agreed, it's in proto-draft-15.

Rick