Subject: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 09 Dec 2003 12:29:20 -0500

The IESG has reviewed the document and did not have any issue with the
content of the document per se.

However, the follow issue was raised:

 This document has a normative reference to RFC 2153, which is an
 informational document. Per 2026, Standards Track documents can't
 have normative references to informational documents.

The following options were mentioned as ways forward:

	- Moving to reclassify 2153 as Standards Track.

	- Making 2153 an informative reference. (doable, but would
          require some text shuffling)

	- Moving this draft to Informational track.

I think there was a slight preference within the IESG for the latter
step, but we can go with whatever the WG decides it wants to do.

Opinions?

Thomas

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Dec 2003 22:03:04 +0200

> 	- Moving to reclassify 2153 as Standards Track.

I didn't realize reclassification is an option. Does
that involve re-publishing the RFC with a different
number, the whole RFC approval process?

>           require some text shuffling)

Hmm.... perhaps you can do it but I wonder if its too
much of a stretch. The draft says that it uses the
2153 OUI values. Yes, they are mostly IEEE numbers
but not in the case of CF0000 values. I'm not sure
how you would avoid having 2153 define at least partially
the semantics and allocation policy for one of the
fields in the draft.

> 	- Moving this draft to Informational track.

I'm not sure why 2153 was put out as Informational.
But if the reclassification is a too lengthy process
and making the reference informative too hard,
moving this draft to informational track
may be the only option left.

--Jari

---

From: James Carlson <[email-masked]>
Date: Tue, 9 Dec 2003 15:17:44 -0500

Jari Arkko writes:
> but not in the case of CF0000 values.

I don't think that's so much a problem -- this draft can reference
IANA for those values directly.  The CF0000 values are fixed by IANA,
regardless of what 2153 might say.

> I'm not sure why 2153 was put out as Informational.

I *think* the reasoning looked something like this:

	These are, by definition, vendor-proprietary extensions.
	There's no hope that vendors will interoperate on proprietary
	extensions (if they did, such things would be better issued as
	public documents), so any document that depends on such
	interoperability won't advance on standards track.

The small flaw behind that logic, at least in my mind, is that
properly agreeing-to-disagree (per the protocol, where each side is
from a different vendor) *is* an instance of "interoperability," so
long as the link doesn't fail or behave badly because of it.

There's a fuzzy line here -- the mechanism for extension is itself
reasonably standards-track material, but any use of the mechanism
would (necessarily) be proprietary.  So what do you do?

All that said, I'm not too worried about the problem.  If the simplest
solution is to make this Informational as well (and I think it is),
then that's certainly fine by me.  It's publication in a fixed form
that allows reference ("here's what you do if you're doing one of
these") that matters most to me.

-- 
James Carlson, IP Systems Group                <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Dec 2003 22:42:22 +0200

> these") that matters most to me.

Agreed.

Given this, my point below is pretty academic. But I just wanted

 > would (necessarily) be proprietary.  So what do you do?

Yes. I think this is perfectly normal. The escape hatch is standard,
but what happens when you go outside it is not. Most modern protocols
with potential local extension needs have a standardized way to do
it. L2TP, Diameter, ... and in many cases there has been a lot
of debate exactly how easy or hard such extensibility should be
made. Most often the extensibility has been pretty strictly
controlled.

--Jari

---

From: James Carlson <[email-masked]>
Date: Tue, 9 Dec 2003 16:17:20 -0500

> made. Most often the extensibility has been pretty strictly

Right, and it was on this point ("standard support of non-standard
bits") that I asked to hear if there were any IESG direction or
policies, since I suspect that others have seen advancement issues
here.  It'd be really nice if all the protocols needing to provide
such features did it in a similar way.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 09 Dec 2003 19:41:19 -0500

> such features did it in a similar way.

If I understand your question, its about interoperability testing for
non-standard features. This doesn't come up all that much (partly I
guess because not that many documents advance in the first
place...). But in the past, I know there have been cases where the
negotiation process itself was standards track and testable for
interoperability, but the specific methods that were negotiated were
not. Isn't this the case with PPP compression, for instance? I think
IPComp (RFC 3173) also took this approach.

Thomas

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Dec 2003 08:24:44 -0500

Thomas Narten writes:
> not. Isn't this the case with PPP compression, for instance?

That's not quite the same.  With PPP Compression (CCP), the methods
are mostly documented in RFCs, and very few completely undocumented
ones are ever seen in the wild.  Granted, most (all?) of the
documented methods have onerous licensing and IPR issues, but
interoperability among multiple independent implementations is
certainly not unknown.

The goal of this draft is rather different.  It's explicitly carving
out a space for vendor-proprietary features, and, unlike CCP, there's
no expectation that there'll ever be interoperable versions of these
things, at least for large values of "interoperable," nor any open
documentation of them.

What the draft does is set a lower bar -- it defines a way that
vendor-proprietary extensions can meet out in the field and not just
explode on contact.  The current state-of-the-art (as it were) prior
to this draft is to "steal" an option or protocol number from the
IANA, just start using it, and hope that it nobody runs into trouble.
I don't want to call anyone out specifically, but I suspect that
everyone who has had to deal with protocol '0000' (!) or other such
oddities has faced knotty interoperability problems.

> I think

That's a problem similar to CCP.

Anyway, I'd hoped there'd be some sort of general approach here ("when
carving out areas of a namespace such that vendors can add
undocumented features, the document can advance on standards track
when there are independent implementations that gracefully decline to
use the extensions; actual successful negotiation of such an option
between independent implementations is neither expected nor required")
so that we don't push more such drafts out into Informational.

But, to move forward, I'm still in favor of calling it Informational.
That's sufficient.