draft-ietf-opsawg-operations-and-management

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