Comment 1 for bug 1016321

Have requested a formal port from IANA for the public keystone port:

To whom it may concern:

This is an automatically generated message to notify you that we have
received your request, and it has been recorded in our ticketing
system with a reference number of 583461. To check the status
of your request, please see:

https://tools.iana.org/public-view

If you have any problems accessing this page, please contact
<email address hidden>.

There is no need to reply to this message right now. IANA staff will
review your message shortly.

If this message is in reply to a previously submitted ticket, it is
possible that the previous ticket has been marked as closed. As we
review this ticket, we will also review previous correspondence and
take appropriate action.

To expedite processing, and ensure our staff can view the full history
of this request, please make sure you include the follow exact text in
the subject line of all future correspondence on this issue:

        [IANA #583461]

You can also simply reply to this message, as this tag is already in
the subject line.

Thank you,

The Internet Assigned Numbers Authority
<email address hidden>

-------------------------------------------------------------------------

Application for a Port Number and/or Service Name

Assignee: Nebula <email address hidden>
Contact Person: Joe Heck <email address hidden>

Resource Request:

   [x] Port Number
   [x] Service Name

Transport Protocols:
   [x] TCP
   [ ] UDP
   [ ] SCTP
   [ ] DCCP

Service Code: []
Service Name: [openstack-id]
Desired Port Number: [8770]
Description: [public openstack identity api]

Reference:
[The keystone service (http://keystone.openstack.org/) provides a reference implementation of authentication and authorization services for OpenStack - infrastructure as a service software]

Defined TXT Keys:

1. If broadcast/multicast is used, how and what for?
[]

2. If UDP is requested, please explain how traffic is limited, and whether the
   protocol reacts to congestion.
[]

3. If UDP is requested, please indicate whether the service is solely
   for the discovery of hosts supporting this protocol.
[]

4. Please explain how your protocol supports versioning.
[The REST API is versioned within the URI using a standard versioning scheme across all OpenStack projects. ]

5. If your request is for more than one transport, please explain in
   detail how the protocol differs over each transport.
[Another openstack-id is also registered on port 35357, which is the administrative API port. The transports for public and administrative use are supported as defaulting to separate ports to allow for easier enforcement of security.]

6. Please describe how your protocol supports security. Note that presently
   there is no IETF consensus on when it is appropriate to use a second port
   for an insecure version of a protocol.
[If enabled, the protocol fully supports SSL encryption, and in future versions will support SSL server and client side authentication]

7. Please explain the state of development of your protocol.
[stable and in continued development - currently in V2, beginning implementation of V3]

8. If SCTP is requested, is there an existing TCP and/or UDP service name or
   port number assignment? If yes, provide the existing service name and port number.
[]

9. What specific SCTP capability is used by the application such that a
   user who has the choice of both TCP (and/or UDP) and SCTP ports for
   this application would choose SCTP? See RFC 4960 section 7.1.
[]

10. Please provide any other information that would be helpful in
   understanding how this protocol differs from existing assigned services.
[]