bert hubert wrote:
... So my first suggested action is: could we write a document that has a core introduction of DNS and then provides a recommended (not) reading list. Secondly, what we've been doing already, is grouping the various standards in categories. Read this if you are doing X. This could go in the first document.
i agree with your observations, and i like your first and second suggested actions.
Thirdly, this may lead to a category of RFCs that you might be better off not reading or implementing. I don't know if writing a draft that specifically obsoletes record types or features that are never used is helpful. In fact, adding MORE documents to the pile (even if meant to make life easier) may be counterproductive. But simply noting that something should not be implemented anymore would do rhe trick.
let's consider marking some things as mandatory to implement, and then anything not so marked will be, by exclusion there, optional to implement. this is not the same as deprecation, and comports with your later observation as follows...
Finally, with Job Snijders, I am very much in favour of mandating interoperable implementations as a requirement for standards action. There is a whole bunch of reasons for this. For starters, how can we know if an idea is good without having tried it?
....but, i think that multiple interoperable implementations is already a minimum benchmark, and i think it's IETF-wide, not optional, and has always been in effect here.
what i'd like is something more. KEY, SIG and NXT had multiple interoperable implementations, but were not actually functional in any end-to-end way, and were thus replaced by RRSIG, DNSKEY, DS, and NSEC. later we moved the target and added NSEC3 and then NSEC3PARAM.
so while multiple interoperable implementations are a minimum benchmark, i'd like to see some kind of scale model as well. making something work on a whiteboard, or in a test lab, or on one's laptop, does not mean it will work on today's or tomorrow's internet.
this just amplifies my interpretation of your term, "having tried it."
Secondly, getting implementations to support this is an instant damper on ideas which would not get traction with implementations later on.
sadly, this is not so -- thus the above "scale model" requirement.
And thirdly, I think it is extremely educational to experience how a feature that is 'easy' on the authoritative side (say, DNS Multiple QTYPEs) absolutely sucks and leads to probing on the resolver side - requiring whole factors more code than the spec is actually about.
this again goes to scale modeling and the definition of "having tried it."
Thoughts?
anybody can complain about the weather, but very few of us try to change it. thanks for your contribution to complexity considerations.
-- P Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
