On Thu, Apr 16, 2015 at 1:25 PM, Alec Muffett <al...@fb.com> wrote: > Hello All, > > So a couple of days ago I posted draft-appelbaum-dnsop-onion-tld-01: > > https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01 > > Again, the diffs are minimal from -00: > > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-appelbaum-dnsop-onion-tld-01.txt > > …and I am cognizant of (planned, delayed) interim meetings to cover broader > RFC6761 discussion points. However I also have an elderly systems > administrator’s eye towards extremely hard (and CABForum-sourced) deadlines > and process, and I also hereby will admit my complete ignorant newbie-ness > towards established procedure for DNSOP and RFC adoption. > > “Everybody has to be a learner-driver at least once.” :-) > > So I would like to invite the community, please, to pass comment and
Some initial comments, and sorry for the delay. These are all (IMO) nits, not substantive. I found: "instead of using the DNS infrastructure, .onion names functionally correspond to the identity of a given service, thereby combining location and authentication." to be very confusing. After a while I went and looked at the diff and saw that this used to be: ".onion names are hashes that correspond to the identity of a given service," I'm guessing that you changed this because of some comment? Anyway, this is in the introduction section, and so I think a little more, um, introductory text would be helpful. Perhaps saying that they are hashes of the key, and functionally correspond to <handwave, handwave> ? Also: "In this way, .onion names are "special" in the sense defined by [RFC6761] Section 3; they require hardware and software implementations to change their handling, ..." I'm not really sure if this is completely true -- I agree that software implementations would need to change, but I don't see how *hardware* implementations would need to change -- largely because I don't actually understand the concept of a hardware implementation of the DNS / .onion resolution stuff. Sure, some CPE runs *software* that does DNS, and some hardware accelerators run some DNS stuff in FPGAs, but I still don't see this a "hardware" implementation. I'd suggest just making that be: "In this way, .onion names are "special" in the sense defined by [RFC6761] Section 3; they require implementations to change their handling, ..." Also: Throughout the document you state that thingies should return NXDOMAIN. Personally I think that this is a well enough known term that it is fine, but it isn't really defined (hoffman-terminology only sorta, kinda does). I'd think having a "should respond with NXDOMAIN (RCODE 3 - Name Error)" (or 'Non-Existent Domain') the first time it is used would head off future comments.... > consideration on draft-appelbaum-dnsop-onion-tld-01 which (if necessary) can > be addressed in one last round of edits-to and review-of the document; and > if someone would also kindly point me towards the process for seeking a > “call to adoption”, I would be most grateful. The process for seeking a "call for adoption" is that you email the chairs, saying that the authors believe that the document has had some discussion, that it is relevant and that you would like them to start a call for adoption. Actually starting the CfA is at the chair's discretion - they can say the document hasn't been discussed, is off-topic, that they'd like the WG to first focus on <something else>, that there is an interim coming up soon and would like the document to be discussed there some more, etc. When you do ask for the CfA it is helpful to also state that you are not personally aware of any IPR that applies to this draft, or if you have, that is has been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Note that once the work is adopted by a WG, it becomes "property "of the WG -- the chairs select authors (usually they keep the existing ones), but the content has to be what the WG wants - the authors incorporate the WG's consensus (and if they cannot figure out what the WG wants, they can ask the chairs to determine consensus on a point). > I hope to see all of the DNSOP processes - both established and ad-hoc - > interlock in a graceful and well-oiled manner. > > Many thanks and best wishes, > > - alec > Hope this was helpful. W > — > Alec Muffett > Security Infrastructure > Facebook Engineering > London > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
