Subject: [DNSOP] RFC 2181 - a pathway forward.

From: manning <[email-masked]>
Date: Wed, 8 Jul 2015 11:50:05 -0700

With the WG Chairs permission.

RFC 2181 is growing a both long in the tooth.  It is, by its own admission, a collection of eight distinct and independent ideas.  As such, it is difficult to work on one of 
those ideas without raising concerns about all of them.   With some coworkers, we split out each of the ideas in RFC 2181 and have created a standalone ID that has the 
EXACT text from RFC 2181.  What would be a very nice, administrative, step is to take each of these IDs and last call them, turning them into RFCs with the same status
as RFC 2181.  It will then be possible to declare RFC 2181 historic, and folks that then want to update/work on specifics can make changes against these new RFCs.

The drafts in question are:

draft-pfrc-2181--naming-issues-00 
DNS Naming Issues
	
draft-pfrc-2181-handling-zone-cuts-00 
Handling DNS Zone Cuts
	
draft-pfrc-2181-name-syntax-00 
DNS Name Syntax
	
draft-pfrc-2181-resource-record-sets-00 
DNS Resource Record Sets

draft-pfrc-2181-soa-records-00 
Issues Concerning DNS SOA Resource Records
	
draft-pfrc-2181-tc-bit-00 
Use of the TC (Truncated) Header Bit for DNS Responses
	
draft-pfrc-2181-ttl-00 
DNS Resource Record TTL
	
draft-pfrc-rfc2181-historic-issues-00 
RFC2181 to Historic draft-pfrc-rfc2181-historic-issues-00 Abstract

I would like the WG to adopt these drafts.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Jul 2015 09:38:40 -0400

> On Jul 8, 2015, at 2:50 PM, manning <[email-masked]> wrote:
> 

Bill, 
I oppose this strongly for the following reasons 
a) A frequent comment I hear is “DNS has too many RFC’s to read”, this approach will make that worse for no reason. 
b) If there is a need to update an section of RFC2181 then we have a process to obsolete parts of RFC2181 with a new document.
c) Just putting this as is in front of the WG is just make-work IMHO 

Question: 
What sections of 2181 do you see the need to update? 

Regards 
Olafur

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 10 Jul 2015 12:06:51 -0400

Bill,

> What sections of 2181 do you see the need to update? 

This seems to be the critical question to your chairs and our AD as well.

If I understand it correctly, your proposed document roadmap has us putting eight documents through the process as standards-track RFCs with no change in substance from RFC 2181, so we can then put three more documents through the process with new content. This seems like a very process-heavy way to update 2181.

It's also hard to commit to obsoleting 2181 in eight separate steps without seeing the proposed updated content will be, or knowing whether it will get to consensus.

Could you describe the substance of what you think needs to be changed? If the WG wants to do the work, we can manage the process machinery accordingly.

thanks,
Suzanne

---

From: manning <[email-masked]>
Date: Fri, 10 Jul 2015 10:31:02 -0700

I am aware of  at least three of the independent ideas in RFC 2181 that folks are working on:

draft-pfrc-2181--naming-issues-00
draft-pfrc-2181-handling-zone-cuts-00  (isn’t this the basis for the dbound work?)
draft-pfrc-2181-resource-record-sets-00
draft-pfrc-2181-tc-bit-00

Ok, so that is four.   The rational for eight is so that nothing gets lost and we can garbage collect RFC 2181, moving it to historic.
Then each idea can progress independently, without the linkage to any of the other work and without the vestigial anchor to the
collective past (RFC2181).

First split them apart  into their own RFCs
Second, move RFC 2181 to historic
Third, start -bising the specify RFCs that folks are working on anyway.

Clean, Tidy, No trailing steams of toilet paper stuck to our shoes.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 10July2015Friday, at 9:06, Suzanne Woolf <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jul 2015 12:21:40 -0700

> Clean, Tidy, No trailing steams of toilet paper stuck to our shoes.

Fully disagree about that last bit. Turning one RFC about the DNS into eight, some of which are then expected to be updated, is anything but "clean" or "tidy".

On Jul 8, 2015, at 11:50 AM, manning <[email-masked]> wrote:

> RFC 2181 is growing a both long in the tooth.  

RFC 2181 has been only been updated by: 2535 4033 4034 4035 4343 5452. 4343 is a long clarification on case sensitivity. The other five update just one section of 2181, the "trustworthiness" rules.

Also note that there are no errata on RFC 2181.

By IETF standards, that's not "long in the tooth".

> It is, by its own admission, a collection of eight distinct and independent ideas.  As such, it is difficult to work on one of 
> those ideas without raising concerns about all of them.

Now, when there are raising concerns, there are references to sections in 2181. You are proposing to make those references to sections in eight different RFCs. That seems unclean, untidy.

--Paul Hoffman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Jul 2015 16:12:03 -0400

> On Jul 10, 2015, at 1:31 PM, manning <[email-masked]> wrote:
> 

There is a difference between “someone” working on and what is acceptable and/or relevant to the DNSOP working group.
Please share more!!! 

> Clean, Tidy, No trailing steams of toilet paper stuck to our shoes.

Not at all this will become a reference nightmare there are currently over 40 RFC that reference 2181, finding which document to read
now is much harder.
Not to mention that people will pick on the documents for not following current way of standards writing to the letter. 

Bill,  please tell us what you want update before starting any process that may or may not work. 
With out justification this is a waste of everyone’s time, because if the proposed work is not acceptable there is no reason to update RFC2181 in any way.

Olafur (hating being the process fascist)

---

From: manning <[email-masked]>
Date: Fri, 10 Jul 2015 17:19:37 -0700

> There is a difference between “someone” working on and what is acceptable and/or relevant to the DNSOP working group.

The item I am working on will modify draft-pfrc-2181-resource-record-sets-00.   Why?  Because this recommendation is a significant contributing factor in the use of DNS as a DDoS vector.
The tradeoffs in cache coherence are worth a more stable DNS.   I’ll let the others working on these topics speak for themselves, if they wish.

> Not to mention that people will pick on the documents for not following current way of standards writing to the letter. 

From another thread… (when asked why not just reference RFC 2181)

We can.   but then its much more messy following the standards track trail and it becomes very hard to nail down current state;

(berries, son of brie, son of walnuts, daughter of oak, daughter of crocus, son of RFC 8550, son of RFC 6733, son of RFC 4335, son of RFC 2181, son of RFC 1034, son of RFC 853).

when RFC 2181 is still on the standards track because one of its independent ideas has not evolved but the rest of it has moved on.  So yes, it’s “make-work” but its the way the process
has evolved to do garbage collection.

> Bill,  please tell us what you want update before starting any process that may or may not work. 

I thought I did tell you what folks want to change.  Four of the items listed in RFC 2181.   Some of those items are in your list of 40 RFCs that reference RFC 2181.   

> With out justification this is a waste of everyone’s time, because if the proposed work is not acceptable there is no reason to update RFC2181 in any way.

Well, the work is being done.  I don’t think we get to say what is acceptable or not.  If you think there is no reason to update RFC 2181 in any way….

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Jul 2015 10:42:34 +1000

In message <[email-masked]>, manning writes:
> >> draft-pfrc-2181-handling-zone-cuts-00  (isn't this the basis for the
> dbound work?)
> >> Ok, so that is four.   The rational for eight is so that nothing gets
> lost and we can garbage collect RFC 2181, moving it to historic.
> >> Then each idea can progress independently, without the linkage to any
> of the other work and without the vestigial anchor to the
> > There is a difference between "someone" working on and what is
> acceptable and/or relevant to the DNSOP working group.
> > Please share more!!!
>
> The item I am working on will modify
> draft-pfrc-2181-resource-record-sets-00.   Why?  Because this
> recommendation is a significant contributing factor in the use of DNS as
> a DDoS vector.
> The tradeoffs in cache coherence are worth a more stable DNS.   I'll let
> the others working on these topics speak for themselves, if they wish.

So you want us to take it on faith that there is something there
that needs fixing because you have not explained the problem or
why you thing changing RFC 2181 will fix the problem despite the
explict request to do so.

https://tools.ietf.org/html/draft-pfrc-2181-resource-record-sets-00
doesn't explain the problem.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 10 Jul 2015 20:47:33 -0400

Bill,

In the interests of keeping things simple:

Do you have substantive changes to RFC 2181 to propose for WG consideration at this time?

If so-- please provide the list with pointers to the relevant internet-drafts.

If not-- I hope that when you do have substantive changes to suggest, you'll write them up as internet-drafts so the WG can consider them then.

For now: we're not inclined to take on the document production process work you're requesting without more information and review of potential changes to the existing content of RFC 2181. In addition to the objections already raised, I find I have serious doubt that we'd be able to get text known to be inaccurate, such as discussion of DNSSEC already updated by RFC 4033/4034/4035, copied from an old RFC and pushed through the process as a new RFC in the hope that it will actually be updated in the future by yet another RFC. 

As I said earlier-- If the WG wants to do the substantive work, we can manage the process machinery accordingly. 

best,
Suzanne

---

From: joel jaeggli <[email-masked]>
Date: Sat, 11 Jul 2015 11:09:42 -0700

On 7/10/15 9:06 AM, Suzanne Woolf wrote:
>> Question: What sections of 2181 do you see the need to update?
> 
> If I understand it correctly, your proposed document roadmap has us
> putting eight documents through the process as standards-track RFCs
> with no change in substance from RFC 2181, so we can then put three
> more documents through the process with new content. This seems like
> a very process-heavy way to update 2181.

It does,

Also there are  4035, 2535, 4343, 4033, 4034, 5452   which update
respective portions of 2181 so breaking apart 2181 into individual
pieces from the outset means incorporating those updates (fine I guess)
but then you're operating on those drafts; or walking back those changes
which I doubt is your intent.

This is a foggy recollection but I'll recount it here, by way of
communicating my own thoughts.

When Bill asked me at nanog what I though of multiple 2181 changes. I
proffered the opinion that. given that 2181 is several topics (7 I
think) it would be best if each proposed update to a topic taken on in
2181 were to be a seperate draft so that could be discussed on their
invidual merits rather than as a package of changes to 2181. 4343 and
5452 I would treat as precident  for that.

that is not a call imho for splitting appart 2181 first and then
proposing changes. if I was interpreted at any time as proposing that
I'm sorry.

> It's also hard to commit to obsoleting 2181 in eight separate steps
> without seeing the proposed updated content will be, or knowing
> whether it will get to consensus.
> 
> Could you describe the substance of what you think needs to be
> changed? If the WG wants to do the work, we can manage the process
> machinery accordingly.
> 
> 
> thanks, Suzanne
> 
> 
> 
> 
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: manning <[email-masked]>
Date: Sat, 11 Jul 2015 15:04:01 -0700

thank you for your consideration.  I know of substantive changes being worked on for four of the eight independent items collected in RFC 2181.
I believe the other four items in RFC 2181 are unlikely to change.   the one change i am working on is to obsolete RRsets since they are a primary 
cause of DNS originated DDoS in the Internet.   I guess the path will be to obsolete sections of RFC 2181 piecemeal.   

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Ray Bellis <[email-masked]>
Date: Sun, 12 Jul 2015 21:40:29 +0100

On 11/07/2015 23:04, manning wrote:
> the one change i am working on is to obsolete RRsets since they are a
> primary cause of DNS originated DDoS in the Internet.

How do you propose to do that without completely breaking DNSSEC ?

RRSIGs are calculated over entire RRsets, not RRs.

Ray

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 12 Jul 2015 16:54:34 -0400

(Hats off )

And some of use Rrsets to do things for their employer that is never best practice, but necessary evils. 

Tim

From my high tech gadget

> On Jul 12, 2015, at 16:40, Ray Bellis <[email-masked]> wrote:
>

---

From: David Conrad <[email-masked]>
Date: Sun, 12 Jul 2015 14:00:58 -0700

> the one change i am working on is to obsolete RRsets since they are a primary cause of DNS originated DDoS in the Internet.

I thought the primary cause was spoofed source addresses.

Regards,
-drc

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2015 22:50:32 -0000

>draft-pfrc-2181-handling-zone-cuts-00  (isn’t this the basis for the dbound work?)

Nope.  One of the few things we seem to agree on in the dbound group
is that we're not basing anything on zone cuts.

There may be other reasons to update this part of 2181, but dbound
isn't one.

R's,
John