Re: [Bpf] Provisional registration procedure

[David Vernet <void@manifault.com>]

[-- Attachment #1: Type: text/plain, Size: 6051 bytes --]

On Wed, Apr 03, 2024 at 12:13:21PM -0700, dthaler1968@googlemail.com 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]