This should really be two documents

[ekr]

Despite the way it's phrased as "requirements" but really there's almost no relationship between the use cases where you want to discover which general-use resolver you might use locally (Section 3) and the use cases where you are might discover which resolvers to use for a specific domain (Section 4). It's not at all obvious that you would want to use the same technology for these. If we are to have a requirements document, we should split these into two, one for each workstream.

[ekr]

Or maybe 3, because DNS is yet different.

[ekr]

In addition, the security properties of these are likely to be very different, in particular because we don't know how to solve the local discovery problem with reasonable security.

[chris-box]

I'm open to splitting it; let's see what further opinions we get from the working group.

[martinthomson]

My suggestion is to cut Section 4. Then the document has just the most important stuff.

[tfpauly]

I would prefer to, if we split, split 3 and 4, but keep both. There's mechanism work to do on both, and while 3 might be harder, we shouldn't not do 4.

[ekr]

I could live with this. And then we'll need to update the security considerations to match

…

On Thu, Sep 10, 2020 at 7:38 AM Martin Thomson ***@***.***> wrote: My suggestion is to cut Section 4. Then the document has just the most important stuff. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIPLII547O2FM75NNHUYVDSFDQGRANCNFSM4RFA2N3A> .

[martinthomson]

4 as a separate document is probably fine. Honestly, most of Section 4 seems weak to me, but 4.2 is a completely different use case that would benefit from standalone treatment.

[Andrew-419]

I'm struggling to see the advantage of having separate documents versus multiple sections in a single document. I can see advantages in the latter approach, not least of which to have a single repository for all of the use cases and associated requirements, noting that different use cases may share some of the same requirements.

[ekr]

I think we should be able to gather consensus on one set of use cases and requirements, while deferring the others. That's facilitated by having separate documents.

[Andrew-419]

It seems premature to be proposing to split the document without further discussion and does risk some use cases and requirements effectively being abandoned, irrespective of their importance to users.

[ekr]

It seems premature to be proposing to split the document without further discussion

I'm proposing it so we can discuss it.

and does risk some use cases and requirements effectively being abandoned, irrespective of their importance to users.

What I'm proposing is that we defer those use cases and requirements until we have addressed the first set of use cases.

[Andrew-419]

It seems to me that the various types of same provider auto upgrade (ie including with DNS forwarders) are the most pressing need to be addressed. However, it also feels important to identify the other items to include in the use case and requirements universe, even if these are to be addressed later, as well as to be clear which if any are to be excluded.

It would be ideal for the WG to adopt a document that gives clarity on the totality of use cases to be covered, with an order of priority if necessary, rather than to only bring forward a document containing a few at first with an expectation that some others may be done later. So on that basis I'd prefer the document to move as is rather than being split - if there is a view that some use cases should be dropped I think that it would be better to have that discussion now rather than postpone it.

[nicolaileymann]

I think it's a good idea to start with single document describing all the requirements and use cases which will be covered. If we split the the document now I see the risk that only some of the requirements will be covered and others not (e.g. if only one the documents is moved forward). Therefore I am more in favour of having a single document as a basis and to move this document forward. Lets have the dicussion now what we want to include and what not.

[chris-box]

Good arguments on both sides. I agree we do need all requirements described somewhere, but we also need small enough drafts so that are manageable and can be reasoned about. On the list Glenn proposed dividing into two or perhaps three. I tend to agree, so draft -01 is now a single use case. This does of course mean that other requirements drafts are also required. Authors of those could of course grab text from draft -00 and relevant closed issues in this repo.