+1
The issue here is not just the charter. QUIC is a WG with over 100 active participants. It has far greater need to keep focus than others.
In particular, when a WG chair asks 'why are you bringing this here when it is really not QUIC specific', it is important to have a better answer than:
"I'm not asking this working group to do anything. Just socializing
something that generated a lot of discussion on the IETF list that mightbe of interest to the Quic community."
The problem I have with your approach is that when people raised issues, you didn't try to address them, you just told them they weren't issues.
One of the things I really like about the new RFC/ID format is that we can now have diagrams showing the impact of a proposal. Turning a two party protocol (initiator/responder) into a three party protocol (adding a DNS resolver) to shave a couple of packets doesn't look like a win to me. In fact it looks like a de-optimization if the information needed isn't already in-cache.
Managing the number of Web servers Google has facing the world is hard. Its the sort of infrastructure that when scoping a possible acquisition, I would always have to budget several million dollars for a ground up replacement simply because such infrastructures must by their very nature rely on a great depth of local arcana that will walk out of the door the day the people carrying it in their heads walk out the door. I would certainly never presume to tell the operators of such systems that moving from the WebPKI to DANE is easy.
Google already has free WebPKI certs for itself through GTS and for everyone else through LetsEncrypt. So the value prop for DANE is limited to shaving packets. And that requires people to sign their Zones which is expensive because someone is going to have to crack open a manual and read it. And that costs real money when folk are billing at $300-$500/hr.
The whole problem with DANE start to finish was that it was DNSSEC people looking for a problem to solve. And they chose the wrong problem. The only good reason to deploy DNSSEC is to publish security policy. And that isn't viable unless you have
1) A means of expressing the security policy
2) A means of automating publication of the security policy to the DNS zone
3) A complete overhaul of the DNS client-resolver protocol to make THAT efficient.
SMTP over TLS is not a useful paradigm because email is store and forward and we don't care about latency.
The DNS world keeps shooting itself in the foot here and then complaining nobody is taking them seriously. TLSA is too limited as a means of describing security policy. RFC 6763 is the approach to build on as I show in:
I do not have a mechanism for automating publication of the security policy to the DNS but that is going to be one of the things the Mesh eventually does for free as devices are connected to a personal Mesh.
DPRIV is another example of DNS world refusing to see beyond its limited horizons and then complaining nobody is using their stuff. It was abundantly clear that we needed to fix the broken DNS client resolver protocol if there was going to be any takeup of DPRIV. Instead we were told we must do this in a year so the only thing we can look at is DNS over TLS which will require TCP fast start to be sufficiently performant.
I don't just suspect my work was sabotaged under BULLRUN, I know because one of the people responsible apologized to me personally. I am pretty sure that DPRIV and DANE were among the proposals deliberately sabotaged so as to delay deployment of cryptographic systems that worked.
It is so easy for a whispering campaign to persuade people that the 'evil CAs' are the ones only working for themselves. So ignore the proposals they have been working on and circulating for five years now, schemes that don't require a kernel change and instead do this thing someone just scribbled on the back of a paper napkin in crayon.
That is all in the past now. We all have a job to do and it is to secure the net. And we can't do that by thinking small. And we certainly can't do that if we don't listen to and try to understand the stakeholders who have to deploy if it is going to work.
On Wed, Apr 21, 2021 at 1:07 PM Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
Michael, I hav eno idea whether your work was or was not appropriate for
the QUIC working group.
Arguing that working group chairs an not declare things out of scope
weakens your overall argument. Working groups have charters. The
chairs are expected to work within the charter. Working group email
lists are for discussion of topics relevant to the working group.
Now, I will grant that charters are not precise. Topics are not
precise. And chairs should (and generally do) err on the side of
allowing some latitude.
But claiming that chairs can not rule things as being out of scope does
not match our process, and would hamper our work. (Who has, as WG
co-chair, suggested to more than one author team that the independent
stream would make a better home for their work, as it does not fit the
charter of the working group.)
Yours,
Joel
On 4/21/2021 12:47 PM, Michael Thomas wrote:
>
> On 4/20/21 10:26 PM, Brian E Carpenter wrote:
>>
>> Every WG Chair, especially for a WG that has tight focus on a specific
>> goal, meets the problem of potentially off-charter discussions that
>> potentially hamper progress.
>
> This is an often repeated refrain, but I question its actual impact.
> People reply to things because they have an opinion and are interested
> enough in the subject to make time for it. Posing this as a zero sum
> game is a fallacy: if they aren't interested enough at the business at
> hand they simply won't reply at all. At some point things become noise,
> but a few messages back and forth is hardly that point. In fact,
> slightly off topic posts can bring useful insight to working groups, and
> can be extremely useful for outsiders to understand what is going on. I
> know of no other way to get that understanding other than simply asking
> on the working group list. Do you?
>
> That and to be told by a working group chair *in their capacity* to go
> away (and away to where? no answer) is dysfunctional, and sends a clear
> message that interlopers will not be tolerated.
>
> Mike
>
