[ih] IETF relevance (was Memories of Flag Day?)

[Dave Crocker]

On 8/29/2023 8:42 PM, John Klensin wrote:
> Depending on how "originated" is defined and what hair-splitting one 
> wants to do,

I meant a very simple distinction:  Coming to the IETF with an existing 
specification that already has a group constituency associated with it 
and supporting it -- and typically already has functional code -- versus 
starting an IETF discussion without a spec or with a variety of specs as 
proposals, and then producing a fresh specification.

FTP, email, telnet, DNS were originated in an IETF-like mode. MIME was 
originated in the IETF.  HTTP/HTML were not. SPF, DKIM, DMARC, and ARC 
were not.

These days, the IETF does refinement and community promotion, not spec 
origination.


> I can't imagine someone coming to the IESG today, saying "I see this 
> problem and I think the IETF should form a WG and figure out a solution".

And yet people regularly think they can do exactly that.  In spite of 
zero track record of success for that model in decades, certainly for 
applications, and I suspect more generally.


> I could see a refinement of an existing successful protocol coming 
> much closer to "originating" in the IETF, but that is a bit of a 
> different category too.

Starting over is not refinement.  That would be origination. Refinement 
is not origination.


> Now, I think there might be a useful distinction between protocol work 
> that is brought to the IETF that is thought to be complete and with 
> the expectation that the IETF will approve it without making 
> substantive changes and work that is more preliminary and where the 
> IETF is expected (or at least encouraged) to do  significant 
> refinement and improvement.

The very long-standing view on this is that the IETF does not 
rubber-stamp.  Meaningful technical work is required for getting IETF 
standards-track imprimatur.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker at mastodon.social