[Sat] Re: IANA considerations needed for -core and -architecture

[Thomas Hardjono <[e-mail]>]

Thanks Wes,

>>> 1. …  So the question is: what
>>> registries do you need to create now, and what existing values should go
>>> in them now?
Currently (2025) for satp-core we need a registry (or sub-registry) for the message-types used in SATP.  (In the future, for the other new work items we may need other sub-registries).


>>> 2. You'll need a separate part of the IANA considerations where
>>> you request the URN value you want assigned.

Here is my newbie attempt at the IANA Considerations text for satp-core, with the last part containing the URN value requested.

-------- <begin proposed text> --------

14.  IANA Considerations

14.1.  SATP Message Types Registry
This specification establishes the SATP Message Types registry. The purpose of this registry is to define the various message types utilized in the secure asset transfer protocol.

14.1.1.  Initial Registry Contents
The SATP Message Types registry's initial contents are as follows:

   o  Parameter name: transfer-proposal-msg
   o  Parameter usage location: Transfer Proposal
   o  Change controller: IETF
   o  Specification document(s):  Section 8.3 of draft-ietf-satp-core.

   o  Parameter name: proposal-receipt-msg
   o  Parameter usage location: Transfer Proposal Receipt Message
   o  Change controller: IETF
   o  Specification document(s): Section 8.4 of draft-ietf-satp-core.

   o  Parameter name: reject-msg
   o  Parameter usage location: Transfer Reject
   o  Change controller: IETF
   o  Specification document(s): Section 8.5 of draft-ietf-satp-core.

   o  Parameter name: transfer-commence-msg
   o  Parameter usage location: Transfer Commence
   o  Change controller: IETF
   o  Specification document(s): Section 8.6 of draft-ietf-satp-core.

   o  Parameter name: ack-commence-msg
   o  Parameter usage location: Transfer Commence Response
   o  Change controller: IETF
   o  Specification document(s): Section 8.7 of draft-ietf-satp-core.

   o  Parameter name: lock-assert-msg
   o  Parameter usage location: Lock Assertion
   o  Change controller: IETF
   o  Specification document(s): Section 9.1 of draft-ietf-satp-core.

   o  Parameter name: assertion-receipt-msg
   o  Parameter usage location: Lock Assertion Receipt
   o  Change controller: IETF
   o  Specification document(s): Section 9.2 of draft-ietf-satp-core.

   o  Parameter name: commit-prepare-msg
   o  Parameter usage location: Commit Preparation
   o  Change controller: IETF
   o  Specification document(s): Section 10.1 of draft-ietf-satp-core.

   o  Parameter name: commit-ready-msg
   o  Parameter usage location: Commit Ready
   o  Change controller: IETF
   o  Specification document(s): Section 10.2 of draft-ietf-satp-core.

   o  Parameter name: commit-final-msg
   o  Parameter usage location: Commit Final Assertion
   o  Change controller: IETF
   o  Specification document(s): Section 10.3 of draft-ietf-satp-core.

   o  Parameter name: ack-commit-final-msg
   o  Parameter usage location: Commit-Final Acknowledgement Receipt
   o  Change controller: IETF
   o  Specification document(s): Section 10.4 of draft-ietf-satp-core.

   o  Parameter name: commit-transfer-complete-msg
   o  Parameter usage location: Transfer Complete
   o  Change controller: IETF
   o  Specification document(s): Section 10.5 of draft-ietf-satp-core.

   o  Parameter name: error-msg
   o  Parameter usage location: Error message
   o  Change controller: IETF
   o  Specification document(s): Section 10.6 of draft-ietf-satp-core.

   o  Parameter name: session-abort-msg
   o  Parameter usage location: Session Abort
   o  Change controller: IETF
   o  Specification document(s): Section 10.7 of draft-ietf-satp-core.


14.2 URN Registration

URN:   To be assigned by IANA.
Common Name:    urn:ietf:satp
Registrant Contact: IESG
Description: The secure asset transfer protocol (SATP) requires message types, endpoints and parameters to be defined within a unique namespace to prevent collision.


-------- <end proposed text> --------










From: Wes Hardaker <[e-mail]>
Date: Thursday, July 31, 2025 at 13:38
To: Thomas Hardjono <[e-mail]>
Cc: Wes Hardaker <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Sat] IANA considerations needed for -core and -architecture
Thomas Hardjono <[e-mail]> writes:

> However, satp-core introduces several new message types. Also, we will need a URN that is
> unique to ietf-satp.
>
> Could the satp-core document tsay something like this sentence (in its IANA Considerations
> section):
>
>           “SATP MessageType registry: Future values are allocated via
>           Standards Action”

You likely need more than just that.

1. You'll need to define all the registries you want to create along
with the details of what they should look like (what values/columns to
use in the table).  RFC8126 should help here.  So the question is: what
registries do you need to create now, and what existing values should go
in them now?

2. You'll need a separate part of the IANA considerations where you
request the URN value you want assigned.

--
Wes Hardaker
USC/ISI