Thank you. Please see below comment and questions:
------
A couple of clarifications may help here:
1) The purpose of matahari is not to configure QMF/Qpid, but to
configure the entire system. For example, starting and stopping
network
interfaces, services, virtual machines or entire boxes.
2) QMF does not run atop matahari. Matahari runs atop QMF, which
itself
runs atop Apache Qpid (which is the AMQP implementation).
The reason for a separate port is that end users may want to run a
vanilla AMQP service on their hosts which is logically separate from
the
matahari AMQP bus. We cannot force generic users of AMQP to have their
services coexist with ours (for instance, they may require a different
implementation of AMQP), so we request a separate port so that our
specific usage of AMQP can remain logically separate.
Thanks for the clarification. My question; how often should IANA expect
such requests? Is a discovery mechanism in order in the baseline AMQP
protocol? If someone else comes out with some other function that runs
atop AMQP but needs a different implementation, are we going to see
another request?
Also, there exist protocols to manage device configuration, such as
NETCONF[1]. Have you considered making use of it?
[1] RFC 6241 <
---
If we do not receive the information from you within 30 days, your request
will be closed without prejudice, as a matter of administrative procedure.
Thank you,
Pearl Liang
IANA
On Fri Aug 26 07:02:05 2011, zbitter(a)redhat.com wrote:
On 25/08/11 22:58, Pearl Liang via RT wrote:
> The Port Experts Team has review your application (included below).
> The team has the following questions with respect to your request:
>
> -----
>
> I'd like to summarize what I understand of the application, and then
ask
> a question or two:
>
> This application is for an additional TCP port 49000 for a service
> called "matahari", to be used for configuration management of
QMF/QPid
> implementations. Justification for this port assignment seems to be
> that privileged communications must be separated from normal
operations,
> and that QMF will run atop Matahari. Given this, aren't we really
> talking about a newer version of AMQP? Could not the AMQP version be
> bumped? We seek more information as to why precisely different ports
> should be used.
A couple of clarifications may help here:
1) The purpose of matahari is not to configure QMF/Qpid, but to
configure the entire system. For example, starting and stopping
network
interfaces, services, virtual machines or entire boxes.
2) QMF does not run atop matahari. Matahari runs atop QMF, which
itself
runs atop Apache Qpid (which is the AMQP implementation).
The reason for a separate port is that end users may want to run a
vanilla AMQP service on their hosts which is logically separate from
the
matahari AMQP bus. We cannot force generic users of AMQP to have their
services coexist with ours (for instance, they may require a different
implementation of AMQP), so we request a separate port so that our
specific usage of AMQP can remain logically separate.
> Also, there is an inconsistency in the application:
>
> The applicant has stated that multicast may be used, and yet the
> application is only for TCP. This is generally inadvisable and
> impracticable, given the state machine that TCP uses.
Yes, the information in the multicast section is erroneous - please
disregard it. There is no multicast or broadcast used on the matahari
port.
thanks,
Zane.
> -----
>
> Please resolve the above questions. If we do not receive the
information
> from you within 30 days, your request will be closed without
prejudice, as
> a matter of administrative procedure.
>
> Thank you,
>
> Pearl Liang
> IANA
>
>
>
> On Wed Aug 24 09:22:44 2011, zbitter(a)redhat.com wrote:
>> On 24/08/11 18:04, Pearl Liang via RT wrote:
>>> Thank you for the reply.
>>>
>>>> Assignee Name (REQUIRED): Matahari Project
>>>> Assignee E-mail (REQUIRED): matahari(a)lists.fedorahosted.org
>>>
>>> Please confirm if
http://matahariproject.org/ is the
organization's
>>> website.
>>
>> Yes, that is correct.
>>
>>> On Wed Aug 24 06:07:57 2011, zbitter(a)redhat.com wrote:
>>>> Assignee Name (REQUIRED): Matahari Project
>>>> Assignee E-mail (REQUIRED): matahari(a)lists.fedorahosted.org
>>>> (The Assignee is the organization, company or individual person
>>>> responsible
>>>> for the initial assignment. )
>>>> Contact Name (REQUIRED): Zane Bitter
>>>> Contact E-mail (REQUIRED): zbitter(a)redhat.com
>>>>
>>>> Transport Protocol(s) (REQUIRED): (Please indicate which
protocols
>> are
>>>> currently required.)
>>>> [ X ] TCP [ ] UDP [ ] SCTP [ ] DCCP
>>>>
>>>> Service Code (REQUIRED for DCCP only)
>>>>
>>>> A: ____________________________
>>>>
>>>> Service Name (REQUIRED, 15 character maximum):
>>>>
>>>> A: matahari
>>>>
>>>> Desired Port Number (OPTIONAL, for Port Number only)
>>>>
>>>> A: 49000
>>>> NOTE: It is *inappropriate* to use a port number until your
>>>> application has
>>>> been approved for assignment. Leave it blank if no number
>> preference.
>>>>
>>>> Description (REQUIRED) (For example: Super User Messaging)
>>>>
>>>> A: Matahari Broker
>>>>
>>>> Reference (REQUIRED): Please provide a brief and basic technical
>>>> description
>>>> of the protocol that will use the service name or port number,
>>>> including
>>>> message
>>>> formats, types, sequences, functionalities, of your protocol.
In
>>>> addition,
>>>> please address the specific questions included below to the
extent
>>>> possible.
>>>>
>>>> A: The Matahari server is an implementation of an Advanced
Message
>>>> Queuing Protocol (AMQP) broker. Matahari uses a subset of the
Qpid
>>>> Management Framework (QMF), which sits on top of AMQP (Apache
Qpid
>> is
>>>> an
>>>> implementation of AMQP). AMQP is an open standard which is
>> documented
>>>> here:
>>>>
http://www.amqp.org/confluence/download/attachments/720900/amqp.0-
>>>> 10.pdf
>>>>
>>>> In short, AMQP is a generic protocol for handling message queues.
>>>> Client
>>>> applications can create and subscribe to queues and publish
>> messages
>>>> to
>>>> them.
>>>>
>>>> Matahari (
http://www.matahariproject.org/) is a service to
provide
>>>> remote access to system management APIs over QMF. Existing APIs
>>>> support
>>>> system configuration and querying of system parameters for
virtual
>>>> servers, however the protocol is extensible so users can add
their
>> own
>>>> custom APIs.
>>>>
>>>> Q: If broadcast/multicast is used, how and what for?
>>>>
>>>> A: Multicast may optionally be used to efficiently combine
multiple
>>>> brokers into a high-availability cluster.
>>>>
>>>> Q: If UDP is requested, please explain how traffic is limited,
and
>>>> whether the protocol reacts to congestion.
>>>>
>>>> A:
>>>>
>>
___________________________________________________________________________
>>>>
>>>> Q: If UDP is requested, please indicate whether the service is
>> solely
>>>> for the discovery of hosts supporting this protocol.
>>>>
>>>> A:
>>>>
>>
___________________________________________________________________________
>>>>
>>>> Q: Please explain how your protocol supports versioning.
>>>>
>>>> A: All AMQP messages begin with a version field, and AMQP defines
a
>>>> method for the client and server to negotiate a mutually
compatible
>>>> protocol version. QMF objects have a schema which can be queried
>> over
>>>> the protocol.
>>>>
>>>> Q: If your request is for more than one transport, please explain
>> in
>>>> detail how the protocol differs over each transport.
>>>>
>>>> A:
>>>>
>>
__________________________________________________________________________
>>>>
>>>> Q: Please describe how your protocol supports security. Please
note
>>>> that
>>>> there is current debate as to whether additional future ports
will
>> be
>>>> allocated for newly assigned services that lack security, e.g.,
>> solely
>>>> for the addition of a secure variant. Applicants are strongly
>> advised
>>>> to
>>>> address this issue as early as possible in the design of their
>>>> protocols.
>>>>
>>>>
>>>> A: The protocol may optionally be tunnelled over SSL.
>>>>
>>>>
>>>> Q: Please explain the state of development of your protocol.
>>>>
>>>> A: AMQP is a published open standard with four published versions
>>>> since
>>>> 2006 and multiple available implementations. QMF has undergone a
>> major
>>>> revision and is now considered stable.
>>>>
>>>> Q: If SCTP is requested, please describe the following: Is there
an
>>>> existing TCP and/or UDP service name or port number assignment?
>>>> If so, please indicate the details below:
>>>>
>>>> Service Name: _______________; Port number: _______________
>>>>
>>>> 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 [RFC4960 section 7.1]
>>>> (
http://tools.ietf.org/html/rfc4960#section-7.1)
>>>>
>>>> A:
>>>>
>>
_____________________________________________________________________________
>>>>
>>>>
>>
________________________________________________________________________________
>>>>
>>>>
>>>> Please provide any other information that would be helpful in
>>>> understanding how this protocol differs from existing assigned
>>>> services.
>>>>
>>>> A: Matahari differs from a generic AMQP broker in that it
requires
>> the
>>>> QMF protocol running on top, so only the Apache Qpid
implementation
>> of
>>>> AMQP can be used. Since Matahari is designed for system
>> configuration,
>>>> for security reasons it places a tighter than usual set of
>>>> restrictions
>>>> on how the connection can be used, and thus must be segregated
from
>>>> regular applications' AMQP traffic.
>>>>
>>>
>>
>> On Wed Aug 24 06:07:57 2011, zbitter(a)redhat.com wrote:
>> Application for User Registered Port Number
>>
>> Name :
>> Zane Bitter
>>
>> E-mail :
>> zbitter(a)redhat.com
>>
>> Protocol Number :
>> TCP
>>
>> Message Formats :
>> Protocol version, type, channel, size, payload
>>
>> Message Types :
>> Method, Header, Body, Heartbeat
>>
>> Message opcodes :
>> Channel: Open, Open-Ok, Close, Close-Ok
>> Exchange: Declare, Delete
>> Queue: Declare, Declare-Ok, Bind, Bind-Ok
>> Basic: Publish, Consume, Cancel, Deliver, Return, Ack, Reject, Get
>> Transaction: Select, Publish, Ack, Commit, Roll-back
>>
>> Message Sequences :
>> See:
https://www.amqp.org/confluence/download/attachments/720900/amqp0-9-
1.pdf
>>
>> Protocol functions :
>> Queuing and routing of messages for applications.
>>
>> Broadcast or Multicast used ?
>> yes
>>
>> How and what for Broadcast and Multicast is used (if used):
>> Multicast may optionally be used to efficiently combine multiple
brokers into a high-availability cluster.
>>
>> Description :
>> Matahari (
http://www.matahariproject.org/) is a service to provide
remote access to system management APIs. Existing APIs
>> support system configuration and querying of system parameters for
virtual servers, however the protocol is extensible so users
>> can add their own custom APIs.
>>
>> The server is an implementation of an Advanced Message Queuing
Protocol (AMQP) broker. AMQP is an existing open standard
>> (
http://www.ampq.org/). On a Matahari server, communication occurs
through the Qpid Management Framework which sits on
>> top of AMQP. (Apache Qpid is an implementation of AMQP.)
>>
>> Name of the port :
>> Matahari Broker
>>
>> Short name of the port :
>> matahari
>>