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

Thomas Narten writes:
> 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?

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
> IPComp (RFC 3173) also took this approach.

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.

-- 
James Carlson, IP Systems Group                <[email protected]>
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