I have looked at the same problem Bert has, but he did present it much
better than I could. When I started thinking about this, I approached
it from the point of view of "If I have to give a co-worker a document
on how to build a DNS Server (Authoritative or Resolver), what would I
need to give them". I also have spent a lot of time watching the
793bis work in TCPM, which has been moving along slowly and
methodically. I felt what we would come up with would be
1. a DNSOP document which would be an implementation list for
building an Authoritative or Resolver
2. a roadmap to work on 1034bis and 1035bis, which would be a new WG.
I also realized that the second item would be brutal, painstaking, not
"sexy" for most IETF standard types.
I've had lots of experience dealing with the concept of "technical debt"
and a lot of this is very similar. But we also need someone who has the
skill set of a project manager, who knows how to lay out workflows.
That's not something a bunch of programmers always have.
Summary - Paul is on the right track here. A good example is looking
at what Route 53 implements (for better or for worse) and realize they
implement some real minimal subset. I think it's too small, but it's
an interesting argument.
tim
On 3/27/18 17:33, Paul Vixie wrote:
i see no purpose in change documents, which would add to the set of
things a new implementer would have to know to read, and then to read.
rather, we should focus on a DNSOP document set that specifies a
minimum subset of DNS which is considered by the operational community
to be mandatory to implement. any implementer can remove anything else
and still be checklist-compatible when customers are baking things off.
if someone wants to implement iquery or WKS let that be crazy rather
than broken -- on-the-wire patterns still described, code points still
reserved, but unlikely to find anybody to actually interoperate with.
vixie
re:
Matthew Pounsett wrote:
On 27 March 2018 at 03:49, Ondřej Surý <ond...@isc.org
<mailto:ond...@isc.org>> wrote:
Again, from experience from dnsext, I would strongly suggest that
any work in this area is split into CHANGE documents and REWRITE
documents, with strict scope. Documents rewriting existing RFCs
while adding more stuff at the same time tend to not reach the
finish line.
Does this include combining documents? For example, it would probably
make sense to combine some of the clarifications documents into any
rewrite of 1034/1035.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
