[ Top post ] What do other think here -- do we want to decide on the discovery and binding problem first, or do we think that we should choose a document and start working on that (and possibly add in discovery / binding later)?
<no-hats> I'd personally like to start working on a document - i think it helps focus us in something concrete, and will move the discussion from an abstract type thing to actually getting work done... </no-hats> W On Thu, Apr 9, 2015 at 10:36 AM, Phillip Hallam-Baker <[email protected]> wrote: > On Tue, Apr 7, 2015 at 3:33 PM, Warren Kumari <[email protected]> wrote: >> Hi all, >> >> We are planning on starting a call for adoption on the documents on April >> 15th. >> >> At the meeting in Dallas we heard that a number of people didn't feel >> that they had enough information / knowledge of the documents to make >> in informed decision, so we are giving y'all some extra time to read >> the documents before kicking off the CfA. >> >> Our plan is to have a *single* call for adoption, listing all 3 >> documents, and ask people to put in a *clear* indication for each >> document if they would like it adopted or not. >> >> We will then decide which we will be adopting -- if we get really >> strong support for multiple documents we will adopt multiple... > > I think that the more important question is how we partition the > problem up and how we address each part. Documents are only a bunch of > text and it is doubtful much of what is there now will survive if > anything. > > As I see it, there are two sub-problems: > > 1) How does a client discover and establish a binding to a DPRIV service? > 2) What transport/sessions(s) are supported for queries? > > Before answering either, I think it is pretty clear that at some point > in the future, SPUD will be the logical choice for transport/session. > It is also clear that we should not build research on research. > > So the way forward as I see it should be that our answer to (1) should > support some mechanism for advertising alternative transports so we > can use TLS for now and make use of SPUD if and when it matures. > > > The hard part of the problem is all in problem 1. I designed, > implemented and wrote the draft for the transport/session part in a > day. It isn't a difficult problem (if you are only solving DNS, SPUD > is a lot harder). The hard question is how to discover and establish a > binding to the DNS service before you have DNS. -- 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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
