Re: [DNSOP] QNAME minimisation on the standards track?

[manu tman]

I'd like to see this standardized too.

Side note: I would also be interested to get a return of experience from
people operating qname minimization at scale, the type of issues
encountered, what are the ratios of such errors hint @marek :)

Manu

On Tue, Jul 17, 2018 at 2:35 PM Paul Wouters  wrote:

> On Tue, 17 Jul 2018, tjw ietf wrote:
>
> > Subject: Re: [DNSOP] QNAME minimisation on the standards track?
> >
> > I’d like to see a more fleshed out operational considerations section.
>
> That would be good indeed. Especially with respect to broken DNS load
> balancers.
>
> I have enabled it in Fedora from the start and did run into a few problem
> domains, and some people turning it off. But that happened less than I
> had expected. Red Hat did not yet enable this in RHEL7 but it is planned
> to be enabled in RHEL8.
>
> But I do believe qname minimisation is an important privacy enhancing
> technology that we should strongly promote as a standards track
> document.
>
> Paul
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Current Document Status

[Tim Wicinski]

All

In preparation for tomorrow's meeting I've updated our document status,
which is located here:

https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.txt

See y'all in the morning.


# DNSOP Chairs Status
 Updated: 17 July 2018

Official document list: https://datatracker.ietf.org/wg/dnsop/documents/

## IESG Queue

* draft-ietf-dnsop-refuse-any

* draft-ietf-dnsop-session-signal

## Limbo

* draft-ietf-dnsop-alt-tld
- Held by WG.
- Pending guidance from the IESG/IAB

## WG Chairs Work

* draft-ietf-dnsop-kskroll-sentinel
- awaiting write up

* draft-ietf-dnsop-terminology-bis
- awaiting write-up

* draft-ietf-dnsop-attrleaf
- awaiting write up

* draft-ietf-dnsop-attrleaf-fix
- awaiting write up

* draft-ietf-dnsop-isp-ip6rdns
- awaiting write up

## In WG Last Call

* draft-ietf-dnsop-rfc5011-security-considerations
- WGLC Ends 20 Friday 2018
- Consensus is extremely rough

* draft-ietf-dnsop-dns-capture-format
- WGLC Ends 20 Friday 2018

* draft-ietf-dnsop-let-localhost-be-localhost
- Waiting on Authors since 2018-02-19

## Current WG Last Call Order

* draft-ietf-dnsop-algorithm-update
- Should be ready for WGLC

* draft-dupont-dnsop-rfc2845bis
- Should be ready for WGLC *very soon*

## Adopted

* draft-ietf-dnsop-aname
- Authors getting editing help

* draft-ietf-dnsop-serve-stale
- May be too contentious

* draft-ietf-dnsop-dns-tcp-requirements
- Section 4 and 5.3 TODOs, John and Duane are working on

* draft-song-dns-wireformat-http
- Needs to be updated to reflect DOH

## Expired Adopted Documents

* draft-ietf-dnsop-extended-error
- Last list discussion was 2017-11-07

* draft-ietf-dnsop-no-response-issue
- Author will upload new version

## Call for Adoption

* draft-huque-dnsop-multi-provider-dnssec
- CfA Ends 20 July 2018

## Candidates For Adoption

* draft-bortzmeyer-rfc7816bis

## Documents Worth Considering

* draft-wessels-dns-zone-digest

* draft-jabley-dnsop-bootstrap-validator
- Signs point to yes

* draft-mekking-mixfr
- One chair finds highly useful

* draft-woodworth-bulk-rr

* draft-pwouters-powerbind

* draft-spacek-edns-camel-diet

* draft-kh-dnsop-7706bis

## New Documents

* draft-tariq-dnsop-iviptr

* draft-song-atr-large-resp

## Needs more Review

## Not At This Time

* draft-muks-dnsop-dns-catalog-zones

* draft-bellis-dnsop-xpf
- No significant interest

* draft-gavrichenkov-dnsop-dnssapi
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] SRV and HTTP - 18:30 Tuesday (room change)

[Tim Wicinski]

These are great notes Shane.

We're going to talk about APEX records in the DNSOP session in the morning.


Tim


On Tue, Jul 17, 2018 at 7:43 PM, Shane Kerr 
wrote:

> All,
>
> I took some random notes at the meeting. Apologies for any errors or
> misstatements.
>
> Cheers,
>
> --
> Shane
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] SRV and HTTP - 18:30 Tuesday (room change)

[Shane Kerr]

All,

I took some random notes at the meeting. Apologies for any errors or 
misstatements.


Cheers,

--
Shane
2018-07-17

Bar BoF with about 35 people.

Mark Nottingham leads the discussion.

Why not SRV for HTTP?

Some work before:
* draft-andrews-srv-http
* New URI scheme also died.

Use cases for SRV:

1. Load balancing
2. Service on alternate port

Mark Andrews: Gets around CNAME at apex issue in DNS.

Ray Bellis: Missing wildcard support, HTTPS only, more stuff.

Mark Nottingham: From the web side, we have constraints. Have to be
backwards compatible and cannot have a flag day. On the web it is
critical to maintain security boundary based on the name.

Martin Thompson: When we are talking about an unauthenticated method
(DNSSEC notwithstanding), we are uncomfortable although that is
changing.

Ray Bellis: No reason not to have a record that matches this
requirement.

Mark Nottingham: Assumption was "just use SRV", but if we mean "SRV
done right" then it is a different discussion.

Cullen Jennings: What about getting it in a way that you can use it in
every operating system?

Mark Andrews: That is dead easy. If your resolver code does not
support unknown RTYPEs then you are not compliant.

Olafur Gudmondsson: One pain point is provisioning systems, the other
is various libraries.

Steward Cheshire: Within a C API it is easy. If Javascript it is more
difficult.

Mark Nottingham: I didn't see many web people concerned about how hard
it is to set up a new record type.

Erik Nygren: The performance hit of looking it up does not justify the
work. But there is a new record type called ALTSVC is like an
extensible SRV that covers additional use cases. It negotiates what
port to use, and some other things which are actively being looked at
(such as encrypted SNI).

Mark Nottingham: This allows different name treated as the same
origin.

Not a working group document - being considered.

Tale: About performance... that has been a major obstacle. Vendors
want to get answers as quickly as possible. You could do server-side
processing, but this doesn't help across boundaries and also,
server-sides RR more difficult to get out.

Patrick McManus: Protocol version negotiation in the DNS is attractive
in many ways. But blocking is a real thing. ALTSVC fixes this by
allowing connection to be made after or while connected to the primary
service.

Ben Schwartz: two modes, totally asynchronous or blocking.

Tale: Asynchronous does not really address the same problem as SRV,
since you have to connect to the primary origin which may be what you
want to address.

Ask Hansen: Server operators can get much better control, and clients
implemented correctly can also get better behavior.

..

Paul Hoffman: What would you like now? We could do stuff.

Mark Nottingham: Now that we have use cases, what are the appropriate
paths now.

Ray Bellis: SRV is for service type to target mapping. CNAME is
supposed to be for hostname mapping, and that means every service. SRV
is service-specific.

Erik Nyren: Things that have transitional properties are very
important.  Always be a need for A and  records at least for some
decades.

Mark Andrews: I have always expected legacy clients.

[ discussion about deprecating technologies ]

Kazuho Oku: Key distributed via DNS is a separate record, and also
cannot handle the multiple CDN record since key cannot be shared.

Ray Bellis: ANAME shifts work to resolvers; a really bad idea.

Ben Schwartz: There are certain cases in TCP where you can risk a
SYN/ACK, one RTT.

Mark Nottingham: Interaction between web and DNS folks. I am not
expecting a lot, but we should talk together and work better and learn
the pain points and so on.

Martin Thompson: Unfiltered messages coming through. We actually get
TTL's from platforms (except Windows). This is a transition problem
and we need to look at this in terms of transition problems. Browsers
have an influence but they are not the only HTTPS clients.

Mark Andrews: SPF working group did not give themselves enough time to
switch from TXT to SPF. It requires libraries to be upgraded, along
with browsers, and whatever else needs to be upgraded. This takes 3 or
4 years.

Mark Nottingham: I am hearing that we don't know how to get from now
to the end state. We need a roadmap. We need to meet security and
performance while transitioning.

Ben Schwartz: Some people seem to think transition is infinite. I
think that it is large but probably finite. Are are there alternative
means to reach our goals that cost less?

Martin Thompson: I was not proposing that it was intractable
transition. The apex problem is a pain, and externalizes the problem
in various awful ways, and it would be better if we had a different
system. HTTP is everywhere, embedded in all sorts of things. If the
goal is to exterminate the current resolution... I don't see how every
single person could be motivated to move. I can see some of them -
certainly a browser - but there is a lot of HTTP 

Re: [DNSOP] QNAME minimisation on the standards track?

[Paul Wouters]

On Tue, 17 Jul 2018, tjw ietf wrote:


Subject: Re: [DNSOP] QNAME minimisation on the standards track?

I’d like to see a more fleshed out operational considerations section.


That would be good indeed. Especially with respect to broken DNS load
balancers.

I have enabled it in Fedora from the start and did run into a few problem
domains, and some people turning it off. But that happened less than I
had expected. Red Hat did not yet enable this in RHEL7 but it is planned
to be enabled in RHEL8.

But I do believe qname minimisation is an important privacy enhancing
technology that we should strongly promote as a standards track
document.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dns-capture-format

[Peter DeVries]

We have read this document and think it's ready to move forward.

We've also been using the dns-compactor implementation of this standard and
it has shown itself to be quite stable and robust.   We're looking forward
to having this format standardized and hopefully more community interest
than this last call has generated.

Thank you to the authors.

Peter



On Fri, Jul 6, 2018 at 8:32 PM, Tim Wicinski  wrote:

>
> All,
>
> We feel that the authors have addressed all outstanding issues, and this
> document is ready to move forward.  Also, the chairs wanted to kick off
> this Working Group before Montreal so if there are any issues that need
> some face time, we'll have it.
>
> One thing which arose early in the process was the issue of IPR and how
> it would be resolved.  The simple answer is that it is resolved farther
> up the process chain.   I spent time reading RFC 3979 on this topic:
> https://tools.ietf.org/html/rfc3979#section-10
>
> This starts a Working Group Last Call for draft-ietf-dnsop-dns-capture-f
> ormat
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
>
> The Current Intended Status of this document is: Standards Track
>
> Please review the draft and offer relevant comments.  If this does not
> seem appropriate please speak out.  If someone feels the document is *not*
> ready for publication, please speak out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  20
> July 2018
>
> thanks
> tim
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Logistics for DNSOP at IETF 102

[Suzanne Woolf]

Hi all, and welcome to IETF 102!

DNSOP has two slots: Wednesday morning 9:30-12:00 local time in Montreal (the 
Laurier room), and Thursday evening 18:10-19:10 (the Place du Canada room). 
NOTE DIFFERENT ROOMS.

Meeting materials, including agendas and drafts, are linked from the usual 
place: https://datatracker.ietf.org/meeting/102/materials (Look for dnsop under 
the “OPS” tab on the right)

We’re trying a couple of experiments with meeting management since we now have 
three chairs. Two of us will be on stage managing the room, and one will join 
the participants and act as note-taker.

We still need jabber scribes for both sessions.



Thanks,
Suzanne & Tim & Benno
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QNAME minimisation on the standards track?

[Marek Vavruša]

I'd like to see this on the standards track as well. Cloudflare has
some operational experience with it (it's enabled by default on
1.1.1.1). It mostly works, but still has to be turned off on several
delegations that either don't respond to non-terminals, respond with
positive answer that's invalid (usually when there's an LB that only
handles final name, but gives out a referral to intermediate name), or
respond with nxdomain (this is the most common one and well known).

On Tue, Jul 17, 2018 at 10:01 AM, tjw ietf  wrote:
> I’d like to see a more fleshed out operational considerations section.
>
> Tim
> As chair
>
> From my high tech gadget
>
>> On Jul 17, 2018, at 08:14, Stephane Bortzmeyer  wrote:
>>
>> Greetings. With more resolvers implementing QNAME minimisation, and
>> even turning it on by default, we thought that this is a good time to
>> update RFC 7816 and make it a standard. In order to get things moving,
>> we have published a very early draft draft-bortzmeyer-rfc7816bis-00
>> that is mostly the original RFC but with a few questions and holes
>> added (see the text near the strings "TODO"). If folks in the WG is
>> interested, feel free to comment in the non-GitHub repo listed in the
>> draft, or here on the list.
>>
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Rose, Scott]

On 6 Jul 2018, at 20:26, Tim Wicinski wrote:

We've had some interest in moving this document forward, and the 
chairs

wanted to kick off this Call for Adoption before Montreal so if there
are concerns there will be some meeting time to address.

This document is label as: Informational.  The document is attempting
to document operational deployment models on deploying DNSSEC signed
zones across multiple platforms.

This starts a Call for Adoption for: 
draft-huque-dnsop-multi-provider-dnssec



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 authors will be at the next meeting to address questions or 
concerns.


Please also indicate if you are willing to contribute text, review, 
etc.


This call for adoption ends: 20 July 2018

Thanks,
Tim


I have read the draft and I think that it is something that should be 
documented.  I support it becoming a WG draft.


Scott


===
Scott Rose
NIST ITL
scott.r...@nist.gov
+1-301-975-8439
GV: +1-571-249-3671
===
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Artyom Gavrichenkov]

On Sat, Jul 14, 2018 at 7:13 AM Shumon Huque  wrote:
> [..] The portion of the community that
> would benefit from actually using the new deployment models described
> in the document is likely much smaller: a set of enterprises that
> need to deploy DNSSEC in a multiple signing provider configuration,
> and a set of managed DNS providers that are willing and capable of
> supporting this. I expect this population will grow over time if/when
> DNSSEC adoption grows. And yes, this does solve a real problem for
> those enterprises.

Reflects my experience entirely.
Would be happy to see this adopted by the WG.

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: xima...@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QNAME minimisation on the standards track?

[tjw ietf]

I’d like to see a more fleshed out operational considerations section.  

Tim
As chair 

From my high tech gadget

> On Jul 17, 2018, at 08:14, Stephane Bortzmeyer  wrote:
> 
> Greetings. With more resolvers implementing QNAME minimisation, and
> even turning it on by default, we thought that this is a good time to
> update RFC 7816 and make it a standard. In order to get things moving,
> we have published a very early draft draft-bortzmeyer-rfc7816bis-00
> that is mostly the original RFC but with a few questions and holes
> added (see the text near the strings "TODO"). If folks in the WG is
> interested, feel free to comment in the non-GitHub repo listed in the
> draft, or here on the list.
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Hollenbeck, Scott]

> -Original Message-
> From: DNSOP  On Behalf Of Petr Špacek
> Sent: Tuesday, July 17, 2018 7:19 AM
> To: dnsop@ietf.org
> Subject: [EXTERNAL] Re: [DNSOP] Call for Adoption: draft-huque-dnsop-
> multi-provider-dnssec
>
> On 14.7.2018 06:12, Shumon Huque wrote:
> >> On Tue, Jul 10, 2018 at 12:06 PM Joe Abley  > > wrote:
> >>
> >> I actually think the document is actually almost entirely
> >> operational; at least, it describes a set of operational and design
> >> considerations for deploying DNS services constrained by particular
> >> sets of requirements. I don't see it as describing business models,
> >> but rather how commonly-available commercial DNS services can be
> >> lego'd together. Having said that, see (further) below.
> >

[snip]

> Nice summary. In short I support work on this and having it as WG
> documents makes sense to me.

It makes sense to me, too. I support adoption.

Scott
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] The DNSOP WG has placed draft-bortzmeyer-rfc7816bis in state "Candidate for WG Adoption"

[IETF Secretariat]

The DNSOP WG has placed draft-bortzmeyer-rfc7816bis in state
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-00.txt

[internet-drafts]

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 WG of the IETF.

Title   : Secret Key Transaction Authentication for DNS (TSIG)
Authors : Francis Dupont
  Stephen Morris
Filename: draft-ietf-dnsop-rfc2845bis-00.txt
Pages   : 24
Date: 2018-07-17

Abstract:
   This protocol allows for transaction level authentication using
   shared secrets and one way hashing.  It can be used to authenticate
   dynamic updates as coming from an approved client, or to authenticate
   responses as coming from an approved name server.

   No provision has been made here for distributing the shared secrets:
   it is expected that a network administrator will statically configure
   name servers and clients using some out of band mechanism.

   This document includes revised original TSIG specifications (RFC2845)
   and its extension for HMAC-SHA (RFC4635).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc2845bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] QNAME minimisation on the standards track?

[Stephane Bortzmeyer]

Greetings. With more resolvers implementing QNAME minimisation, and
even turning it on by default, we thought that this is a good time to
update RFC 7816 and make it a standard. In order to get things moving,
we have published a very early draft draft-bortzmeyer-rfc7816bis-00
that is mostly the original RFC but with a few questions and holes
added (see the text near the strings "TODO"). If folks in the WG is
interested, feel free to comment in the non-GitHub repo listed in the
draft, or here on the list.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02

[Petr Špaček]

On 15.7.2018 20:37, Shane Kerr wrote:
> Bonjour,
> 
> I decided to implement draft-wessels-dns-zone-digest-02 at the IETF 102
> Hackathon. As expected, it is fairly straightforward. You can see the
> code on GitHub:
> 
> https://github.com/shane-kerr/ZoneDigestHackathon
> 
> It seems to work, although since I have no other implementation to
> compare against I can't be sure that the digest values are in any way
> correct.
> 
> In proper hackathon style there are no tests. Bugs surely abound. If you
> use it in production please keep a fire extinguisher handy.
> 
> I found the draft to be clear and fairly complete, although I have a few
> suggestions:
> 
> * It might be worth mentioning that names are expected to be
>   uncompressed. It's kind of obvious, but it might trick up some
>   implementations.
> 
> * The TTL of the ZONEMD record has to come from somewhere. It can either
>   come from configuration or pulled from somewhere else (I used the TTL
>   of the SOA record). This should be documented.
> 
> * It might be worthwhile giving some recommendations or even
>   requirements about what to do with failures. For example, something
>   like "secondary servers who receive a zone that fails a digest
>   validation SHOULD NOT serve the zone".
> 
> * Having some example zones and the expected digest values would be very
>   useful for implementers.

First of all thanks for your work! It is useful to test drafts this way,
it obviously uncovered some definiencies.

In any case, I believe that real problem is not the spec or
toy-implementation, the real complexity is still hidden and will unveil
itself once we attempt an efficient implementation inside a
high-performace DNS server.

> As a final note, while it is awesome to have dnspython available to do
> such projects, dnspython is not a joy to work with. I had a brief
> discussion with some other hackathon attendees and it seems to be a

OT: Please create issues in dnspython Github pages, we might look into
it ...

> shared experience. I was encouraged to look at the getdns Python API,
> which has apparently had quite some thought in making it Pythonic. I may
> look at that or making a pure Python version of it at some point in the
> future. If you have other suggestions for DNS in Python feel free to
> contact me off-list (since this isn't a software development list).

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Petr Špaček]

On 14.7.2018 06:12, Shumon Huque wrote:
>> On Tue, Jul 10, 2018 at 12:06 PM Joe Abley  > wrote:
>>
>> I actually think the document is actually almost entirely operational;
>> at least, it describes a set of operational and design considerations
>> for deploying DNS services constrained by particular sets of
>> requirements. I don't see it as describing business models, but rather
>> how commonly-available commercial DNS services can be lego'd
>> together. Having said that, see (further) below.
> 
> Yes, it is indeed almost entirely operational. If dnsop is now only about 
> protocol enhancements, maybe we need to change its name to dnsext! :-)
> 
>> I don't particularly know who the audience for this document is, but
>> I'm pretty sure it's not me. So I'm not the right person to judge
>> whether it solves a real problem or is pitched at the right level. I
>> haven't reviewed the document in detail; I've just skimmed through
>> it. I'm pretty confident that the authors know what they are talking
>> about :-)
> 
> The audience in my opinion is the general DNS community, since I think
> they should be aware of the issues. The portion of the community that
> would benefit from actually using the new deployment models described
> in the document is likely much smaller: a set of enterprises that
> need to deploy DNSSEC in a multiple signing provider configuration,
> and a set of managed DNS providers that are willing and capable of
> supporting this. I expect this population will grow over time if/when
> DNSSEC adoption grows. And yes, this does solve a real problem for
> those enterprises.
> 
>> I don't know that the document would necessarily benefit from adoption
>> by the working group. I also don't know that the working group ought
>> to have the kind of concern about the topics that this document
>> addresses that would cause it to seek editorial control. It seems
>> entirely plausible that the document contains useful advice, however,
>> and that the RFC series is a suitable place for its publication.
>>
>> I think this document is an ideal candidate for the independent
>> stream. I don't see an obvious reason why it belongs in dnsop.
> 
> From discussing this draft at the last IETF, it appeared to us that
> there was interest from the working group in taking on this work. Doing
> this as a working group document carries more weight than an independent
> submission (of course, most people outside the IETF would not know the
> difference).
> 
> On ceding editorial control to the working group, and whether or
> not the group should even care about the issues raised in the
> draft - that is a good question, and I had contemplated that prior
> to the last IETF. If we sensed that this would lead to a protracted
> fight between DNS protocol purists and the DNS traffic management/
> tricks crowd about how to solve this problem in entirely different
> ways, then I think we would probably have elected to go the
> independent submission route. I did not get that impression.
> 
> In principle, I am open to tackling the larger question of should we
> standardize the various traffic management tricks. But I suspect there
> will be strong resistance from both camps, and even if it could be done
> and implemented, it would not be possible to do so in a time frame
> required by the folks interested in this draft.
> 
>> Like Paul, my lack of enthusiasm for adoption shouldn't be interpreted
>> as an objection.
> 
> Ok. I waited a few days to see if other people will speak up in support
> of this draft, but I guess we're in the pre-IETF lull period. Lest people
> get the impression there is no enthusiasm for this draft, I want to remind
> folks that I presented this draft at IETF101 in London, and there appeared
> to be quite a bit of interest.. I went back and took a look at some of the
> previous discussion:
> 
> The original email thread for this draft from March starts here:
> 
>     https://www.ietf.org/mail-archive/web/dnsop/current/msg22196.html
> 
> Here's video of my presentation at IETF101:
> 
>     https://www.youtube.com/watch?v=MixId63DGP4=33m16s
> 
> And you can jump to the Q section here:
> 
>     https://www.youtube.com/watch?v=MixId63DGP4=40m54s
> 
> As you can see, most people who expressed an opinion were supportive
> of doing this work (as a working group document). The jabber session
> shows more supportive comments. And I had largely positive discussions
> with many other folks in the hallway track.
> 
> Jim Reid, notably, was quite vocally opposed. As far as I could tell,
> on the basis that (1) this is another straw on the camel's back, and
> (2) who is actually even asking for DNSSEC, is there any demand, and
> will this move the needle.
> 
> Regarding (1), if this is straw, it seems to be rather light straw.
> I don't think the DNS camel should be used as a bludgeon to beat back
> all proposals to enhance the DNS. The incentives here appear to be in
> the right place.