On Thu, Mar 29, 2018 at 10:36:12AM +1100, Mark Andrews wrote:
>
> > On 29 Mar 2018, at 9:05 am, Frederico A C Neves wrote:
> >
> > On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
> >> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> >>> No. You can have multip
On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote:
> > One comment,
> >
> > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text
> > regarding NSEC3PARAM update as well.
> >
> > For that I suggest to change 3.1 section name and include an extra
> > paragraph.
> >
> On 29 Mar 2018, at 9:05 am, Frederico A C Neves wrote:
>
> On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
>> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
>>> No. You can have multiple nsec3 chains in a zone at the same time. Only one
>>> is active. Some
On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> > No. You can have multiple nsec3 chains in a zone at the same time. Only one
> > is active. Some may be incomplete.
> >
> > Named builds and destroys chains i
On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> No. You can have multiple nsec3 chains in a zone at the same time. Only one
> is active. Some may be incomplete.
>
> Named builds and destroys chains incrementally to avoid large changes.
>
> Timely ness of changes is more impo
No. You can have multiple nsec3 chains in a zone at the same time. Only one is
active. Some may be incomplete.
Named builds and destroys chains incrementally to avoid large changes.
Timely ness of changes is more important than volume of changes.
--
Mark Andrews
> On 29 Mar 2018, at 02:0
Tony Finch wrote:
...
I still prefer the name "UXFR (update-style IXFR)" :-)
:-). +1, if we're voting.
--
P Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote:
> > One comment,
> >
> > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text
> > regarding NSEC3PARAM update as well.
> >
> > For that I suggest to change 3.1 section name and include an extra
> > paragraph.
> >
On 28/03/2018 15:43, Pieter Lexis wrote:
> The draft speaks of an OPCode in the IANA section and of a meta
> RRType in the examples and Introduction section, which is it?
>
> If it is an RRType, some words need to be added about the fact that
> current resolvers will pass through the MIXFR query
Frederico,
On 03/28/2018 05:06 PM, Frederico A C Neves wrote:
Hi Matthijs,
On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
All,
It's been a while, but I have put up a new version of the MIXFR draft:
https://tools.ietf.org/html/draft-mekking-mixfr-02
The IETF 101 Hack
Richard,
On 03/28/2018 04:44 PM, Richard Gibson wrote:
I really like this document, especially the changes to version 02.
Thanks:)
One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH
must be non-zero" _and_ that "The same syntax is used to delete an RRset
and to replace an
Pieter,
On 03/28/2018 04:43 PM, Pieter Lexis wrote:
Hi Matthijs,
On Wed, 28 Mar 2018 15:31:57 +0200
Matthijs Mekking wrote:
It's been a while, but I have put up a new version of the MIXFR draft:
https://tools.ietf.org/html/draft-mekking-mixfr-02
The draft speaks of an OPCode in the
Tony,
On 03/28/2018 04:08 PM, Tony Finch wrote:
Matthijs Mekking wrote:
It's been a while, but I have put up a new version of the MIXFR draft:
https://tools.ietf.org/html/draft-mekking-mixfr-02
I've had a quick skim and it looks nice.
Thanks.
Suggestions for 2nd paragraph of intr
Hi Matthijs,
On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
> All,
>
> It's been a while, but I have put up a new version of the MIXFR draft:
>
> https://tools.ietf.org/html/draft-mekking-mixfr-02
>
> The IETF 101 Hackathon lead to the revival of this draft.
>
> Changes
I really like this document, especially the changes to version 02.
One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH
must be non-zero" _and_ that "The same syntax is used to delete an RRset
and to replace an RRset with an RR whose RDLENGTH is zero". I think the
former should
On Wed, Mar 28, 2018 at 04:43:53PM +0200, Pieter Lexis wrote:
> Hi Matthijs,
>
> On Wed, 28 Mar 2018 15:31:57 +0200
> Matthijs Mekking wrote:
>
> > It's been a while, but I have put up a new version of the MIXFR draft:
> >
> > https://tools.ietf.org/html/draft-mekking-mixfr-02
>
> The dra
"Transport of a query may be by either UDP or TCP. If an IXFR query
is via UDP, the IXFR server may attempt to reply using UDP if the
entire response can be contained in a single DNS packet. If the UDP
reply does not fit, the query is responded to with a single SOA
record of the serve
Hi Matthijs,
On Wed, 28 Mar 2018 15:31:57 +0200
Matthijs Mekking wrote:
> It's been a while, but I have put up a new version of the MIXFR draft:
>
> https://tools.ietf.org/html/draft-mekking-mixfr-02
The draft speaks of an OPCode in the IANA section and of a meta
RRType in the examples an
Matthijs Mekking wrote:
>
> It's been a while, but I have put up a new version of the MIXFR draft:
>
> https://tools.ietf.org/html/draft-mekking-mixfr-02
I've had a quick skim and it looks nice.
Suggestions for 2nd paragraph of intro:
To keep the deltas small in zone transfers, we need t
All,
It's been a while, but I have put up a new version of the MIXFR draft:
https://tools.ietf.org/html/draft-mekking-mixfr-02
The IETF 101 Hackathon lead to the revival of this draft.
Changes after the three year sleep:
- I removed the IXFR Gone Wild section. This document should focus i
20 matches
Mail list logo
