On 31 March 2018 at 17:34, bert hubert wrote:
> First, I agree it is necessary. I don't think anyone would really disagree.
> The issue is the stupendous amount of work it would be and if we are going
> to do it.
>
> A secondary question is how hard we are going to make
On 31 March 2018 at 22:02, Paul Vixie wrote:
>
> furthermore, the IETF would have to update some STD document every time a
> new DNS-related RFC was published, just to enumerate the full set of things
> a new implementer should study and consider. that STD could be just a list
Matthew Pounsett wrote:
there's a carrier wave in that time series, which has its own wave
form. at the end of each epoch, we'll be back where we are today,
without a coherent or complete document set. we'd be moving from
failing to plan, to planning to fail. let's make a
On 03/31/2018 07:34 PM, Mukund Sivaraman wrote:
> All the clarifications RFCs such as NCACHE 2308, 2181, wildcards 4592,
> etc. I'd also expect TSIG, AXFR, IXFR and UPDATE to get treatment in
> "core" DNS in the same grouping as master files.
>
Just offhand, IPv6 stuff should be merged and
On Sat, Mar 31, 2018 at 11:34:29PM +0200, bert hubert wrote:
> On Sun, Apr 01, 2018 at 02:39:06AM +0530, Mukund Sivaraman wrote:
> > Just a "guide to the RFCs" won't be sufficient. Language has to be
> > corrected; large parts of RFC 1034 and 1035 have to be rewritten and
> > restructured,
On Sun, Apr 01, 2018 at 02:39:06AM +0530, Mukund Sivaraman wrote:
> Just a "guide to the RFCs" won't be sufficient. Language has to be
> corrected; large parts of RFC 1034 and 1035 have to be rewritten and
> restructured, incorporating clarifications from newer RFCs. It would be
> a big work, but
Matthew Pounsett wrote:
On 28 March 2018 at 14:48, Paul Vixie > wrote:
matt, the rfc document set is innately time-series. this was seen as
a strength compared to some "document set in the sky" that would be
updated periodically with
On 28 March 2018 at 14:48, Paul Vixie wrote:
> matt, the rfc document set is innately time-series. this was seen as a
> strength compared to some "document set in the sky" that would be updated
> periodically with lineouts and additions, like for example legal codes or
> the
On Wed, Mar 28, 2018 at 04:38:24AM -0400, Tim Wicinski wrote:
>
> 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
matt, the rfc document set is innately time-series. this was seen as a
strength compared to some "document set in the sky" that would be
updated periodically with lineouts and additions, like for example legal
codes or the ARIN PPML. i think you're very close to saying we need the
latter in
tjw ietf wrote:
I should qualify my comments on Route 53 - I don't think they are
something we should emulate, more of an example of how 3rd party vendors
get away with an overly-minimal set of resource records. The words I
have to describe them are generally not polite.
i remember being
On 27 March 2018 at 20:17, Paul Vixie wrote:
> I think we're discussing the same idea from different perspectives.
>>
>
> i think so, yes.
>
> I think writing a new document that references other documents to say
>> "here's the sections in each of these you need to implement"
I should qualify my comments on Route 53 - I don't think they are something
we should emulate, more of an example of how 3rd party vendors get away
with an overly-minimal set of resource records. The words I have to
describe them are generally not polite.
Tim
On Wed, Mar 28, 2018 at 4:38 AM,
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
Matthew Pounsett wrote:
On 27 March 2018 at 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.
I think we're discussing the
On 27 March 2018 at 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.
I think we're discussing the same idea from different perspectives.
I think writing a
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
On 27 Mar 2018, at 9:02, Andrew Sullivan wrote:
On Mon, Mar 26, 2018 at 05:46:45PM +0200, 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.
Maybe we could, but we failed at
Definitely. I didn’t mean to rewrite 1:1, but take existing content and do m:n
including splitting and combining existing RFCs into new document(s).
Ondřej
--
Ondřej Surý — ISC
> On 27 Mar 2018, at 18:19, Matthew Pounsett wrote:
>
>
>
>> On 27 March 2018 at 03:49,
On 27 March 2018 at 03:49, Ondřej Surý 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
>
Hi,
On Mon, Mar 26, 2018 at 05:46:45PM +0200, 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.
Maybe we could, but we failed at that once before.
After the DNSSEC work wound
Paul Wouters wrote:
On Mon, 26 Mar 2018, Paul Vixie wrote:
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
On Mon, 26 Mar 2018, Paul Vixie wrote:
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
On Tue, 27 Mar 2018, Ondřej Surý wrote:
I strongly believe that any work on cleaning up DNS protocol and/or rewriting
RFC1034/RFC1035 and associated document would need a new WG with tightly
defined charter.
Hence, I will not request or I won’t support adopting my
Hi Suzanne,
> If the WG feels that the previous view of how DNSOP should work has been
> overtaken by events, we can certainly work with our Area Director (hi
> Warren!) on a revised charter.
I strongly believe that any work on cleaning up DNS protocol and/or rewriting
RFC1034/RFC1035 and
On Tue, Mar 27, 2018 at 2:26 AM, Suzanne Woolf wrote:
> The current DNSOP charter was deliberately written
> to be flexible in what we could work on. Normally an
> IETF WG is chartered to perform a fairly tightly
> constrained piece of work and then either re-charter
> to
Hi all,
First, thanks for running with this.
Top-posting a couple of process observations:
First, the chairs are always open to discussion of what documents belong in the
WG, interpretation/revision of our charter, etc. There’s a certain amount of
process to be observed, especially if we want
So, a couple of thoughts as a newcomer to the list, and someone who's
wading through the virtual forest that is the DNS RFC specifications.
Breaking into the DNS world is to put it ... difficult. I thought myself
relatively knowledgeable on the subject up until about two weeks ago
when I
Martin Hoffmann wrote:
...
So, I'll step on that mine: What really would help new implementers
is a 1034bis.
i sympathize with this view, but here's my worry:
That having been said, a stronger document set written today would
not be able to put all of the DNS genies back into their
On Mon, Mar 26, 2018 at 09:13:31AM -0700, Paul Vixie wrote:
> > 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
bert hubert wrote:
>
> I've been looking at the amount of DNS out there, and I think we can
> do several things with them. I've also concluded that the mediocrity
> of DNS implementations outside of the well-known ones can not be
> fully blamed on "stupid programmers". The fact that we've offered
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.
Hi everyone,
I've been looking at the amount of DNS out there, and I think we can do
several things with them. I've also concluded that the mediocrity of DNS
implementations outside of the well-known ones can not be fully blamed on
"stupid programmers". The fact that we've offered the world
33 matches
Mail list logo