David W. Hankins wrote:
I certainly would say that, given what we can observe as users, the
possible explanations for the DNS and DHCP service outages reside in
a _very_ limited set; hardware, software, configuration, or some
None of those are "IETF business" in the sense of things which we can
observe or change through "Reviewing our protocols and
specifications" as John Klensin appears to have suggested.
doesn't follow. in particular, I don't think we in IETF pay nearly
enough attention to architecture, nor to making our protocols easy to
DHCP, in particular, strikes me as a nightmare - a hodgepodge of
unrelated attributes, many of which have no business being dictated to
hosts by the network. gluing DHCP to DNS creates another set of
problems, also based on dubious assumptions about the relationship
between a host's identity and the attachment point of a host to the
network. and this all strikes me as a consequence of developing network
configuration protocols "organically", i.e. without much forethought.
now it might be that this specific incident has little to do with the
lack of a configuration architecture in IP. but I do think that IETF
would do well to analyze such incidents when they do occur and try to
learn from them. such lessons might impact future protocol designs at
both an architectural and a detailed level.
more broadly, I wish there were a better feedback path from operators to
IETF to take advantage of the breadth of operational experience. it's
not as if the incidents occurring in IETF meeting networks are typical;
it's just that we experience them directly and as a group rather than
indirectly or as individuals.
Ietf mailing list