Subject: [Curdle] Time to Review IANA SSH Registries Policies?

From: Sean Turner <[email-masked]>
Date: Wed, 3 Feb 2021 14:51:28 -0500

Hi! The IANA registries for SSH were established long ago when the fashion was to require an RFC to set any value (see https://datatracker.ietf.org/doc/rfc8126/ for definitions of the various registry rules). IPsec, TLS, and others initially did the same thing, but have since backed down the high bar and gone to expert review for many if not all of their registries. Is there interest in reviewing the SSH registries to see if it makes sense to move them to expert review (or some other level)?

This would likely result in setting up a pool of experts and providing them with some instructions, but that’s been done before for other registries.

spt

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Feb 2021 19:54:46 +0000

Speaking as an individual,

> Is there interest in reviewing the SSH registries to see if it makes sense to move them to expert review (or some other level)?

I support this and would contribute to the review.  (I'm author of a draft which is currently in the WG adoption phase; https://datatracker.ietf.org/doc/draft-rsalz-update-registries/

---

From: Ron Frederick <[email-masked]>
Date: Wed, 3 Feb 2021 12:01:15 -0800

I’m not currently familiar with the “expert review” process that’s in place for these other registries right now, but (also speaking as an individual) I’d be interested in learning more and would potentially be interested in participating in such a review depending on the time commitment involved.

On Feb 3, 2021, at 11:54 AM, Salz, Rich <rsalz=[email-masked]> wrote:
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

-- 
Ron Frederick
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Feb 2021 20:11:17 +0000

>    I’m not currently familiar with the “expert review” process that’s in place for these other registries right now, but (also speaking as an individual) I’d be interested in learning more and woul…

See https://www.rfc-editor.org/rfc/rfc8126.html#page-20 for details.

The IESG appoints the experts, almost always based on the Area Director's recommendations.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Feb 2021 15:16:23 -0500

+1

Restrictive registration requirements contradict the principle of
'permissionless innovation'. If the IETF is the place you go to get
permission to innovate, we are doing it wrong.

Restrictions on registration are also counterproductive as they don't stop
people innovating, they just stop the innovations being tracked accurately.
When the SAML TC asked me to register SRV code points for SAML, the
response I got back from IETF was of the form, 'we have set up a committee
to look at forming a WG to decide on procedures for registering new
services, come back in five years, maybe'. So I wrote my own and those are
the standard SRV discovery tags for SAML.

I would like the IAB to put out a policy that every registry be made open
registration except in cases where the code space itself is limited (e.g.
IP version numbers, Port numbers, etc.).

This should even be the case for cryptographic algorithms. In fact it
should be especially for cryptographic algorithms because we don't really
do any reviews for security except to reject the ones we know are absurdly
rubbish. We just don't have bandwidth to do any vetting beyond the tiny set
of algorithms we use ourselves.

So where do RFCs, documentation and expert review come in? I think they
still have a place but think of this more as an Amazon.com star rating.

1 Star: The code point has been registered to a named purpose which may or
may not be intelligible.
2 Stars: As 1, plus the purpose described in a document which is accessible
3 Stars: As 2, plus an expert has reviewed the document, it is not
obviously stupid.
4 Stars: As 3, plus there is a published RFC
5 Stars: As 4, plus the spec is a proposed standard.

And we can also add in 0 stars for the case where multiple parties contest
the use of the same code point and as a result it leads only to pain,
misery and death.

On Wed, Feb 3, 2021 at 2:55 PM Salz, Rich <rsalz=[email-masked]>
wrote:

> > Is there interest in reviewing the SSH registries to see if it makes
> sense to move them to expert review (or some other level)?
>
> I support this and would contribute to the review.  (I'm author of a draft
> which is currently in the WG adoption phase;
> https://datatracker.ietf.org/doc/draft-rsalz-update-registries/
>
>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 3 Feb 2021 12:28:20 -0800

Sean Turner <[email-masked]> writes:

> Hi! The IANA registries for SSH were established long ago when the
> fashion was to require an RFC to set any value (see
> https://datatracker.ietf.org/doc/rfc8126/ for definitions of the
> various registry rules). IPsec, TLS, and others initially did the same
> thing, but have since backed down the high bar and gone to expert
> review for many if not all of their registries. Is there interest in
> reviewing the SSH registries to see if it makes sense to move them to
> expert review (or some other level)?

I suppose Expert Review is a possibly. I am not entirely sure how the
current Area Directors will select the pool names of experts to provide
to the IESG. The SSH working group mailing list is still running, but
that group was disbanded long ago and CURdle is in the process of
wrapping up right now.

> This would likely result in setting up a pool of experts and providing
> them with some instructions, but that’s been done before for other
> registries.

True, but I am under the impression that the pool of experts were being
drawn from highly active groups.

I agree that an update to

  https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml

may be useful. Possibly to even include commonly used private extensions
for some of the options.

	-- Mark

---

From: Sean Turner <[email-masked]>
Date: Wed, 3 Feb 2021 15:28:24 -0500

> On Feb 3, 2021, at 15:11, Salz, Rich <[email-masked]> wrote:
> 

We would set up a designated expert (DE) pool that includes a couple of people. There aren’t all that many requests, but it is good to have more than one person in the pool in case they get hit by a piece of space junk. The DEs are appointed by the IESG, and as Rich noted, are almost always based on AD recommendations. Typically, the AD asks the WG chairs because they have a sense of who has the expertise.

IANA has a registry tool that accepts requests (https://www.iana.org/form/protocol-assignment). To make sure we have oversight into what the DEs are doing that tool will shoot the request to a publicly available mailing list, e.g., [email-masked]. The experts can self-manage who reviews the request; sometimes there is an agreement to do round-robin but in my experience it is who gets to it first.

When we write up the I-D that would make this change we can also specify a review period after which the ADs just back in the mix; typically it’s two weeks from request. Likewise, we can also provide some guidance for the DEs and maybe a disclaimer that says the DEs are doing and to not infer anything beyond that. E.g., in TLS some people were touting that they had a registry entry as if it was some kind of endorsement from the WG, when in fact nothing was farther from the truth.

The DEs could also provide updates the chairs at every IETF meeting to highlight the assignments that were made since the last meeting.

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 3 Feb 2021 16:34:26 -0500

A good point I should forward my email to the SSH list.

As for where an I-D would land, I am not wed to any particular group and do not think it absolutely has to go through CURDLE or even through a WG.  I could write an I-D, share it around on this and the SSH lists, present to SECDISPATCH, and have them decide its fate.

spt

Sent from my iPhone

> On Feb 3, 2021, at 15:26, Mark D. Baushke <[email-masked]> wrote:
> 
> The SSH working group mailing list is still running, but

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Feb 2021 20:19:50 -0500

Hi,

I am personally in favor of lowering the bar to register code points. In my
opinion, this encourages/documents innovation without compromising
interoperability as ssh has some negotiating capabilities and is not part
of a system that almost requires any implementation to implement any
proposed options -  as DNS for example. This why I have different opinions
for DNS and SSH related to the bar of acceptance for registries (see dnsop
discussion earlier this month).

I hope the draft will not be limited to the review but will perform a
general clean-up of the registry. This is something I had in mind while
never took the time to do, so I am happy you step in.

The curdle WG has become the defacto ssh WG, and at least the place most
ssh discussions at the IETF happened. Rechartering curdle to ssh could have
been an option, though they do not share any letters... We suggested Ben a
ssh dedicated WG could be created as there are other interests for ssh
(post quantum). So it seems to me this mailing list is the right place to
discuss it.... for now.

Yours,
Daniel

On Wed, Feb 3, 2021 at 4:34 PM Sean Turner <[email-masked]> wrote:

> As for where an I-D would land, I am not wed to any particular group and
> do not think it absolutely has to go through CURDLE or even through a WG.
> I could write an I-D, share it around on this and the SSH lists, present to
> SECDISPATCH, and have them decide its fate.
>
> spt
>
> Sent from my iPhone
>

-- 
Daniel Migault
Ericsson

---

From: Sean Turner <[email-masked]>
Date: Wed, 3 Feb 2021 23:04:39 -0500

Apologies I should have also sent this message to the SSH list.

Cheers,
spt

> On Feb 3, 2021, at 14:51, Sean Turner <[email-masked]> wrote:
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Feb 2021 08:23:30 -0500

> On Feb 3, 2021, at 20:19, Daniel Migault <[email-masked]> wrote:
> 
> I hope the draft will not be limited to the review but will perform a general clean-up of the registry. This is something I had in mind while never took the time to do, so I am happy you step in.

Consider me a willing victim. I will start with the registration policies and see where the discussion goes (i.e., I am not averse to doing more).

spt

---

From: Daniel Migault <[email-masked]>
Date: Thu, 4 Feb 2021 08:28:02 -0500

Sounds good to me. Thanks!

Daniel

On Thu, Feb 4, 2021 at 8:23 AM Sean Turner <[email-masked]> wrote:

> Consider me a willing victim. I will start with the registration policies
> and see where the discussion goes (i.e., I am not averse to doing more).
>
> spt

-- 
Daniel Migault
Ericsson

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Feb 2021 09:32:02 -0500

I am going to try to avoid the take your rock to the other WG dance, by requesting time on secdispatch’s agenda. Just wanted to let everyone know so it doesn’t seem like venue shopping.

spt

> On Feb 4, 2021, at 08:28, Daniel Migault <[email-masked]> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Feb 2021 15:11:37 +0000

>    I am going to try to avoid the take your rock to the other WG dance, by requesting time on secdispatch’s agenda. Just wanted to let everyone know so it doesn’t seem like venue shopping.

Good plan.

Thanks for stepping up to initiate this.

---

From: "Jeffrey T. Hutzelman" <[email-masked]>
Date: Thu, 4 Feb 2021 22:12:40 +0000

I'm not specifically opposed to this, but many of ssh's registries are for string identifiers (e.g. algorithm names) where there is a straightforward mechanism for individual implementors to define unique, interoperable identifiers without going through the registry (specifically, identifiers of the form name@domain are permitted, as assigned by the owner of that domain).

Certain values, such as message numbers, are small, and thus scarce. The current policy for these is Standards Action, which IMHO is appropriate giving the size of the available namespace as well as the core protocol functions they serve. For the most part, it is intended that new values for these codes would be allocated only as part of a revision of the base protocol suite, rather than in an extension.

That said, there are some other attributes (particularly, disconnect reasons, channel open failure reasons, and extended channel data types) for which significant namespace is managed under the IETF Review policy, with a small portion set aside for private use. It does seem like it would be reasonable to update these to use Expert Review instead. The ultimate question, then, is whether it is worth the (admittedly small) effort.

-- Jeff

________________________________
From: Sean Turner <[email-masked]>
Sent: Thursday, February 4, 2021 00:51
To: SSH List
Cc: Curdle List
Subject: Re: Time to Review IANA SSH Registries Policies?

Cheers,
spt

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 5 Feb 2021 01:15:16 +0200

Jeffrey T. Hutzelman writes:
> I'm not specifically opposed to this, but many of ssh's registries are for
> string identifiers (e.g. algorithm names) where there is a straightforward
> mechanism for individual implementors to define unique, interoperable
> identifiers without going through the registry (specifically, identifiers of
> the form name@domain are permitted, as assigned by the owner of that domain).
> 
> Certain values, such as message numbers, are small, and thus scarce. The
> current policy for these is Standards Action, which IMHO is appropriate giving
> the size of the available namespace as well as the core protocol functions
> they serve. For the most part, it is intended that new values for these codes
> would be allocated only as part of a revision of the base protocol suite,
> rather than in an extension.

I agree on what was said above. I do not think changing those string
registries to Expert review would really help anything, as the corrent
way way of allocate [email-masked] is
much easier than even to go to the Expert and ask for the review... On
the other hand if that algorithm gets implemented by multiple
implementations then writing and RFC about it is not high bar.

Most of the Expert review allocations end up having RFCs anyways
(speaking as an IANA expert for IPsec), or at least have some stable
reference in some other SDOs.

Currently only Message Numbers, and Publickey Subsystem Status codes
have Standards Action registration procedure, and I think at least
Message Numbers should be kept with that high bar.

> That said, there are some other attributes (particularly, disconnect reasons,
> channel open failure reasons, and extended channel data types) for which
> significant namespace is managed under the IETF Review policy, with a small
> portion set aside for private use. It does seem like it would be reasonable to
> update these to use Expert Review instead.

Yep. Those registries do not have string format, so lowering the bar
there from IETF Review to Expert review could be helpful. Perhaps even
the last numeric registry Pseudo-Terminal Encoded Terminal Modes too.

On the other hand only following registries have had any allocations
after the initial work finished around 2006.

  - Message Numbers (integer)
  - Pseudo-Terminal Encoded Terminal Modes (integer)
  - Connection Protocol Subsystem Names (string)
  - Key Exchange Method Names (string)
  - Encryption Algorithm Names (string)
  - MAC Algorithm Names (string)
  - Public Key Algorithm Names (string)

And my understanding is that those string registries used @domain name
format for some time before someone actually decided to create RFC to
register those things, so this did not cause any issues on the
interoperability.

Usually the problems have been when people have used those @domain
name formats, and there is no documentation how they work, thus others
have had to reverse engineer or guess how they work, and didn't get
things right. Requiring RFC solves that issue, as then you must have
a documentation what that thing means...

> The ultimate question, then, is whether it is worth the (admittedly
> small) effort.

I would almost think it would not even be worth the effort. At least
we should show that it has caused some issues in the past before we
invest too much time on this.
-- 
[email-masked]

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 4 Feb 2021 23:43:45 +0000

>permission to innovate, we are doing it wrong.

+1.  To give a real-world experience of "expert review", when I tried to go
through the process on $unnamed-wg there was an experts group that you
couldn't contact who had a non-public mailing list where decisions were made
in secret, but that didn't matter since there was no way to contact them.
Eventually it got sorted out by one or two people involved in the process
going out of their way to help, but when done as it should have been the
process was more reminiscent of Kafka than the IETF.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Feb 2021 00:18:22 +0000

Hi Peter,

On 04/02/2021 23:43, Peter Gutmann wrote:
> through the process on $unnamed-wg 

It's not like you to be shy like that:-)

> there was an experts group that you

I think that's a reasonable point. From the POV of the IESG
and I guess the DEs, handling things more informally likely
seems easier, but I agree that may well make the process look
Kafkaesque to someone wanting a codepoint.

Maybe we ought try up our game the next time we do one of
these "re-work IANA" things for some protocol. Just as we
now have the "recommended" column for TLS ciphersuites, (and
I think that makes things better overall and can be copied
for other registries), it might be a good idea to have an
open mailing list for each registry or set of DEs or some
such. (IIRC, the URI schemes registry does have such a list,
and the magic incantation one must learn is to try get people
discussing your proposed scheme on that list, without too
much scorn, before you can hope for success with the DEs:-)

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 5 Feb 2021 02:23:08 +0000

> the form name@domain are permitted, as assigned by the owner of that domain).

It is possible to mark [email-masked] as private/experimental and not require review. The only issue would be if such identifiers are needed for interop and the table has to be in IANA.  Is that the case?

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 4 Feb 2021 19:52:47 -0800

Salz, Rich <rsalz=[email-masked]> writes:

>     > identifiers without going through the registry (specifically,
>     > identifiers of the form name@domain are permitted, as assigned
>     > by the owner of that domain).
> 
> It is possible to mark [email-masked] as private/experimental and not
> require review. The only issue would be if such identifiers are needed
> for interop and the table has to be in IANA. Is that the case?

Names with @dom.ain are explicitly NOT to be in IANA per
RFC 4250 section 4.6.1

...elided...
| 4.6.1.  Conventions for Names
| 
|    All names registered by the IANA in the following sections MUST be
|    printable US-ASCII strings, and MUST NOT contain the characters at-
|    sign ("@"), comma (","), whitespace, control characters (ASCII codes
|    32 or less), or the ASCII code 127 (DEL).  Names are case-sensitive,
|    and MUST NOT be longer than 64 characters.
| 
|    A provision is made here for locally extensible names.  The IANA will
|    not register, and will not control, names with the at-sign in them.
| 
|    Names with the at-sign in them will have the format of
|    "name@domainname" (without the double quotes) where the part
|    preceding the at-sign is the name.  The format of the part preceding
|    the at-sign is not specified; however, these names MUST be printable
|    US-ASCII strings, and MUST NOT contain the comma character (","),
|    whitespace, control characters (ASCII codes 32 or less), or the ASCII
|    code 127 (DEL).  They MUST have only a single at-sign in them.  The
|    part following the at-sign MUST be a valid, fully qualified internet
|    domain name [RFC1034] controlled by the person or organization
|    defining the name.  Names are case-sensitive, and MUST NOT be longer
|    than 64 characters.  It is up to each domain how it manages its local
|    namespace.  It has been noted that these names resemble STD 11
|    [RFC0822] email addresses.  This is purely coincidental and has
|    nothing to do with STD 11 [RFC0822].  An example of a locally defined
|    name is "[email-masked]" (without the double quotes).
...elided...

Please note that [email-masked] is a different extension than
[email-masked] due to the case-sensitive nature of the name.
(Yes, it is confusing.)

	Be safe, stay healthy,
	-- Mark

---

From: denis bider <[email-masked]>
Date: Sat, 6 Feb 2021 14:56:20 -0600

Some general thoughts on this:

(A) When I'm implementing new ideas, it would be nice to have a more
straightforward way of registering and documenting them.

(B) Registration is needed primarily for coordination. Primarily,
incompatible ideas must avoid using the same (numeric or string)
identifiers on the wire. This primary purpose can be met without
documentation. If the identifier space is large compared to demand, there
need be no specific standards that registrations must meet.

(C) However, registration also helps discover ideas developed by others. In
this case, documentation is essential if one wants to understand and use
those ideas.

(D) So quality of documentation is important. Lots of people who try
writing specs, write specs of questionable usability without lots of
guidance, review, iteration, and cajoling from others. The spec writer
experiences this as suffering. However, this suffering ensures a useful
result.

(E) Nevertheless, there is suffering. Therefore, if the process is too
onerous, the spec writer learns to avoid it.

I'm thinking (E) is a problem for the IETF - the registration + spec
polishing burdens are onerous. Two years to publish an RFC is a lot. It
vastly reduces the number of specs people are willing to write.

For most things, I'm not willing to go through this effort. Instead, I
might publish an internet-draft, and then make no effort toward an RFC
because the draft, even though informal, is discoverable, and costs 5% of
the effort of an RFC. There are lots more things for which I'm willing to
write an internet-draft, than things for which I'm willing to write an RFC.

I think the IETF could ease the registration and documentation burdens to
increase the likelihood that:

- Registration happens, for coordination purposes.

- Documentation is published that otherwise would not be, even if it's not
perfect.

I think there are opportunities here that are currently being missed.
Changing some of the SSH registries to expert review could be a step in
this direction, but it depends on what the expert review practically looks
like. If it's going to look like Peter described, where you can't actually
reach the experts, then I'm not sure if it's an improvement. :)

denis

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 7 Feb 2021 10:38:08 +0000

denis bider <[email-masked]> writes:

>For most things, I'm not willing to go through this effort.

It is an excessive amount of effort in many cases.  Some years ago I assisted
in the creation of an RFC used by an industry body that amounted to "if you
see the value 27 in this location, assume X".  The RFC itself was something
like ten to fifteen pages of IETF-mandated gunk that no-one in the industry
body knew what to do with, it was only the fact that I sort-of volunteered to
do the work that prevented use of the previous approach, "take the last-
currently-used value and add ten or twenty and hope no-one ever gets to it".
There'a Laffer curve at play here, and the current process seems to be too far
off to the right of it.

Not sure what the solution is, but it should at least be less painful to
comply with the process than to circumvent it.

(My suggestion for a Security Considerations section that read "The number 27
may be offensive to some religions; caution is advised", just so we could say
something interesting somewhere, wasn't accepted).

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 7 Feb 2021 14:55:09 +0000

*   - Documentation is published that otherwise would not be, even if it's not perfect.

Especially now that internet drafts do not expire, all that’s necessary is to write one of those.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 7 Feb 2021 22:41:28 -0500

+1

Registration processes can very easily turn into ring kissing requirements.
And especially so when the authority is a voluntary organization.

Lots of people get really, really excited at the idea that they are adding
value by preventing work that might lead to vague, consequences that they
can't quite put their finger on.

And then when people go through the process and end up waiting six months
for those people to make up their minds, well we are a
voluntary organization so people should thank us for the very important
work we do.

I have a rather different view. I think that when someone puts themselves
in the way of someone else's critical path, they are making a commitment to
deal with the issue expeditiously and if that isn't possible, the answer is
to not make things critical path.

Given the number of times we have people pointing out the IESG are
overworked, we should look to get out of the way as much as possible, not
stand athwart the tides of history yelling stop.

---

From: denis bider <[email-masked]>
Date: Mon, 8 Feb 2021 10:47:18 -0600

:D

Well argued.

The thing with a person or group getting out of the way is that this
vacates the opportunity for being in the way. The opportunity continues to
exist and becomes open to the next person.

This is generally the problem with power. Things work better with
coordination. We're therefore willing to pay a substantial cost to
coordinate. The role of the coordinator is a form of power. This power
works best if the coordinator coordinates, and otherwise gets out of the
way. But to use power in restrained ways is to serve, and to serve is a
burden. Therefore, the people who apply for such positions are (1)
reluctant volunteers who would serve, and (2) folks who see it as an
opportunity to "lead" and "govern".

Reluctant volunteers will gladly step away in favor of those who have more
enthusiasm, and those who have more enthusiasm are the ones who would
"lead" and "govern". And that's how we simultaneously want and need
coordination, but somehow it always devolves into some kind of tyranny.

Speaking very generally, the IETF is just a microcosm and a special case.

On Sun, Feb 7, 2021 at 9:41 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> +1
>
> Registration processes can very easily turn into ring kissing
> requirements. And especially so when the authority is a voluntary
> organization.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2021 12:03:29 -0500

I don't think it is malice. I think it is more a reluctance to take actions
that may have unknown consequences.

And of course, anyone paying attention to what the Internet was designed to
do from the very start should realize that the consequences we worry about
at the protocol level are ridiculously trivial compared to the social
impact.

The Arab Spring was not an unforeseen consequence, or at least not in form.
I was talking to people setting up Web servers in Sarajevo during the siege
back in 1993.

Of course every major advance in human history has come in the wake of a
major change in communications technology: Guttenberg, paper from wood
pulp, telegraph, telephone, radio, television. But take a deeper look at
what happened and it might surprise you.

Guttenberg's press allowed information to flow freely, Aldud Maneutius
invented the codex book that would fit in a saddlebag. And now Thomas Moore
could read every book just like I once read every page on the Web. And
the man who knew everything still knew nothing because the vast majority of
the content of every book in print was nonsense.

It took 200 years to invent science and start to differentiate actual
knowledge from the nonsense. When are we going to do that for the Web?

Worrying that it might be premature to allocate a .Well-known port... seems
kinda trivial.

On Mon, Feb 8, 2021 at 11:47 AM denis bider <[email-masked]>
wrote:

>> Lots of people get really, really excited at the idea that they are
>> adding value by preventing work that might lead to vague, consequences that
>> they can't quite put their finger on.
>>

---

From: denis bider <[email-masked]>
Date: Mon, 8 Feb 2021 21:21:36 -0600

> It took 200 years to invent science and start to differentiate actual
knowledge from the nonsense.

The success of science so far to actually do that is greatly overestimated.
This is especially true for biology, psychology and medicine, and this
popular overestimate is extremely dangerous. It is now leading to tyranny
of wrong science.

> When are we going to do that for the Web?

Hopefully never, because everything "reputable" right now is MALICIOUSLY
wrong. One must consult "conspiracy theorists" to find kernels of truth,
since it is being wiped from everywhere else.

On Mon, Feb 8, 2021 at 11:03 AM Phillip Hallam-Baker <[email-masked]>
wrote:

> I don't think it is malice. I think it is more a reluctance to take
> actions that may have unknown consequences.
>
> And of course, anyone paying attention to what the Internet was designed
> to do from the very start should realize that the consequences we worry
> about at the protocol level are ridiculously trivial compared to the social
> impact.
>
> The Arab Spring was not an unforeseen consequence, or at least not in
> form. I was talking to people setting up Web servers in Sarajevo during the
> siege back in 1993.
>
> Worrying that it might be premature to allocate a .Well-known port...
> seems kinda trivial.
>
>
>
>> Reluctant volunteers will gladly step away in favor of those who have
>> more enthusiasm, and those who have more enthusiasm are the ones who would
>> On Sun, Feb 7, 2021 at 9:41 PM Phillip Hallam-Baker <
>> [email-masked]> wrote:
>>
>>> +1
>>>
>>> And then when people go through the process and end up waiting six
>>> months for those people to make up their minds, well we are a
>>> I have a rather different view. I think that when someone puts
>>> themselves in the way of someone else's critical path, they are making a
>>> commitment to deal with the issue expeditiously and if that isn't possible,
>>> the answer is to not make things critical path.
>>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Feb 2021 20:52:41 -0800

> reach the experts, then I'm not sure if it's an improvement. :)

If the experts are non-responsive, you should escalate to the IESG and hold
the IESG ultimately responsible for the presence of functional experts.

And if we are changing the registry procedures, we can make it so that
there's a designated place (list) to talk to the experts, which is done for
many TLS, OAuth, etc. registries already.

> body knew what to do with, it was only the fact that I sort-of volunteered to

FWIW, I think we're down to maybe 3 pages of gunk now.
https://datatracker.ietf.org/doc/draft-allan-5g-fmc-encapsulation/ is up
for approval this week and is only 8 pages, yet seems to contain a fair bit
of non-gunk.

> something interesting somewhere, wasn't accepted).

That's a shame!

-Ben