On 10July2015Friday, at 13:12, Olafur Gudmundsson <o...@ogud.com> wrote:
> >> 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). > > 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. > >> >> 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. >> > > 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. >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…. > > Olafur (hating being the process fascist) > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
