On Mon, Aug 29, 2011 at 7:57 PM, Zane Bitter <zbitter(a)redhat.com> wrote:
Questions for the list...
On 27/08/11 00:56, Pearl Liang via RT wrote:
> 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...
> Also, there exist protocols to manage device configuration, such as
> NETCONF[1]. Have you considered making use of it?
>
> [1] RFC
6241<http://tools.ietf.org/html/rfc6241>
Does somebody who was involved earlier in the project have any comment
on this?
None of their damn business.
Seriously, they want to retroactively rewrite our design constraints? Bah.
(iana response)
We designed for an QMF/AMQP bus because it was already available,
usable and fulfilled all our design requirements.
Whatever merits, if any, RCF 6241 may have over QMF/AMQP, at the time
there was no such implementation for us to use.
We note also that 6241 itself was also only finalised in June this
year, far too late to influence the current Matahari implementation.
Research revealed one implementation[1] of NETCONF[2] but it is still
very immature - their first release was only Jan 2010.
By contrast, Qpid (the QMF/AMQP implementation we're using) has
shipped for a number of years in multiple versions of at least one
enterprise distro.
[1]
https://yuma.svn.sourceforge.net/svnroot/yuma/branches/v1/debian/changelog
[2] Its unclear whether it is of the older or more recent RFC.