|
»
« Return to Thread: SPDY / NPN
Re: SPDY / NPN
by Nico Williams
::
Rate this Message:
On Thu, Apr 19, 2012 at 6:27 AM, Marsh Ray <marsh@...> wrote:
> It reads to me like they were trying to do the right thing and the IETF/IANA
> process failed them.
Not IANA. The IETF failed them.
> We had this problem with the RI extension too. As a practical matter,
> developers needed to start interop testing long before the ID was in last
> call status.
This has happened quite a bit in other areas too (e.g., the IKEv2
NAT-T extensions, IIIRC).
Part of the problem is that during development the protocol is still
fluid and you don't want code to get deployed that later fails to
interop when the final protocol ends up differing from an earlier
version.
For non-scarce namespaces the solution is to just make allocations
liberally. And for scarce ones? I think we could use a standard
policy that requires, say, just WG chair and AD approval -- something
less that IESG Approval, more than FCFS, something akin to Expert
Review but requiring wider consensus yet being light-weight. The
problem is that we can't require WG consensus or WG chair approval for
allocations because WGs are not stable -- we'd need a method for
updating which WG's chairs (if any applicable WG remains) need to
approve. Ditto ADs, as it's possible to have the IESG re-organized.
But IESG Approval is a bit heavy-duty, I think (maybe I'm wrong about
that).
> Withholding numbers doesn't actually seem to dissuade anyone from developing
> extensions. It simply results in numbers being de facto allocated in an
> uncoordinated fashion:
Bingo. But I don't think this is just a matter of the IETF being too
conservative in selecting allocation policies for registries. That's
only part of it. The other part is that we need an allocation policy
that is lightweight yet faster/simpler than Expert Review and also
requiring approval by an authority that can confirm the existence of
consensus for the allocation. The bodies that would provide that
confirmation are ephemeral.
Nico
--
_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls
> It reads to me like they were trying to do the right thing and the IETF/IANA
> process failed them.
Not IANA. The IETF failed them.
> We had this problem with the RI extension too. As a practical matter,
> developers needed to start interop testing long before the ID was in last
> call status.
This has happened quite a bit in other areas too (e.g., the IKEv2
NAT-T extensions, IIIRC).
Part of the problem is that during development the protocol is still
fluid and you don't want code to get deployed that later fails to
interop when the final protocol ends up differing from an earlier
version.
For non-scarce namespaces the solution is to just make allocations
liberally. And for scarce ones? I think we could use a standard
policy that requires, say, just WG chair and AD approval -- something
less that IESG Approval, more than FCFS, something akin to Expert
Review but requiring wider consensus yet being light-weight. The
problem is that we can't require WG consensus or WG chair approval for
allocations because WGs are not stable -- we'd need a method for
updating which WG's chairs (if any applicable WG remains) need to
approve. Ditto ADs, as it's possible to have the IESG re-organized.
But IESG Approval is a bit heavy-duty, I think (maybe I'm wrong about
that).
> Withholding numbers doesn't actually seem to dissuade anyone from developing
> extensions. It simply results in numbers being de facto allocated in an
> uncoordinated fashion:
Bingo. But I don't think this is just a matter of the IETF being too
conservative in selecting allocation policies for registries. That's
only part of it. The other part is that we need an allocation policy
that is lightweight yet faster/simpler than Expert Review and also
requiring approval by an authority that can confirm the existence of
consensus for the allocation. The bodies that would provide that
confirmation are ephemeral.
Nico
--
_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls
« Return to Thread: SPDY / NPN
| Free embeddable forum powered by Nabble | Forum Help |
