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
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 1000-2
35 matches
Mail list logo
