Some cautionary comments

["Mark Day" <markday@cisco.com>]

I'm very happy with the overall tone of the discussion that is taking place.

However, for a couple of ideas/approaches that I have seen come up in the
discussion over the last couple of weeks, I think I need to be gently
discouraging.

These are not (necessarily) intrinsically bad ideas, but in the specific
context of an IETF process to develop protocols I foresee trouble from them.

1. Negotiation of parameters

It is often tempting to defer a hard choice in a protocol design by saying
that multiple possibilities will exist, with a negotiation at runtime.  The
unfortunate result is that every implementation has to deal with all the
possibilities.  In addition, negotiation structures complicate the process
of interoperability testing.

I think the most elaborate supportable model here is where *one* side of a
communication presents *one* set of choices to the other side, which then
picks *one* from that set and the negotiation is over for the life of that
communication between those parties.

I'm willing to be convinced otherwise, but I want to avoid casually assuming
that negotiations are a good idea or easily built.

2. Hypothetically useful capabilities

Since we are creating new protocols and enabling new kinds of system to be
built, it is tempting to start imagining entirely new ways of using them.
This can be fun but it's not very functional. To the extent that it's
possible, standards work should be about working through the issues in
well-understood technologies, not inventing new things that haven't existed
before.

While it is a good idea to leave places for others to extend defined
capabilities in the future, we really need to focus on the set of things
that we are pretty sure will be widely useful. As with negotiation, the
tempting behavior is easy for people defining the protocol but causes higher
costs elsewhere in the universe, and it's not a good tradeoff to make.

Thanks for your understanding. We now return you to the more interesting
technical discussions on the list.

--Mark

Mark Stuart Day
Senior Scientist
Cisco Systems
+1 (781) 663-8310
markday@cisco.com