On May 8, 2014, at 12:43 PM, Suzanne Woolf <suzworldw...@gmail.com> wrote: > > Ah, sorry. Was trying to reflect what the discussion was saying, not impose > an “edict”. It seemed like a reasonable starting position. > > Do you disagree? If so I’ll hope you’ll say what you think on the subject….
Yes, I think I do disagree with your previous conclusion, actually. Specifically, the “sounds to me like” and: “b) a resulting RFC as "Informational”. I’m not sure I’d have so quickly reached the same conclusion if I were chair or based on what I’ve seen in the discussion here (!even after DW, who invented a strikingly similar feature for http ~16 years ago, pointed out a slewwww of concerns [and opportunities] with this particular feature oob), but I wasn’t actually counting opinions here like I presume you were and I do think this particular thing has demonstrated utility already, warts et al. Of course, I’m not sure I really care so much about this particular feature as to take a hard position, it’s more the meta topic. Quite frankly, given implementation and deployment scope already this is the sorta thing that arguably coulda-shoulda been published years ago as Informational OR Experimental RFC even absent ANY working group support (and still could be, of course) -- and then [e.g., now] lending deployment experience to a potential Standards Track RFC IF it doesn’t perturb to many things and gains traction. OTOH, if the goal of putting it through the wringer here is to simply continue publication as an Informational RFC (albeit with a bunch of extra text talking about applicability, deployment experience, security and privacy considerations, architectural fashion sense, and other important stuff) then I think we might be missing an opportunity, or even worse... IF DNSOP is going to muck with bits on the wire in Standards Track protocols, in addition to documenting operational DNS fun, then we should expressly aim to not push implementers away. That’s the only reason I’m really responding to this thread at all, FWIW. On a related noted, and in lieu of the earlier references from Jiankang Yao to draft-iab-dns-applications (i.e., RFC6950), folks considering this with context might want to also apply RFC5218 considerations here - which may well leave you more firmly on the fence or perhaps even more entrenched on either side of this particular discussion :-) -danny
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
