Re: agent draft updated

[Damien Miller <djm%mindrot.org@localhost>]

On Thu, 24 Aug 2023, tom petch wrote:

> 
> From: ietf-ssh-owner%NetBSD.org@localhost <ietf-ssh-owner%NetBSD.org@localhost> on behalf of tom petch <ietfc%btconnect.com@localhost>
> Sent: 23 August 2023 16:57
> _______________________________________
> From: ietf-ssh-owner%NetBSD.org@localhost <ietf-ssh-owner%NetBSD.org@localhost> on behalf of Damien Miller <djm%mindrot.org@localhost>
> Sent: 23 August 2023 06:45
> 
> On Tue, 22 Aug 2023, Jeffrey Hutzelman wrote:
> 
> > Indeed, independent submissions cannot normally create new registries.
> > That's OK, though, because you don't actually need them. The purpose of the
> > independently-submitted information document would be to document the
> > existing protocol, both for the benefit of the community already using it
> > and as a starting point for standardization work. Such a document can simply
> > list the code points already used or reserved (the tables already in your
> > draft) and need not actually create any registries. The registry creation
> > can wait for publication of the eventual IETF-stream document.
> 
> Ok, I've uploaded a version without the new IANA registries.
> 
> https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent-10
> 
> I assume it's okay to request new entries in existing registries?
> (This draft does)
> 
> <tp>
> It depends and here it is not.
> 
> The registry is defined as what is now known as Expert Review in the RFC that created the registry RFC8308  and that is explained in RFC8126 as
>   (Formerly called "IETF Consensus" in the first edition of this
>    document.)  With the IETF Review policy, new values are assigned only
>    through RFCs in the IETF Stream -- those that have been shepherded
>    through the IESG as AD-Sponsored or IETF working group documents
> 
> So it must be an IETF WG document or AD-sponsored.  If the policy were Expert Review or RFC Required you would be ok but you are not.  And changing the policy cannot be done , that would likely require Standards Track.
> 
> <tp2>
> And that is precisely what is proposed by
> 
> draft-yee-ssh-iana-requirements
> 
> which is in state IESG approved with IANA Action needed so watch this space, that is the IANA SSH registries Space

So it looks like RFC9519 has been published to relax the SSH-related IANA
registries: https://datatracker.ietf.org/doc/rfc9519/ - this is great news
IMO and will hopefully make it getting protocol extensions documented as
RFCs tenable again.

Given this, I've restored the IANA considerations section to the agent
draft and would like to start the process for getting it published.
Please take a look at the latest version:

https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent-12

If you were following along last year, the substantive changes since the
last version are 1) restoring the IANA considerations section, 2) improved
wording around the legacy @openssh.com channel names and 3) explicitly
carving out a section of the message number space for organizational-
local use (since I'm aware of some orgs that have done local extensions
to the agent protocol).

PTAL.

-d