draft-ietf-opsawg-operations-and-management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]