Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reclaiming is very hard #4275

Closed
larseggert opened this issue Oct 28, 2020 · 6 comments
Closed

Reclaiming is very hard #4275

larseggert opened this issue Oct 28, 2020 · 6 comments
Labels
-transport ietf-lc An issue that was raised during IETF Last Call.

Comments

@larseggert
Copy link
Member

22.1.1. Provisional Registrations

Provisional registration of codepoints are intended to allow for
private use and experimentation with extensions to QUIC. Provisional
registrations only require the inclusion of the codepoint value and
contact information. However, provisional registrations could be
reclaimed and reassigned for another purpose.

Experience in other WGs suggests that reclaiming is very hard. We really
needed to do this in MPLS where we had a 16 value field and found it impossible.

@larseggert larseggert added -transport ietf-lc An issue that was raised during IETF Last Call. labels Oct 28, 2020
@larseggert larseggert added this to the transport-genart milestone Oct 28, 2020
@larseggert larseggert added this to Triage in Late Stage Processing via automation Oct 28, 2020
@martinthomson
Copy link
Member

This is not an issue. I agree that it could be hard, but that doesn't mean that we shouldn't allow for the option. And we expect the need for reclamation to be low. I suggest that we close this with no action.

@StewartBryant
Copy link

Given that you do not think it is likely to be used, and given that in MPLS we tried this and found it to be very hard, why not remove the text?

@martinthomson
Copy link
Member

We have been successful in recovering the port number that this protocol uses. So we have a clear example of where reclamation was successful and useful.

That was made much harder due to a lack of an understanding about reclamation. Being clear up front should help avoid problems.

Proposing no action here.

@martinthomson martinthomson added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Nov 5, 2020
@project-bot project-bot bot moved this from Triage to Consensus Emerging in Late Stage Processing Nov 5, 2020
@StewartBryant
Copy link

StewartBryant commented Nov 6, 2020 via email

@janaiyengar
Copy link
Contributor

We have far more values, so in practice this should not be an issue. I agree that we don't want to close out the possibility of reclaiming.

@LPardue
Copy link
Member

LPardue commented Dec 8, 2020

The proposed resolution was to close to with action, which was signalled to the appropriate review channel.

Hearing no pushback, I'm closing this.

@LPardue LPardue closed this as completed Dec 8, 2020
Late Stage Processing automation moved this from Consensus Emerging to Issue Handled Dec 8, 2020
@LPardue LPardue removed the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Dec 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport ietf-lc An issue that was raised during IETF Last Call.
Projects
Late Stage Processing
  
Issue Handled
Development

No branches or pull requests

5 participants