On Wed, Sep 7, 2022 at 6:13 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 08-Sep-22 08:00, S Moonesamy wrote:
> Hello,
> At 10:06 AM 07-09-2022, Robert Sparks wrote:
>> After a series of trials used to gather feedback from the community,
>> the IETF has switched from Jabber to Zulip as its chat service.
>
> I assumed that XMPP was in wide use in the IETF community and still
> in use on the internet. I gather that is not the case given that RFC
> 6120 is following a path similar to RFC 959 [1]. It is high time to
> consider what to do with "standards" which no longer have community support.
Why? A Proposed Standard can sit on the books and does no harm. Sometimes,
it turns out that there is a whole user community for such a standard
that we don't know about, for some version of "we".
That is not really true. A proposed standard can and often does prevent others trying to address a problem.
Before DPRIV, I proposed a DNS client-resolver protocol that leveraged a TLS key exchange to secure a UDP based replacement protocol. Two years later DPRIV was started and at the first meeting we were told that this problem is so very very urgent, there is no time to consider any proposals except for running DNS client interactions over TLS because it 'had to be done in a year'.
Having seized the floor, sharp elbows stopped anyone from proposing a practical approach to the problem until QUIC came along and the absurdity of claiming Fast TCP start, a solution requiring a kernel change would solve the performance problem became to much. So now, eight years after I made my original proposal for DNS client-resolver over UDP, there is finally an RFC but of course, much of the deployment momentum has been dissipated.
We has the same problem today with DANE and security policy. Again against my advice, DANE adopted an approach that is technically defective. If you want to deploy security policy you have to consider the whole process of service discovery. That means considering the SRV and TXT records FIRST, not treating them as an afterthought. In other words, start with RFC 6763 and work from there. That is the approach I adopt in the Mesh.
I have a security policy system that works and is not tied to one transport protocol. But I am pretty sure that I would face demands to recast it in DANE terms because that is the 'proposed standard' even though it is dead on its feet for everything but SMTP STARTTLS.
Recognizing that standards have failed or failed to thrive can be a very valuable and positive contribution to the community because recognizing failure clears the stage for possible success.
