On Tue, Dec 13, 2016 at 07:16:37PM +,
Warren Kumari wrote
a message of 132 lines which said:
> The authors think that they have captured / addressed everyone's
> comments - if we missed (or misunderstood) anything, it was
> unintentional.
One of my comments was not addressed. I would like
Hi,
On 20-12-16 11:59, Stephane Bortzmeyer wrote:
> One of my comments was not addressed. I would like, in section 10, see
> some details about what exactly is implemented by Unbound and Google
> Public DNS:
>
> * synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
> * synthesis of NX
> On 20 Dec 2016, at 06:40, ac wrote:
>
> my reply and opposition to the publication of the draft is that it is not
> ethical.
In that case, I suggest the WG notes your objection and otherwise ignores it.
You don’t have a veto anyway: nobody does.
The rest of us should now be able to get on
On Dec 20, 2016, at 1:45 AM, ac wrote:
> It is not really an argument to say just because someone else has no
> ethics it is also okay for me not to have ethics.
Andre, you still haven’t given any reason why the IETF should care about your
ethical beliefs. I’ve asked you several times privatel
On Tue, 20 Dec 2016 07:49:59 -0500
Ted Lemon wrote:
> On Dec 20, 2016, at 1:45 AM, ac wrote:
> The point is that while you may believe that domains names are
> property, and that a DNS server administrator who doesn’t honor that
> property right is stealing, nobody here agrees with you, and by an
On Tue, 20 Dec 2016, Stephane Bortzmeyer wrote:
One of my comments was not addressed. I would like, in section 10, see
some details about what exactly is implemented by Unbound and Google
Public DNS:
* synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
* synthesis of NXDOMAIN from
Why not just wade into this discussion...
The draft is being present as "Informational", and the point here is to
document current working behavior in the DNS (for the past several years).
It is obvious that some feel this draft is a large mistake, but like
edns-client-subnet, more operators are
On Tue, Dec 20, 2016 at 10:14:16AM -0500,
Paul Wouters wrote
a message of 16 lines which said:
> > One of my comments was not addressed. I would like, in section 10, see
> > some details about what exactly is implemented by Unbound and Google
> > Public DNS:
> >
> > * synthesis of NXDOMAIN fr
> On Dec 20, 2016, at 10:16 AM, tjw ietf wrote:
>
> Why not just wade into this discussion...
>
> The draft is being present as "Informational", and the point here is to
> document current working behavior in the DNS (for the past several years).
> It is obvious that some feel this draft is
On 20/12/2016 15:16, tjw ietf wrote:
> This starts a Call for Adoption for draft-vixie-dns-rpz
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the l
On Tue, 20 Dec 2016, Stephane Bortzmeyer wrote:
One of my comments was not addressed. I would like, in section 10, see
some details about what exactly is implemented by Unbound and Google
Public DNS:
* synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
* synthesis of NXDOMAIN from
> On 20 Dec 2016, at 15:29, Ray Bellis wrote:
>
> On 20/12/2016 15:16, tjw ietf wrote:
>
>> This starts a Call for Adoption for draft-vixie-dns-rpz
>>
>> Please review this draft to see if you think it is suitable for adoption
>> by DNSOP, and comments to the list, clearly stating your view.
>
On 20 December 2016 at 10:37, Jim Reid wrote:
>
> > On 20 Dec 2016, at 15:29, Ray Bellis wrote:
> >
> > On 20/12/2016 15:16, tjw ietf wrote:
> >
> >> This starts a Call for Adoption for draft-vixie-dns-rpz
> >>
> >> Please review this draft to see if you think it is suitable for adoption
> >> by
On Tue, 20 Dec 2016, Suzanne Woolf wrote:
The draft is being present as "Informational", and the point here is to
document current working
behavior in the DNS (for the past several years). It is obvious that some
feel this draft is a
large mistake, but like edns-client-subnet, more operators
On 12/20/2016 at 10:17 AM, "tjw ietf" wrote:
The draft is available
here:https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/
Please review this draft to see if you think it is suitable for
adoption by DNSOP, and comments to the list, clearly stating your
view.
Please also indicate if you are
On 20 Dec 2016, at 7:16, tjw ietf wrote:
Please review this draft to see if you think it is suitable for
adoption by
DNSOP, and comments to the list, clearly stating your view.
The draft itself is really not suitable for adoption by the WG. Just
slapping "Informational" on the document is in
On 20/12/2016 16:33, Paul Hoffman wrote:
> Counter-question: of what value is documenting this current practice?
> Anyone who is already using it can find the documentation for it from
> their software vendor. There is nothing here that really affects the
> rest of the DNS other than "there will
On 12/20/16 11:35 AM, Ray Bellis wrote:
On 20/12/2016 16:33, Paul Hoffman wrote:
Counter-question: of what value is documenting this current practice?
Anyone who is already using it can find the documentation for it from
their software vendor. There is nothing here that really affects the
r
On 20 Dec 2016, at 8:35, Ray Bellis wrote:
The document primarily covers BIND's behaviour.
Noted. That seems like a good reason for ISC to document it.
It would be good if other implementations were completely compatible
with that,
Is this so that different implementations use the same mas
On 20/12/2016 17:43, Paul Hoffman wrote:
> On 20 Dec 2016, at 8:35, Ray Bellis wrote:
>
>> The document primarily covers BIND's behaviour.
>
> Noted. That seems like a good reason for ISC to document it.
ISC isn't the current custodian of the specification. Vixie and VJS are.
>> It would be
On Tue, Dec 20, 2016 at 09:43:25AM -0800, Paul Hoffman wrote:
> On 20 Dec 2016, at 8:35, Ray Bellis wrote:
>
> >The document primarily covers BIND's behaviour.
>
> Noted. That seems like a good reason for ISC to document it.
No it doesn't. It also documents the exact PowerDNS behaviour. RPZ is a
On Tue, 20 Dec 2016, bert hubert wrote:
On Tue, Dec 20, 2016 at 09:43:25AM -0800, Paul Hoffman wrote:
On 20 Dec 2016, at 8:35, Ray Bellis wrote:
The document primarily covers BIND's behaviour.
Noted. That seems like a good reason for ISC to document it.
No it doesn't. It also documents th
On 20 Dec 2016, at 9:46, bert hubert wrote:
On Tue, Dec 20, 2016 at 09:43:25AM -0800, Paul Hoffman wrote:
On 20 Dec 2016, at 8:35, Ray Bellis wrote:
The document primarily covers BIND's behaviour.
Noted. That seems like a good reason for ISC to document it.
No it doesn't. It also document
On 20/12/2016 18:46, Paul Hoffman wrote:
> It is statements like this which show that this WG working on this as an
> "Informational RFC" is dishonest and is sure to lead to massive
> dissatisfaction with the result.
AIUI, the authors *could* just request that it go AD Sponsored via the
Indepen
On Tue, Dec 20, 2016 at 5:59 AM Stephane Bortzmeyer
wrote:
> On Tue, Dec 13, 2016 at 07:16:37PM +,
> Warren Kumari wrote
> a message of 132 lines which said:
>
> > The authors think that they have captured / addressed everyone's
> > comments - if we missed (or misunderstood) anything, it w
On 20 Dec 2016, at 10:54, Ray Bellis wrote:
On 20/12/2016 18:46, Paul Hoffman wrote:
It is statements like this which show that this WG working on this as
an
"Informational RFC" is dishonest and is sure to lead to massive
dissatisfaction with the result.
AIUI, the authors *could* just reque
On Tue, Dec 20, 2016 at 10:17 AM tjw ietf wrote:
> Why not just wade into this discussion...
>
> The draft is being present as "Informational", and the point here is to
> document current working behavior in the DNS (for the past several years).
> It is obvious that some feel this draft is a la
>"Not wanting to be recruited into a botnet" is another such consideration.
>Paul and Vernon invented a useful tool to help address it, and I'm
>in favor of documenting it.
I would really prefer that the IETF not embarrass itself with a rerun
of the NAT fiasco, in which TCP/IP purists yelled and s
+1
Regards,
-drc
(speaking only for myself)
> On Dec 20, 2016, at 4:02 PM, John Levine wrote:
>
>> "Not wanting to be recruited into a botnet" is another such consideration.
>> Paul and Vernon invented a useful tool to help address it, and I'm
>> in favor of documenting it.
>
> I would really
+1
I agree this is ugly as ugly can be but that ship has sailed.
For interoperability sake lets just publish this with a note that says
something like this;
This is documentation of fielded useful protocol.
This is ugly protocol and it copying it is strongly discouraged.
Olafur
> On Dec
On Tue, 20 Dec 2016 22:10:20 -0500
Olafur Gudmundsson wrote:
> +1
> I agree this is ugly as ugly can be but that ship has sailed.
> For interoperability sake lets just publish this with a note that
> says something like this;
>
> This is documentation of fielded useful protocol.
> This is ugly
Moin!
On 20 Dec 2016, at 17:33, Paul Hoffman wrote:
On 20 Dec 2016, at 7:16, tjw ietf wrote:
Please review this draft to see if you think it is suitable for
adoption by
DNSOP, and comments to the list, clearly stating your view.
The draft itself is really not suitable for adoption by the W
On Tue, Dec 20, 2016 at 10:46:40AM -0800, Paul Hoffman wrote:
> >Unbound is also slated to have support for RPZ.
> Unbound can document it or point to the ISC documentation.
We might as well stop doing standards all together then. We have something
that works. It interoperates. There is an ecosyst
On Tue, Dec 20, 2016 at 01:12:06PM -0500, Paul Wouters wrote:
> One would hope it interops, as this document only describes an IXFR/AXFR
> of a zone with existing RRTYPEs with some semantics associated to CNAME
> records for other applications (such as DNS servers)
The "some semantics" parts are w
34 matches
Mail list logo
