I'd like to see something similar to what was done with HTTP (cf.
https://tools.ietf.org/html/rfc7230#section-1 ), in which one or two
foundational documents lay out the core concepts and data structures and
then cross-link with others that flesh out more specialized aspects with
an intent to p
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 this on ourselves if
> we
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
> of RFC's, or coul
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 better
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 cons
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, incorpor
On 31 March 2018 at 17:27, Paul Vixie wrote:
>
>
>>
>> I think the RFC series as a whole needs to contain both, but I'm not
>> saying that both should exist simultaneously for any given set of
>> documents within the RFC series.
>>
>
> i think you are.
I'm really not.
>
>
> I think we've reac
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 I
Matthew Pounsett wrote:
On 28 March 2018 at 14:48, Paul Vixie mailto:p...@redbarn.org>> 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
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 ARIN PPML. i think yo
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 bui
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 add
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 un
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" without
>> actually
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, T
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 g
Matthew Pounsett wrote:
On 27 March 2018 at 17:33, Paul Vixie mailto:p...@redbarn.org>> 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 diff
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 new document that re
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 tha
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, Ondřej Surý wrote:
>>
>>
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
> the same time tend
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 d
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 and
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 then
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
deprecating-obsolete-rr-typ
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 ass
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 an equally specific next
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 subscribe
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 bottles
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 is
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. Th
34 matches
Mail list logo
