While I'm all in favor of considering configurability and
manageability in designing protocols, I have some concern that this
document may have unintended side effects, namely more boiler plate
and more delays in protocol standardization.
The document does not seem to distinguish between the two kinds of
protocol documents we tend to write these days:
(1) fully new protocols (e.g., RELOAD, NSIS, LoST and HELD, to cite
four somewhat recent examples I'm familiar with); we seem to do less
and less of that.
(2) extensions and enhancements to existing protocols (probably 90% of
the current IETF work)
While Security Considerations are necessary and appropriate for both
(1) and (2), Manageability Considerations are mostly relevant to
efforts of type (1). It is not clear to me that adding more
boilerplate (and IESG DISCUSSes) on yet another DHCP extension or SIP
draft is all that helpful in anything except bloating the document.
While the document recognizes this to some extent, I'd prefer that the
applicability of these discussions be cast much more narrowly, and
maybe looking at some sample of recent RFCs to see where this would
really be helpful and necessary.
More seriously, I'm concerned that this imposes a new high hurdle to
getting new protocol efforts done, further delaying efforts that can
already take five years. Often, the right models and facilities won't
be known until the protocol has seen some initial deployment. (As an
example, we have a SIP MIB, which seems to be rarely used, and took
years to complete. The SIP deployment model turned out to differ
significantly from the original notions, and it is likely that any
attempt to codify this in the original specification would only have
inflated the already large size of the spec.)
In many cases, it would be much better to get some initial deployment
experience, and then write such documents. I have no objection to
ensuring such considerations are met before a document is promoted to
Draft Standard, for example.
Thus, I think this would be more helpful as a set of guidelines for
protocol design (e.g., "a protocol should have a way to test liveness
within the protocol itself"), rather than one more check-off,
boilerplate, dependency and delaying item.
Before adding higher hurdles to the Proposed stage, maybe we can
identify whether such a mechanism would have solved real issues in
recent protocol design cases, or just delayed an already exceedingly
long process even more. Maybe BCPs imposing new requirements on WGs
need a "Delay Impact Assessment" section...
Henning
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf