Subject: [manet] [DLEP] DLEP Vendor Extensions

From: "Viberg, Neil" <[email-masked]>
Date: Wed, 17 Dec 2014 13:36:32 -0700

Rick,

I'm sorry to hear you're removing the vendor extension. I would have
thought that no uproar would have been a positive signal.

I had no problem implementing it when I moved our Draft 5 DLEP prototype
to be compliant with Draft 6 and, more importantly, I found it useful
for passing some needed information when we used a proxy DLEP modem for
a radio without DLEP.

I suppose it's not a huge deal. We'll just have to use an experimental
TLV if it is taken out.

Cheers,
Neil 

>Date: Tue, 16 Dec 2014 15:42:56 +0000
>From: Rick Taylor <[email-masked]>
>To: manet IETF <[email-masked]>
>Subject: [manet] DLEP Vendor Extensions
>Message-ID:
>
<[email-masked]
rmsoftware.com>
>	
>Content-Type: text/plain; charset="us-ascii"
>
>All,
>
>In response to the silence concerning Vendor Extensions in DLEP, and
after much deliberation amongst the authors, we have decided to >drop
the concept from the protocol.
>Regards,
>Rick Taylor

---

From: Teco Boot <[email-masked]>
Date: Wed, 17 Dec 2014 21:50:15 +0100

I didn’t see any argument removing vendor extensions on the mailing list. What did go wrong?

Just procedural: it is not the authors which decide what gets in and out a WG draft.

Teco

> Op 17 dec. 2014, om 21:36 heeft Viberg, Neil <[email-masked]> het volgende geschreven:
> 
> Rick,
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 16:07:21 -0500

Teco,
> Just procedural: it is not the authors which decide what gets in and out a

Perhaps the case is overstated a bit. Let me attempt to rephrase: There was
(and still is) a point of contention (at least amongst the co-authors)
about Vendor Extensions, and whether they should be allowed on Destination
Update/Destination Down. The two points of view are:

1. Vendor Extensions are pretty much worthless unless/until they are
allowed on Destination Update.

2. Vendor Extensions are an abomination, *especially* on Destination Update
- at most, they should only be allowed on Destination Up.

During the Honolulu IETF, the author team asked for WG opinions regarding
those two points of view, and/or whether there might be options the
co-authors had not considered. We did actually state that DLEP-07 reflects
point-of-view #2 above; and that it (point-of-view #2) would be the
"default option" going forward. But we asked for opinions on-list.

Up to today, the silence has been deafening. The co-authors would *greatly*
appreciate if other WG participants expressed an opinion on-list, so that
we might guage WG consensus on this item.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 17 Dec 2014 22:53:17 +0100

I’ve provided my opinion in the meeting. I don’t see a problem having vendor extensions in whatever signal. They are optional items in the spec. Helpful in some cases. There is always the standards based fallback.

I cannot follow reasoning behind 2. Can someone explain?

Now I’ll continue configuring DHCP option 43.

Teco

> Op 17 dec. 2014, om 22:07 heeft Stan Ratliff <[email-masked]> het volgende geschreven:
> 
> Teco, 
> Perhaps the case is overstated a bit. Let me attempt to rephrase: There was (and still is) a point of contention (at least amongst the co-authors) about Vendor Extensions, and whether they should be allowed on Destination Update/Destination Down. The two points of view are:
>  
> 1. Vendor Extensions are pretty much worthless unless/until they are allowed on Destination Update.
>  
> 2. Vendor Extensions are an abomination, *especially* on Destination Update - at most, they should only be allowed on Destination Up. 
>  
> During the Honolulu IETF, the author team asked for WG opinions regarding those two points of view, and/or whether there might be options the co-authors had not considered. We did actually state that DLEP-07 reflects point-of-view #2 above; and that it (point-of-view #2) would be the "default option" going forward. But we asked for opinions on-list.
>  
> Up to today, the silence has been deafening. The co-authors would *greatly* appreciate if other WG participants expressed an opinion on-list, so that we might guage WG consensus on this item.
>  
> Regards,
> Stan
>  
>  
>  
>  
>  
> Teco
>

---

From: "Viberg, Neil" <[email-masked]>
Date: Wed, 17 Dec 2014 15:55:58 -0700

Teco,

I included Rick's email about removing the vendor extension which is what I was responding to. I have been monitoring the manet mailing list for months and I don't believe there was any discussion of adding a vendor extension prior to Draft 7 and there has, AFAIK, been no discussion about removing it.

If you didn't see the email, it was the start of this long dialogue which is still labeled "DLEP Vendor Extensions" but has morphed into a discussion about adding multiple destinations. 

Neil

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: Wednesday, December 17, 2014 1:50 PM
To: Viberg, Neil
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] [DLEP] DLEP Vendor Extensions

Teco

> I had no problem implementing it when I moved our Draft 5 DLEP 
> prototype to be compliant with Draft 6 and, more importantly, I found 
> it useful for passing some needed information when we used a proxy 
> DLEP modem for a radio without DLEP.
>

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 19:14:57 -0500

On Wed, Dec 17, 2014 at 4:53 PM, Teco Boot <[email-masked]> wrote:
>
> I’ve provided my opinion in the meeting. I don’t see a problem having
> vendor extensions in whatever signal. They are optional items in the spec.
> Helpful in some cases. There is always the standards based fallback.
>

The explanation behind point-of-view #2 is:

How can we define a *standards-track* protocol with a TLV in it that says
"Put any arbitrary, proprietary information you desire right here."?? Just
exactly what makes "Do whatever you want to do, Mr. Radio Vendor" a
"standard"? If allowed for Destination Update, specifically with regard to
metrics, how does the approach help us normalize/standardize *ANYTHING* ???
This was the group of people that AGONIZED for MONTHS over the precise
definition of "Latency", and whether "Latency" should be specified in
milliseconds or microseconds... And now we're actually talking about
sticking something like this into Destination Update for unknown,
proprietary, (potentially arbitrary) metrics?!?!?!?!? If that is the case,
why did the Design Team even attempt to look at metrics in the first place?

Stan

> > Perhaps the case is overstated a bit. Let me attempt to rephrase: There
> was (and still is) a point of contention (at least amongst the co-authors)
> > 2. Vendor Extensions are an abomination, *especially* on Destination
> Update - at most, they should only be allowed on Destination Up.
> >
> > During the Honolulu IETF, the author team asked for WG opinions
> regarding those two points of view, and/or whether there might be options
> the co-authors had not considered. We did actually state that DLEP-07
> reflects point-of-view #2 above; and that it (point-of-view #2) would be
> the "default option" going forward. But we asked for opinions on-list.
> >
> > Up to today, the silence has been deafening. The co-authors would
> *greatly* appreciate if other WG participants expressed an opinion on-list,
> so that we might guage WG consensus on this item.
> >
> > Regards,
> > Stan
> >
> >
> >
> >
> >
> > Teco
> >
> prototype

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 18 Dec 2014 00:20:26 +0000

On 18 Dec 2014, at 00:14, Stan Ratliff wrote:
> How can we define a *standards-track* protocol with a TLV in it that says "Put any arbitrary, proprietary information you desire right here."?? Just exactly what makes "Do whatever you want to do, Mr. Radio Vendor" a "standard"? If allowed for Destination Update, specifically with regard to metrics, how does the approach help us normalize/standardize *ANYTHING* ??? This was the group of people that AGONIZED for MONTHS over the precise definition of "Latency", and whether "Latency" should be specified in milliseconds or microseconds... And now we're actually talking about sticking something like this into Destination Update for unknown, proprietary, (potentially arbitrary) metrics?!?!?!?!? If that is the case, why did the Design Team even attempt to look at metrics in the first place?

LDP has an allocation for vendor specific TLVs, so it wouldn't be a first.

Mind you, there's at least one (other) thing about LDP I wouldn't want to adopt, so that's not a definitive argument.

---

From: Rick Taylor <[email-masked]>
Date: Thu, 18 Dec 2014 00:56:36 +0000

Neil, All,

Sorry, they are such an attractive concept, but we just can't seem to
make them usable.

I (as the original proponent of Vendor Extensions) have worked really
hard with the other authors to find a way to add some flexibility to the
DLEP metrics set, as it is so simple to outline a use-case for it.

But, it has proved impossible within the deadlines set by the WG and ADs
to find a solution that is not a 'free for all' where vendors can report
what they like and the routers have no point of reference for
implementation (when anyone can report anything, there is no real
standard anymore).

Alternative solutions such as reserving a set of TLVs in a system-scoped
block - sort of like the experimental TLVs - were also proposed, but
under close analysis, without explicit value-encoding metadata, there is
still nothing a router can do with what are effectively opaque blobs of
data.

For a proxy, using the experimental TLV space is the best way to go, as
you are proxying and therefore have full control of both ends.  When you
only have control of one end, or are trying to write a standard, such
wildcard metrics become useless very quickly.

The design team imagined later DLEP standards track documents describing
extra standard metrics for various classes of modem: satcom, mesh,
etc... and I am now convinced that is the best way to go.

Regards,

Rick

---

From: Teco Boot <[email-masked]>
Date: Thu, 18 Dec 2014 07:04:39 +0100

> Op 18 dec. 2014, om 01:14 heeft Stan Ratliff <[email-masked]> het volgende geschreven:
> 
> 
> 

Sorry, I cannot take these arguments as serious. Protocols that cannot be extended are short-lived. There is a long list of examples where IETF STD protocols carry vendor extensions.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Thu, 18 Dec 2014 08:42:23 +0100

> Sorry, I cannot take these arguments as serious. Protocols that cannot be extended are short-lived. There is a long list of examples where IETF STD protocols carry vendor extensions.

I would like Vendors coming to this group and helping to make their
vendor extensions available for everyone by putting them into a RFC.

Henning Rogge

---

From: John Dowdell <[email-masked]>
Date: Thu, 18 Dec 2014 12:50:21 +0000

Just to add my view ... having sat across the desk from Rick and had 
many, many conversations with Rick and Stan on this topic over very many 
months, the real problem as I see it is when you take a concept (however 
good) and actually have to write it down in terms that the IESG will 
accept. The author team could not make that last step, despite no 
shortage of trying, so in the interests of cleaning up and moving on to 
the fast approaching brick wall deadline, out this goes.

I fully support the author team on this one.

John

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 18 Dec 2014 10:00:02 -0500

On Thu, Dec 18, 2014 at 1:04 AM, Teco Boot <[email-masked]> wrote:
> > How can we define a *standards-track* protocol with a TLV in it that
> says "Put any arbitrary, proprietary information you desire right here."??
> Just exactly what makes "Do whatever you want to do, Mr. Radio Vendor" a
> Sorry, I cannot take these arguments as serious.

This type of statement is unhelpful. It does not advance the discussion.
Attempting to dismiss an opinion does nothing to *change* said opinion. I'm
serious. Very serious. So help me see the error of my ways; but please
refrain from this type of statement, which IMO borders on ad hominem.

> Protocols that cannot be extended are short-lived.

I believe that TLV-based protocols such as DLEP *can* easily be extended,
in an open, well-documented, interoperable manner. Therefore, I believe
this statement is self-evident, but does not apply to the issue at hand.

> There is a long list of examples where IETF STD protocols carry vendor
> extensions.
>

Carrying vendor extensions for ancillary functionality is one thing. One of
the stated reasons behind making Vendor Extensions available in the
Destination Update was to allow for additional metrics. Metrics, and the
ability to share them in a well-understood, interoperable manner are, IMO,
*the core* of the DLEP specification. Allowing the addition of a
"vendor-specific glop of goo" into the *core* of the protocol is not
"standard", and by definition it is not "interoperable". You can't even
successfully decode it with Wireshark (unless, of course, you posses the
vendor-supplied 'secret-sauce' that goes with it).

At this point, as an editor of the DLEP specification and as a chair, I do
*NOT* believe the WG has reached consensus wrt Vendor Extensions.
Therefore, the plan announced in Honolulu is still operative - that is,
Vendor Extensions are allowed *only* on the Peer Initialization/Peer Update
orders (IIRC), but are not allowed on any of the 'Destination' orders - or
more specifically (and correctly), I should state that the Vendor Extension
functionality in DLEP-07 will be carried forward without modification.

Further, just so that we're clear - *If* working group consensus forms
around the notion that Vendor Extensions should be allowed in Destination
Update for metrics, then:
1. As an editor, I will dutifully modify the document to reflect the WG
consensus, and
2. As an author, editor, co-chair, and IETF participant, I will use all
the persuasive ability I have at the AD/IESG level to make sure the
specification *NEVER* gets published at IETF.

Unless, of course, someone actually decides to help me see the error of my
position, or offers an alternative...

Stan

> > > Perhaps the case is overstated a bit. Let me attempt to rephrase:
> There was (and still is) a point of contention (at least amongst the
> co-authors) about Vendor Extensions, and whether they should be allowed on
> Destination Update/Destination Down. The two points of view are:
> > >
> > > > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil <
> [email-masked]> het volgende geschreven:
> > > >
> > > > Rick,
> > > >

---

From: Teco Boot <[email-masked]>
Date: Thu, 18 Dec 2014 16:42:07 +0100

You miss the point. Of course vendor extension metrics are not part of the *core* DLEP spec. The core spec is about encoding the extensions on a standard way.

Teco

> Op 18 dec. 2014, om 16:00 heeft Stan Ratliff <[email-masked]> het volgende geschreven:
> 
> 
> This type of statement is unhelpful. It does not advance the discussion. Attempting to dismiss an opinion does nothing to *change* said opinion. I'm serious. Very serious. So help me see the error of my ways; but please refrain from this type of statement, which IMO borders on ad hominem.
>  
>  
> I believe that TLV-based protocols such as DLEP *can* easily be extended, in an open, well-documented, interoperable manner. Therefore, I believe this statement is self-evident, but does not apply to the issue at hand.
>  
>  
> There is a long list of examples where IETF STD protocols carry vendor extensions.
>  
> Carrying vendor extensions for ancillary functionality is one thing. One of the stated reasons behind making Vendor Extensions available in the Destination Update was to allow for additional metrics. Metrics, and the ability to share them in a well-understood, interoperable manner are, IMO, *the core* of the DLEP specification. Allowing the addition of a "vendor-specific glop of goo" into the *core* of the protocol is not "standard", and by definition it is not "interoperable". You can't even successfully decode it with Wireshark (unless, of course, you posses the vendor-supplied 'secret-sauce' that goes with it).
>  
> At this point, as an editor of the DLEP specification and as a chair, I do *NOT* believe the WG has reached consensus wrt Vendor Extensions. Therefore, the plan announced in Honolulu is still operative - that is, Vendor Extensions are allowed *only* on the Peer Initialization/Peer Update orders (IIRC), but are not allowed on any of the 'Destination' orders - or more specifically (and correctly), I should state that the Vendor Extension functionality in DLEP-07 will be carried forward without modification.
>  
> Further, just so that we're clear - *If* working group consensus forms around the notion that Vendor Extensions should be allowed in Destination Update for metrics, then:
> 1. As an editor, I will dutifully modify the document to reflect the WG consensus, and
> 2. As an author, editor, co-chair, and IETF participant, I will use all the persuasive ability I have at the AD/IESG level to make sure the specification *NEVER* gets published at IETF.
>  
> Unless, of course, someone actually decides to help me see the error of my position, or offers an alternative...
>  
> Stan
>  
>  
>  
> 
> Teco
> 
> 
> >
> > Stan
> >
> >
> >
> >