Subject: Re: Call for Comments: "Design Considerations for Protocol Extensions"

From: Adam Roach <[email-masked]>
Date: Wed, 24 Nov 2010 14:46:57 -0600

On 11/24/10 2:08 PM, IAB Chair wrote:
> The IAB intends to publish "Design Considerations for Protocol Extensions"
> http://tools.ietf.org/html/draft-iab-extension-recs-02
>
>
> This document discusses issues related to the extensibility of Internet protocols, with a focus on the architectural design considerations involved.  Case study examples are included.  It is intended to assist designers of both base protocols and extensions.
>
> The IAB will submit this shortly and welcomes any comments you might have prior to Dec 11, 2010.

The recommendations in the document seem appropriate, and tailored 
towards improving the deployability and interoperability of IETF 
protocols. I do note, however, that there is very little guidance on a 
general topic that is actually causing some amount of dispute in the RAI 
area today.

Within the DISPATCH working group, there has been a proposal to extend 
the BFCP protocol (defined in RFC 4582) in a way that is fundamentally 
incompatible with the base protocol. In particular, the draft 
(draft-sandbakken-dispatch-bfcp-udp) proposes to change the transport 
from TCP to UDP. To support doing so, it proposes changes to the 
transaction model (adding BFCP-level confirmations to make up for the 
unreliability of UDP), and potentially adding restrictions on message 
size to reduce the chance of IP fragmentation.

While section 2.3 of draft-iab-extension-recs-02 can be read as very 
vaguely pointing away from this kind of extension ("[S]pecifications 
that look very similar to the original but don't interoperate with each 
other or with the original - are even more harmful to interoperability 
than extensions"), it appears to be aimed more squarely at the creation 
of protocol profiles by SDOs other than the IETF.

At the very least, the current extensions recommendation document (by 
casting this issue mostly in the light of inter-SDO coordination) leaves 
room for people to argue about whether the IAB intends such guidance to 
apply to defining new variations of a protocol aimed predominantly at 
changing the underlying transport protocol (which inherently prevents 
interoperation with the original protocol).

I would appreciate seeing more explicit guidance from the IAB regarding 
the definition of alternate transports for existing protocols, and I 
think this document is an ideal vehicle for the IAB to provide this kind 
of guidance.

/a

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Nov 2010 13:49:38 -0800

On Nov 24, 2010, at 12:46 PM, Adam Roach wrote:

> While section 2.3 of draft-iab-extension-recs-02 can be read as very vaguely pointing away from this kind of extension ("[S]pecifications that look very similar to the original but don't interoperate with each other or with the original - are even more harmful to interoperability than extensions"), it appears to be aimed more squarely at the creation of protocol profiles by SDOs other than the IETF.

well, we could discuss the use of an IETF session setup protocol for instant messaging, and the use of a protocol designed to add attributes and report on available bandwidth within a class of traffic on a standard (eg, calculated by a routing protocol) route to install a route. We do it to ourselves as well.

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Nov 2010 17:13:46 -0600

> well, we could discuss the use of an IETF session setup protocol for instant messaging, and the use of a protocol designed to add attributes and report on available bandwidth within a class of traf…

So, without agreeing or disagreeing with your examples: that's all 
rather orthogonal to what I was suggesting in my original message. The 
point I was trying to make is that there is a highly relevant open issue 
under discussion in the RAI area right now. That discussion would 
benefit greatly from general architectural guidance. The present IAB 
recommendation does not address this class of issue unambiguously.

/a