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?
It's a valid question, but I don't know how we can speak for everybody
else in the world.
IPP is just layered on top of HTTP, yet it has a Well-Known(!) Port
(631) assigned. Shouldn't it just use port 80? Apache supports virtual
servers, after all...
Does somebody who was involved earlier in the project have any comment
on this?
---
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
>>>
>