Subject: Re: [manet] DLEP Vendor Extensions negotiation

From: Rick Taylor <[email-masked]>
Date: Tue, 23 Dec 2014 12:01:34 +0000

All,

I'm just running through some updated ideas for extensions in my head and thought I would jot down some ideas.

If tlvs are split in to type and subtype (0 for command and control tlvs, 1 for core metrics, 2 to 64 for future standards, 65 to 128 for vendor extensions and some experimental space) then extensions supported can be negotiated at session initialization by stating a list of extensions supported with the usual behaviour for not supported etc.

This might allow a clean method for future extensions to be negotiated and allow vendors some private space as well on a per session basis.

The disadvantage is that two registries would have to be maintained by IANA.

Before I go too far down this line of thought does anyone have any points I may have missed?

Rick

Sent from my HTC

----- Reply message -----
From: "Henning Rogge" <[email-masked]>
To: "Stan Ratliff" <[email-masked]>
Cc: "manet IETF" <[email-masked]>
Subject: [manet] DLEP Vendor Extensions negotiation
Date: Fri, Dec 19, 2014 17:28

On Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff <[email-masked]> wrote:
> Henning,
>
> Yeah, that was my point - it's already done via the "Optional TLVs
> Supported" mechanism.

Damned, you are right...

I somehow had the "direction" of the announcement the other way around
in my head.

Each side announces which TLVs it understands... if something
mandatory is missing the other side can drop the session.

So it is a non-issue.

Henning Rogge

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: Teco Boot <[email-masked]>
Date: Tue, 23 Dec 2014 14:20:47 +0100

Why would IANA keep track of vendor extensions? 
We only need one type codepoint for vendor extensions. The TLV format has a mandatory UOI (which are somewhat easy to get).  Each vendor shall set up its own subtype registry and publish. This brings the housekeeping for proprietary stuff where it belongs: outside IETF and IANA. If vendors want their stuff standardized, which they should, they shall bring it to IETF.

Teco

> Op 23 dec. 2014, om 13:01 heeft Rick Taylor <[email-masked]> het volgende geschreven:
> 
> All,
> 
> From: "Henning Rogge" <[email-masked] <mailto:[email-masked]>>
> To: "Stan Ratliff" <[email-masked] <mailto:[email-masked]>>
> Cc: "manet IETF" <[email-masked] <mailto:[email-masked]>>
> On Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff <[email-masked] <mailto:[email-masked]>> wrote:
> > Henning,
> >
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 23 Dec 2014 15:47:45 -0500

I'll note - the schedule discussed and agreed on in Honolulu had this item
(Vendor Extensions) scheduled for resolution by Dec 19.... Advice from the
ADs is that we're out of time extensions.

We CANNOT continue to cycle on this issue. We MUST come to consensus and
move on.

Regards,
Stan

On Tue, Dec 23, 2014 at 7:01 AM, Rick Taylor <[email-masked]
> wrote:

> If tlvs are split in to type and subtype (0 for command and control tlvs,
> 1 for core metrics, 2 to 64 for future standards, 65 to 128 for vendor
> extensions and some experimental space) then extensions supported can be
> negotiated at session initialization by stating a list of extensions
> supported with the usual behaviour for not supported etc.
>
> This might allow a clean method for future extensions to be negotiated and
> allow vendors some private space as well on a per session basis.
>

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 23 Dec 2014 15:52:22 -0500

As I understood the thread with Henning et. al. on this topic:

Presentation of the Vendor Extensions TLV will stay in the Peer-level
exchange. However, presentation of the Vendor Extension TLV implicitly
"announces" formats for codepoints in the Experimental space. This let's
the vendors utilize the Experimental TLVs to... well... experiment with
potential additional, modem-specific metrics. It also provides an impetus
for follow-on drafts, if the aforementioned modem-specific metrics gain
broad acceptance.

Regards,
Stan

On Tue, Dec 23, 2014 at 8:20 AM, Teco Boot <[email-masked]> wrote:

> We only need one type codepoint for vendor extensions. The TLV format has
> a mandatory UOI (which are somewhat easy to get).  Each vendor shall set up
> its own subtype registry and publish. This brings the housekeeping for
> proprietary stuff where it belongs: outside IETF and IANA. If vendors want
> their stuff standardized, which they should, they shall bring it to IETF.
>
> Teco
>
>
> Op 23 dec. 2014, om 13:01 heeft Rick Taylor <
> [email-masked]> het volgende geschreven:
>
> All,
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Dec 2014 21:58:15 +0100

On Tue, Dec 23, 2014 at 9:52 PM, Stan Ratliff <[email-masked]> wrote:
> "announces" formats for codepoints in the Experimental space. This let's the
> vendors utilize the Experimental TLVs to... well... experiment with

Yes...

instead of giving Vendors each a space where they can build stuff AND
keep it there, we give them a space to quickly test and roll out
stuff... but in the end you want normal IANA codepoints.

Henning