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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf