This is relevant to the Special-Use registry discussion. (Which is mentioned,
in a negative way.)
http://www.circleid.com/posts/20170312_and_the_wait_continues_for_corp_home_and_mail_applicants/___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org
On 13/03/2017 05:35, william manning wrote:
> Joel,
>
> I'd be happy to see the document proceed under two conditions: 1) it
> becomes a WG document, subject to IETF change control, and 2) that the
> disclaimer requested back on 20170103 be added to the document. To
> refresh the collective mind,
Hi,
On Sun, Mar 12, 2017 at 10:35:19PM -0700, william manning wrote:
> Joel,
>
> I'd be happy to see the document proceed under two conditions: 1) it
> becomes a WG document, subject to IETF change control
Without my IAB hat on, I should think that is self-evident. If a WG
adopts a document, i
On Mon, 13 Mar 2017, Stéphane Bortzmeyer wrote:
To: dnsop@ietf.org
Subject: [DNSOP] And the Wait Continues for .Corp, .Home and .Mail Applicants
This is relevant to the Special-Use registry discussion. (Which is mentioned,
in a negative way.)
http://www.circleid.com/posts/20170312_and_the_wai
> On 13 Mar 2017, at 09:33, Paul Wouters wrote:
>
> It's quite clear if vendor Foo starts using .foo and tainting
> it, no one would faciliate them into using that to obtain a new domain.
Indeed. If anything, anyone generating "too much" traffic for .foo would almost
certainly cause that strin
> On 13 Mar 2017, at 07:05, Stéphane Bortzmeyer wrote:
>
> This is relevant to the Special-Use registry discussion. (Which is mentioned,
> in a negative way.)
Meh. I fail to understand how the problems that the applicants for these
strings made for themselves could be in scope for this WG or
On Sun, 12 Mar 2017, Dave Crocker wrote:
On 3/12/2017 4:23 PM, Paul Wouters wrote:
I do not want to adopt it unmodified
as informational RFC for running existing code.
You do not want the IETF to document existing practice?
Really?
There is a fine line between "bringing existing things to
> On Mar 12, 2017, at 7:10 AM, Jari Arkko wrote:
>
> For what it is worth, reviewed these documents today
> as an interested individual, and both seem to be OK
> from my (very limited DNS expertise) perspective.
>
> Thanks for your work on this important space.
And thank you for your review an
Hi,
Per assorted comments in this thread….a couple of observations from one WG
chair.
It’s my sense at least that the WG was clear that there’s some interest in
publishing an informational document about RPZ, given that it’s widely deployed
and considered useful by certain admins in certain si
Disclaimer: As a BIND developer, I've been co-maintaining RPZ for a few
years now (and have exposure to how it's used/deployed in various
places). I don't like these DNS tricks (ECS, RPZ, etc.) at all; they
reduce the elegance of DNS, but I've learned over the years that some
things are a practical
On 3/13/2017 4:11 AM, Paul Wouters wrote:
The draft breaks DNSSEC.
...
I have proposed a method that would not change the RPZ response for a
non-DNSSEC client, but would add data for DNSSEC capable clients to be
That sounds like an excellent bit of technical enhancement to
consider... /afte
> On Mar 13, 2017, at 15:44, Dave Crocker wrote:
>
>> On 3/13/2017 4:11 AM, Paul Wouters wrote:
>> The draft breaks DNSSEC.
> ...
>> I have proposed a method that would not change the RPZ response for a
>> non-DNSSEC client, but would add data for DNSSEC capable clients to be
>
>
> That sounds
On 13 Mar 2017, at 7:44, Dave Crocker wrote:
On 3/13/2017 4:11 AM, Paul Wouters wrote:
The draft breaks DNSSEC.
...
I have proposed a method that would not change the RPZ response for a
non-DNSSEC client, but would add data for DNSSEC capable clients to
be
That sounds like an excellent bi
On 3/13/2017 8:07 AM, Paul Hoffman wrote:
On 13 Mar 2017, at 7:44, Dave Crocker wrote:
On 3/13/2017 4:11 AM, Paul Wouters wrote:
The draft breaks DNSSEC.
...
I have proposed a method that would not change the RPZ response for a
non-DNSSEC client, but would add data for DNSSEC capable clients
On 13.3.2017 16:12, Dave Crocker wrote:
> On 3/13/2017 8:07 AM, Paul Hoffman wrote:
>> On 13 Mar 2017, at 7:44, Dave Crocker wrote:
>>> On 3/13/2017 4:11 AM, Paul Wouters wrote:
The draft breaks DNSSEC.
>>> ...
I have proposed a method that would not change the RPZ response for a
n
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Aggressive use of DNSSEC-validated Cache'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please se
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.
Title : DNS Terminology
Authors : Paul Hoffman
Andrew Sullivan
On 3/13/2017 7:58 AM, Paul Wouters wrote:
On Mar 13, 2017, at 15:44, Dave Crocker wrote:
On 3/13/2017 4:11 AM, Paul Wouters wrote:
The draft breaks DNSSEC.
...
I have proposed a method that would not change the RPZ response for a
non-DNSSEC client, but would add data for DNSSEC capable client
> On Mar 13, 2017, at 4:11 AM, Paul Wouters wrote:
>
> The draft breaks DNSSEC
The draft does not break DNSSEC. How version of DNS software implement RPZ can
have issues with DNSSEC. There are some software that can inject a RPZ feed and
not break DNSSEC.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.
Title : Special-Use Domain Names Problem Statement
Authors : Ted Lemon
Ralph Drom
On Sun, Mar 12, 2017 at 04:38:20PM -0700, Dave Crocker wrote:
> On 3/12/2017 4:23 PM, Paul Wouters wrote:
> > I do not want to adopt it unmodified
> > as informational RFC for running existing code.
>
> You do not want the IETF to document existing practice?
In general, yes. However, in this ca
FYI.
Some of you may be aware that there are at least a couple of patents
in this area (US8972580 and US8832283), and we'll be handling them
through the usual IETF IPR disclosure process.
--- start of forwarded message (RFC 934 encapsulation) ---
From:
Subject: New Version Notification f
On 3/13/17 7:07 AM, Paul Hoffman wrote:
> Why "after" and not "during"? That is, if the WG document tells how this
> one method of achieving a set of goals works, why not also document
> other options that could have, and might in the future, be adopted? That
> would certainly give the reader more
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.
Title : DNS Session Signaling
Authors : Ray Bellis
Stuart Cheshire
On 3/13/2017 4:07 PM, Melinda Shore wrote:
I have to say that I find it a little odd that a document
constrained to describing current practice or a currently deployed
protocol would be adopted by a working group - usually I'd
expect that to be an individual submission. The benefits
brought by g
On 3/13/2017 1:28 PM, Viktor Dukhovni wrote:
Whether we like it or not,
publication of said existing practice by the IETF will be seen as
an endorsement of that practice.
This kind of assertion is frequently made, but never demonstrated with
anything other than theory or anecdotes, the latter
26 matches
Mail list logo
