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
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102



On 10July2015Friday, at 17:47, Suzanne Woolf <suzworldw...@gmail.com> wrote:

> 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
> 
> On Jul 10, 2015, at 1:31 PM, manning <bmann...@karoshi.com> wrote:
> 
>> 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
>> bmann...@karoshi.com
>> PO Box 12317
>> Marina del Rey, CA 90295
>> 310.322.8102
>> 
>> 
>> 
>> On 10July2015Friday, at 9:06, Suzanne Woolf <suzworldw...@gmail.com> wrote:
>> 
>>> Bill,
>>> 
>>> On Jul 10, 2015, at 9:38 AM, Olafur Gudmundsson <o...@ogud.com> wrote:
>>> 
>>>> Question: 
>>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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

Reply via email to