Provisional registration procedure

Provisional registration procedure

[Suresh Krishnan]

Hi all,
  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?
* Do Provisional registrations timeout after a while if they are not made Permanent?
* How do we remove Provisional registrations? Are the codepoints freed up?

I have opened an issue on the issue tracker for this at https://github.com/ietf-wg-bpf/ebpf-docs/issues/113 . Comments are welcome and greatly appreciated.

Thanks
Suresh

[Bpf] Provisional registration procedure

[Suresh Krishnan]

Hi all,
  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?
* Do Provisional registrations timeout after a while if they are not made Permanent?
* How do we remove Provisional registrations? Are the codepoints freed up?

I have opened an issue on the issue tracker for this at https://github.com/ietf-wg-bpf/ebpf-docs/issues/113 . Comments are welcome and greatly appreciated.

Thanks
Suresh
-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: Provisional registration procedure

[David Vernet]

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

On Tue, Apr 02, 2024 at 10:50:02PM -0400, Suresh Krishnan wrote:
> Hi all,

Hi Suresh,

Thanks for reading over the document.

> 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 xample, 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?

> * 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.

> * 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.

> 
> I have opened an issue on the issue tracker for this at
> https://github.com/ietf-wg-bpf/ebpf-docs/issues/113 . Comments are
> welcome and greatly appreciated.

Ack, thanks. Whatever we decide, we'll update the GitHub issue
accordingly.

Thanks,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Bpf] Provisional registration procedure

[David Vernet]

[-- Attachment #1.1: Type: text/plain, Size: 4271 bytes --]

On Tue, Apr 02, 2024 at 10:50:02PM -0400, Suresh Krishnan wrote:
> Hi all,

Hi Suresh,

Thanks for reading over the document.

> 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 xample, 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?

> * 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.

> * 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.

> 
> I have opened an issue on the issue tracker for this at
> https://github.com/ietf-wg-bpf/ebpf-docs/issues/113 . Comments are
> welcome and greatly appreciated.

Ack, thanks. Whatever we decide, we'll update the GitHub issue
accordingly.

Thanks,
David

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: [Bpf] Provisional registration procedure

[dthaler1968]

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
> xample, 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).

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.
 
> > * 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.
 
> > * 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.

Dave

Re: [Bpf] Provisional registration procedure

[dthaler1968=40googlemail.com]

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
> xample, 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).

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.
 
> > * 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.
 
> > * 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.

Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] Provisional registration procedure

[David Vernet]

[-- 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 --]

Re: [Bpf] Provisional registration procedure

[David Vernet]

[-- Attachment #1.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf