On Wed, Apr 03, 2024 at 12:13:21PM -0700, dthaler1968@xxxxxxxxxxxxxx wrote: > David Vernet wrote: > > On Tue, Apr 02, 2024 at 10:50:02PM -0400, Suresh Krishnan wrote: > > > At the recently concluded IETF119 bpf WG meeting, I had asked a > > > question to Dave about the Provisional registrations for BPF > > > instruction conformance groups. Section 5.1 of draft-ietf-bpf-isa-01 > > > talks about Provisional registrations, but does not elaborate further. > > > Specifically, I think it would be good to cover the following cases > > > > > > * Do we allow conversions from Provisional to Permanent? If so how? > > > > Would you mind please pointing to examples of other RFCs we can look > > at to see how this is typically specified? My assumption was that we > > would just initiate a standards action or IESG review to change the > > state from Provisional to Permanent (meaning, that it was sufficient > > to simply define the registration policies for Permanent and > > Provisional), but it sounds like we need to be more explicit in our > > language. It seems that RFC8126 section 4.13 doesn't specify a > > standard method for converting between states: > > > > 4.13. Provisional Registrations > > > > Some existing registries have policies that allow provisional > > registration: see URI Schemes [RFC7595] and Email Header Fields > > [RFC3864]. Registrations that are designated as provisional are > > usually defined as being more readily created, changed, reassigned, > > moved to another status, or removed entirely. URI Schemes, for > > example, allow provisional registrations to be made with incomplete > > information. > > > > Allowing provisional registration ensures that the primary goal of > > maintaining a registry -- avoiding collisions between incompatible > > semantics -- is achieved without the side effect of "endorsing" the > > protocol mechanism the provisional value is used for. Provisional > > registrations for codepoints that are ultimately standardized can be > > promoted to permanent status. The criteria that are defined for > > converting a provisional registration to permanent will likely be > > more strict than those that allowed the provisional registration. > > > > If your registry does not have a practical limit on codepoints, > > perhaps adding the option for provisional registrations might be > > right for that registry as well. > > > > Hmm, and looking at RFC 7595 [0] section 7.3 Change Control as a possible > > example, it specifies the following: > > > > 7.3. Change Control > > > > Registrations can be updated in the registry by the same mechanism as > > required for an initial registration. In cases where the original > > definition of the scheme is contained in an IESG-approved document, > > update of the specification also requires IESG approval. > > > > 'Provisional' registrations can be updated by the original registrant > > or anyone designated by the original registrant. In addition, the > > IESG can reassign responsibility for a 'provisional' registration > > scheme or can request specific changes to a scheme registration. > > This will enable changes to be made to schemes where the original > > registrant is out of contact or unwilling or unable to make changes. > > > > Transition from 'provisional' to 'permanent' status can be requested > > and approved in the same manner as a new 'permanent' registration. > > Transition from 'permanent' to 'historical' status requires IESG > > approval. Transition from 'provisional' to 'historical' can be > > requested by anyone authorized to update the 'provisional' > > registration. > > > > [0]: https://www.rfc-editor.org/rfc/rfc7595#page-9 > > > > Dave, what do you think? I guess we should add a paragraph(s) > > explaining the processes for this state machine? > > The ISA document says Permanent requires "Standards action or IESG > Review" (the latter is a typo, should say "IESG Approval" to match RFC > 8126 section 4.10 terminology). Ack > So converting to Permanent from nothing, or converting to Permanent from > Provisional is currently the same... Standards action or IESG Review. > > Yes I can copy language from RFC 7595 (which I was also the editor of) > to make it explicit. Sounds good, thanks. > > > * Do Provisional registrations timeout after a while if they are not > > > made Permanent? > > > > Dave? I'm not sure if this has been discussed or what the norm would be. > > It's up to us, there examples that time out, and examples that don't. > (URI schemes being an example that don't.) There is no requirement > in RFC 8126 to have any discussion of timeout. The lack of such > discussion at in the document at present means that there is currently > no timeout, i.e., like provisional URI schemes. If we did want a > timeout, we'd have to add language to say that. > > Documents that are labeled as "experimental" are supposed to discuss > timeouts, but things that are "provisional" generally do not. > > My current recommendation is to not have a timeout, but I don't feel > strongly either way. I agree > > > * How do we remove Provisional registrations? Are the codepoints freed > up? > > > > Also not sure if this has been discussed or what the norm should be. > > Absent language saying otherwise, currently you can convert a > Provisional registration to Historical via the process for Historical. > In the ISA spec this is currently "Specification required". In the > RFC 7595 example, this is instead stated otherwise: > > "Transition from 'provisional' to 'historical' can be requested by > anyone authorized to update the 'provisional' registration." > > Here I would definitely recommend copying the RFC 7595 precedent, which > makes more sense process wise. Makes sense and sounds good to me as well. Thanks, David
Attachment:
signature.asc
Description: PGP signature
