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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf