Hi Benoit and friends,As someone who has a lot of sympathy for operators running our stuff (being polite), I read your draft. I've already been thinking about this a bit, and so the timing is good. That having been said, I do have a few thoughts that I've organized into directorate-reviewish comments.
&TL;DR *Not ready, but there's some great text in the draft.*
Major
* I am not entirely certain that you are looking for an "Operational
Considerations" section so much as the answer within the IETF prior
to publication to the question, “Did you consider how this
specification would be used in the field?” That is, in general, the
question I would expect ops directorate reviewers to ask, and
there's a lot of good discussion in this document on how to help
them evaluate answers, not to mention for the authors to know what
they should be thinking about. RFC 1958’s advice on avoiding
options was and remains *excellent*. But the discussion about
whether to have an option needs to be within the working group, and
the text around how to use an option should (IMHO) be proximate to
its specification, and not divorced. If it's really complex to use,
requiring a lot of text, then RFC 1958 seems to apply even more.
* Not all of the examples in the document support an Operational
Considerations section. Case and point is the reference to RFC2439
in Section 4. Can you think of any text that would have gone into
an Operational Considerations that would have changed the outcome
that is described. In fact, arguably a substantial portion of that
Proposed Standard addresses operational considerations! There's
configuration examples, processing costs, etc.
* RFC2439 also demonstrates something else, and it is not alone:
sometimes we do not fully understand how a protocol will be used in
the wild. You properly cite RFC *5218* (one of my favorite RFCs
*ever* (we should have a contest!)), but that document makes clear
the difficulty: imagine having had this requirement for RFCs 822 or
1945. Not only did we not know what the operational considerations
should be, we did not know what we did not know! Sometimes the
operational considerations are in the application of the
specification, and not within the sole context of the specification
itself, and I am specifically concerned about this when it comes to
Section 4.5.
* Similarly, the discussion about coexistence is tricky, and somewhat
relates to not only RFC 5218 but the workshop the IAB held some time
ago on Internet Technology Adoption and Transition (RFC 7305). You
might need an entire RFC to discuss the effects of transitioning at
at the IP layer, requiring that the discussion be deferred or simply
placed elsewhere. Indeed we have an entire working group for v6
operations! For little stuff, it might just require some normative
behavior definitions here or there.
* Regarding Section 4.4, I just chastised authors for "burying the
lede" in terms of stating what the requirements to run a protocol
are. And this one gets hairy. A good example is certificates and
time. Is NTP required or is roughtime required? And if so, if you
bury that in operational considerations, might it waste a lot of
time (so to speak)? I like the idea of listing out that sort of
dependency right up front.
* Also, there's this bit:
Tooling required by security operators should be documented in the
design and deployment of a New Protocol or Protocol Extension.
That's great as a concept, but it seems to me has the lingering
effect of delaying the publication of work as an RFC because
E-LACKOFTOOLING. BTW, I'm all for tooling, but indications of
exploit evolve and are a lagging technology because we may not know
how the specification will be exploited.
* Similarly, with network management, it may be that the subject
requires a lot of consideration once there is in fact operational
experience. Prematurely writing that down can lead people down the
wrong path, and worse an ossified path at that.
What does all of this boil down to? There's some *really great* text in
the draft. Perhaps required reading for authors and WG chairs. Don't
lose that! It's good stuff. I just don't think an Operational
Considerations section is the best way to deliver the result. Also, I
think you might want to promote the idea of entire "Operational
Considerations" RFCs being delivered in certain cases.
Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
