Name Service
Ilya Dmitrichenko
According to what Martin told me a few days ago after his talk at Skills Matter,
the is currently an open subject.
To start with, it's probably a good idea to look into the list of DNS
record types [1],
there exists SRV type which seems to be something that we could use [2, 3].
[1]: http://en.wikipedia.org/wiki/List_of_DNS_record_types
[2]: http://en.wikipedia.org/wiki/SRV_record
[3]: http://tools.ietf.org/html/rfc2782
The major shortcoming of DNS is that there had never been real-time guarantee,
however I suppose that if a dedicated nameserver would be in deployment this
won't be a problem. I.e. propagation delays are due to global scaling of DNS
and are not an issue in the local domains, I may be the case however that some
closely-coupled (optimised) implementation (or modification) would need to be
in place for some specific scenarios.
Nevertheless, other obvious alternatives would be LDAP [4] and NIS [5]. To my
knowledge NIS is still in wide use, though it seems to have a number of issues,
and LDAP is somewhat superior. I am not an expert of either of these, however
I suppose that both have nearly equal rights and probability of deployment at
any given organisation.
[4]: http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
[5]: http://tools.ietf.org/html/rfc4510
[6]: http://en.wikipedia.org/wiki/Network_Information_Service
I don't see a great need of argument over this subject really and I'd suggest,
if I may, that generic approach should be taken in the RFC draft. Suppose
DNS SRV recodrs with possible use of mDSN (aka zeroconf) can be set as
a kind of default. AND on the API level, it's probably best to provide a
possibility to define a custom methods for name resolution with examples of
handling LDAP and YP queries. Also it would be a good idea to propose
a certain common format, which we shall define.
Kind Regards,
--
Ilya
Paul Colomiets
On Sun, Sep 25, 2011 at 2:37 AM, Ilya Dmitrichenko
<errorde...@gmail.com> wrote:
> Nevertheless, other obvious alternatives would be LDAP [4] and NIS [5]. To my
> knowledge NIS is still in wide use, though it seems to have a number of issues,
> and LDAP is somewhat superior. I am not an expert of either of these, however
> I suppose that both have nearly equal rights and probability of deployment at
> any given organisation.
>
Another obvious alternative is build name service on top of SP.
Pros:
1. We can leverage SP's abilities to load balancing, forwarding, different
underlying protocols, etc.
2. Easy to write service which translates requests to DNS, LDAP or whatever
(I also expect that LDAP tools whould be different for each
installation, because
of huge flexibility of how LDAP works)
3. Standalone service (which translates to LDAP or whatever) is both more easy
to integrate with the network and more easy to change, if you have a network
with services written in different languages.
4. Codebase of the SP libary is smaller (no need for DNS, etc.)
5. Some kind of hot update (e.g. by using pub/sub) may be invented to
propagate name record changes
Cons:
1. Another big part of spec
2. For small applications it's problem to run one additional service (but it
doesn't mean name service is required or can't be embedded)
3. May not integrate well with existing infrastructure
4. Better suited for local installations than for wide network with different
providers (same can be said for LDAP and NIS, I think)
--
Paul
Ilya Dmitrichenko
>
> Another obvious alternative is build name service on top of SP.
Certainly a good alternative.
So you mean a req/rep proxy for dns/ldap/other ?
Ok, so it would go as "SPNS is a front-end protocol intended to abstract various
back-end implementation scenarios, whether an organization A wishes to use
NIS+, organization B - LDAP and there exist a few more orginizations which
have published DNS SRV records and are participating on casual basis."
Then we shall include a DNS-to-SPNS reference implementation which takes
care of DNSsec also (I find it quite reasonable to include DNSsec).
Apart from the things mentioned already, one may wish to deploy a DB at the
back-end for whatever reason it's a perfectly valid approach.
Also, I suppose there may be some cases where a developer will not be able
to push their updates into DNS or anything and will utilise HTTP-based API,
suppose they have some really-really-really fast-changing thing and all they
have is the web application, so they would be translating that to SPNS within
their infrastructure (where they are free to do anything).
Hece, all the spec should care about is a simple abstract model with an example
of usage in combination with a traditional approach, such as DNS.
In terms of the API, the idea would that one could just point the application at
example.org and by default it would try to get the SP SRV record and find what
is the IP of their front-end server. It should be specified in the DNS
records whether
that server is an SPNS, otherwise there would be SRV records for everything that
example.org has for public to see. If an organization chosen to use it
with IPsec,
they will most likely approach it in their own way and will issue
instruction to those
who need to integrate with their service. Well, there will need to a
be an RFC for
SP+IPsec at some later point anyway as well as SP+SASL/SSL/etc.
>
> Pros:
>
> 1. We can leverage SP's abilities to load balancing, forwarding, different
> underlying protocols, etc.
> 2. Easy to write service which translates requests to DNS, LDAP or whatever
> (I also expect that LDAP tools whould be different for each
> installation, because
> of huge flexibility of how LDAP works)
> 3. Standalone service (which translates to LDAP or whatever) is both more easy
> to integrate with the network and more easy to change, if you have a network
> with services written in different languages.
> 4. Codebase of the SP libary is smaller (no need for DNS, etc.)
> 5. Some kind of hot update (e.g. by using pub/sub) may be invented to
> propagate name record changes
>
> Cons:
>
> 1. Another big part of spec
Yeah, care has to be taken to make it as compact as possible.
> 2. For small applications it's problem to run one additional service (but it
> doesn't mean name service is required or can't be embedded)
> 3. May not integrate well with existing infrastructure
> 4. Better suited for local installations than for wide network with different
> providers (same can be said for LDAP and NIS, I think)
>
> --
> Paul
>
> --
> Note Well: This discussion group is meant to become an IETF working group in the future. Thus, the posts to this discussion should comply with IETF contribution policy as explained here: http://www.ietf.org/about/note-well.html
>
Martin Sustrik
> The major shortcoming of DNS is that there had never been real-time guarantee,
> however I suppose that if a dedicated nameserver would be in deployment this
> won't be a problem. I.e. propagation delays are due to global scaling of DNS
> and are not an issue in the local domains, I may be the case however that some
> closely-coupled (optimised) implementation (or modification) would need to be
> in place for some specific scenarios.
The most important point here IMO is that name resolving happens only
when new link within a topology is established. The idea is that once
established, each link can transport unlimited number of messages
(unlike HTTP where connections and messages are in 1:1 ratio).
Thus the DNS delays will be experienced only during the topology
establishment/change but never when actually passing the messages.
> Nevertheless, other obvious alternatives would be LDAP [4] and NIS [5]. To my
> knowledge NIS is still in wide use, though it seems to have a number of issues,
> and LDAP is somewhat superior. I am not an expert of either of these, however
> I suppose that both have nearly equal rights and probability of deployment at
> any given organisation.
I am not an expert on LDAP either, however, my understanding is that
LDAP directory is basically constrained to a single enterprise. When
crossing the enterprise boundaries, it falls back to DNS by resolving
the name of the LDAP server. (Please, correct me if I'm wrong.)
If the above is true, it looks like an unnecessary additional layer of
indirection on top of DNS.
No experience with NIS here.
> I don't see a great need of argument over this subject really and I'd suggest,
> if I may, that generic approach should be taken in the RFC draft. Suppose
> DNS SRV recodrs with possible use of mDSN (aka zeroconf) can be set as
> a kind of default. AND on the API level, it's probably best to provide a
> possibility to define a custom methods for name resolution with examples of
> handling LDAP and YP queries. Also it would be a good idea to propose
> a certain common format, which we shall define.
What we should think of in the first place IMO is what kind of queries
we want/need to support. Let me give an example:
Imaging there a global feed, say "quotes.reuters.com". When you resolve
the name, you get an address of a server in Reuters, you connect to it
and receive the messages.
However, let's imagine someone in a middle (such as your company admin
or an ISP) wants to cut the bandwidth usage by placing a device in the
middle (one connection from Reuters to the device, many connections to
the device from within the company).
He should be able to redefine the records in the name service in such a
way that all local users resolve "quotes" to the address of the proxy
device rather than to the address of the Reuters server.
This is just a single use case though. A lot of experimentation is
needed to get an clear idea of all the use cases.
Martin
Martin Sustrik
> Another obvious alternative is build name service on top of SP.
> Cons:
The largest cons IMO is that DNS is actually deployed while the potental
SP name service is not.
This may not matter much if you think of a local network, fully
controlled and administered by you.
However, once you think of cross-domain messaging you would face the
need to deploy a single consistent version on the SP name service on
global scale.
Which is a very hard thing to do and very likely to fail and/or lack any
significant level of adoption.
Martin
Martin Sustrik
> On 25 September 2011 11:42, Paul Colomiets<pa...@colomiets.name> wrote:
>> Another obvious alternative is build name service on top of SP.
>
> Certainly a good alternative.
>
> So you mean a req/rep proxy for dns/ldap/other ?
>
> Ok, so it would go as "SPNS is a front-end protocol intended to abstract various
> back-end implementation scenarios, whether an organization A wishes to use
> NIS+, organization B - LDAP and there exist a few more orginizations which
> have published DNS SRV records and are participating on casual basis."
Bevare of the vicious circle here: SP needs SPNS. SPNS is basically an
SP topology and thus is needs SPNS to work. Etc.
> Then we shall include a DNS-to-SPNS reference implementation which takes
> care of DNSsec also (I find it quite reasonable to include DNSsec).
+1 wrt DNSsec
> Apart from the things mentioned already, one may wish to deploy a DB at the
> back-end for whatever reason it's a perfectly valid approach.
> Also, I suppose there may be some cases where a developer will not be able
> to push their updates into DNS or anything and will utilise HTTP-based API,
> suppose they have some really-really-really fast-changing thing and all they
> have is the web application, so they would be translating that to SPNS within
> their infrastructure (where they are free to do anything).
>
> Hece, all the spec should care about is a simple abstract model with an example
> of usage in combination with a traditional approach, such as DNS.
Yes. The question is whether it falls into the scope of SP working group
or whether it's just an implementation issue or an API issue. IETF is
not too happy about working on something that is not an protocol.
> In terms of the API, the idea would that one could just point the application at
> example.org and by default it would try to get the SP SRV record and find what
> is the IP of their front-end server. It should be specified in the DNS
> records whether
> that server is an SPNS, otherwise there would be SRV records for everything that
> example.org has for public to see. If an organization chosen to use it
> with IPsec,
> they will most likely approach it in their own way and will issue
> instruction to those
> who need to integrate with their service. Well, there will need to a
> be an RFC for
> SP+IPsec at some later point anyway as well as SP+SASL/SSL/etc.
Martin
Paul Colomiets
> On 09/25/2011 01:42 PM, Paul Colomiets wrote:
>
>> Another obvious alternative is build name service on top of SP.
>
>> Cons:
>
> The largest cons IMO is that DNS is actually deployed while the potental SP
> name service is not.
>
Don't get the point. SP is not deployed either. There is no need to resolve
a name of some service that does not exists at all.
> This may not matter much if you think of a local network, fully controlled
> and administered by you.
>
> However, once you think of cross-domain messaging you would face the need to
> deploy a single consistent version on the SP name service on global scale.
>
> Which is a very hard thing to do and very likely to fail and/or lack any
> significant level of adoption.
>
So do you mean there more implementations ready and well-tested?
Latter makes much more sense, but don't sure it's critical. If we care
about current level of adoption, we choose existing protocol. I think we
should focus on doing it in the right way.
I'm also not sure SRV records serve our purposes well (which should
be discussed separately). And inveting another kind of record for DNS
is not much easier than inventing name resoving protocol.
Also there is no much deployment of DNSsec. Which I think should be
required for SP instead of plain DNS, because latter is too insecure.
BTW, all those network reimplementers like OpenFlow, RINA,.... do I
understand correctly that they have name service built into a lower
level?
--
Paul
Martin Sustrik
>> The largest cons IMO is that DNS is actually deployed while the potental SP
>> name service is not.
>>
>
> Don't get the point. SP is not deployed either. There is no need to resolve
> a name of some service that does not exists at all.
Imagine the first service to be deployed.
To access it from the Internet you would have to resolve its name. To do
so you would have to use SP name service. To do that you would need to
open appropriate ports in the firewall, you need your company or ISP
admin to install the name server etc.
With DNS, all this deployment/administration stuff is already done.
(Of cource you can connect to service provider's name server and use
that, however, it means that you basically fall back to the DNS when
resolving the name of the providers service.)
> So do you mean there more implementations ready and well-tested?
> Latter makes much more sense, but don't sure it's critical. If we care
> about current level of adoption, we choose existing protocol. I think we
> should focus on doing it in the right way.
No. It's about deployment as described above.
> I'm also not sure SRV records serve our purposes well (which should
> be discussed separately).
Yes. I have no expertise here. What's the problem with SRV records in
your opinion?
> And inveting another kind of record for DNS
> is not much easier than inventing name resoving protocol.
It isn't, but again, the deployment argument above applies.
> Also there is no much deployment of DNSsec. Which I think should be
> required for SP instead of plain DNS, because latter is too insecure.
Any way to allow both?
> BTW, all those network reimplementers like OpenFlow, RINA,.... do I
> understand correctly that they have name service built into a lower
> level?
OpenFlow is about controlling your local switch, there's no need for a
name service.
RINA, AFAIU is more of an conceptual framework for building network
architectures.
Martin
Martin Sustrik
> To access it from the Internet you would have to resolve its name. To do
> so you would have to use SP name service. To do that you would need to
> open appropriate ports in the firewall, you need your company or ISP
> admin to install the name server etc.
To be totally explicit: You'll also need the name service at your ISP to
know about other name services, you'll need a way to resolve unknown
names by delegating the query, you'll need root name servers running
somewhere in 24/7 mode and transparent fialover etc.
Martin
Paul Colomiets
On Sat, Oct 1, 2011 at 10:33 AM, Martin Sustrik <sus...@250bpm.com> wrote:
> Hi Paul,
>
>>> The largest cons IMO is that DNS is actually deployed while the potental
>>> SP
>>> name service is not.
>>>
>>
>> Don't get the point. SP is not deployed either. There is no need to
>> resolve
>> a name of some service that does not exists at all.
>
> Imagine the first service to be deployed.
>
> To access it from the Internet you would have to resolve its name. To do so
> you would have to use SP name service. To do that you would need to open
> appropriate ports in the firewall, you need your company or ISP admin to
> install the name server etc.
>
> With DNS, all this deployment/administration stuff is already done.
>
> (Of cource you can connect to service provider's name server and use that,
> however, it means that you basically fall back to the DNS when resolving the
> name of the providers service.)
> Yes. I have no expertise here. What's the problem with SRV records in your
> opinion?
SRV records has two fields priority and weight to determine actual address.
By specification:
>A client MUST attempt to
>contact the target host with the lowest-numbered priority it can
>reach; target hosts with the same priority SHOULD be tried in an
>order defined by the weight field. The range is 0-65535. This
>is a 16 bit unsigned integer in network byte order.
Given some practice with zeromq, I'd say that client probably should
connect to each of lowest priority addresses (and for instance
send requests acording to weights). And ASAICS it's allowed by
specification:
>In the absence of a protocol whose specification calls for the
>use of other weighting information, a client arranges the SRV
>RRs of the same Priority in the order in which target hosts,
>specified by the SRV RRs, will be contacted. The following
>algorithm SHOULD be used to order the SRV RRs of the same
>priority:
>[.. snip ..]
There are couple of problems:
Say we have a high traffic service with 5 addresses with
priority 10 and 5 addresses with priority 20. And only 1 address
with priority 10 is available for some reason. Do you need to
switch to priority 20? Or will you send a lot of messages to
this one address until it's overflown and then connect to
ones with priority 20?
So I think SRV works with a lot of very light clients (like for XMPP)
but doesn't work well for few heavy loaded ones.
Also pub/sub and req/rep would probably use different algorithm
for choosing server (connecting to all in req/rep, and connecting
to a single one for pub/sub)
>To be totally explicit: You'll also need the name service at your
> ISP to know about other name services, you'll need a way
> to resolve unknown names by delegating the query, you'll
> need root name servers running somewhere in 24/7 mode
>and transparent fialover etc.
Sure, it's my major concern. And sure default mapping for
name service on top of DNS should be provided, but I still
think that SP is quite more useful to use between several
big providers than between zillions of desktop users so
centralised structure like DNS seems not required. And if
someone will implement desktop software using SP it can
embed SP-to-DNS mapping service in it.
There is also evidence that Google uses Chubby instead
of a DNS for name service. That matches my expectation
of DNS being too inefficient for big highly loaded services.
--
Paul
Gary Berger (gaberger)
Sent from my iPhone
Ilya Dmitrichenko
It is commonly know that load-balancing with DNS record
priorities doesn't work in the real world, therefore a instance
of load balancer would need to be implemented behind
one IP address. It can be done in many different ways,
to avoid NAT one can use Multiprotocol Label Switching
(MPLS) [1, 2, 3].
[1]: http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching
[2]: http://www.cisco.com/en/US/tech/tk436/tk428/technologies_q_and_a_item09186a00800949e5.shtml
[3]: http://blog.ioshints.info/2006/11/perfect-load-balancing-with-mpls.html
Another scenario would be to design a dumb forwarder,
but that's probably now a very stable solution.
I will have a look into Chubby also, thanks.
Cheers,
--
Ilya
Paul Colomiets
<gabe...@cisco.com> wrote:
> IMHO, DNS is a completely lost opportunity. Imagine if it existed as a graph, finding services would be relative to whatever other services were closer. For instance finding a service which delivered bond yields in the same proximity as a service providing mortgage pricing. In this way services can be discovered through their relationships instead of having the customer do Google lookups.
We see a lot of examples of providing different DNS record by location
of the request. I think your description is similar to that. But
actually I don't work for those big provides having use of that, so
don't know if it works in practice.
--
Paul
Paul Colomiets
<errorde...@gmail.com> wrote:
>
> It is commonly know that load-balancing with DNS record
> priorities doesn't work in the real world, therefore a instance
> of load balancer would need to be implemented behind
> one IP address. It can be done in many different ways,
> to avoid NAT one can use Multiprotocol Label Switching
> (MPLS) [1, 2, 3].
I'm thinking of services which have a throughtput from a
single provider much more than single node can handle.
I do not have any experience how those systems
having several machines with single IP address work, but I'm
sure I do not want to setup that thing for doing load-balancing
inside a datacenter (name service should work there too).
BTW, It seems MPLS handles one of the tasks of SP,
but at the lower level.
--
Paul
Gary Berger
OpenFlow is about controlling your local switch, there's no need for aname service.
RINA, AFAIU is more of an conceptual framework for building networkarchitectures.
Martin
--Note Well: This discussion group is meant to become an IETF working group in the future. Thus, the posts to this discussion should comply with IETF contribution policy as explained here: http://www.ietf.org/about/note-well.html
Martin Sustrik
I am not an expert on name services, so I can't really comment on the
technical stuff. However, few practical comments follow:
1. While it can make a lot of sense to use an alternative to DNS in a
centrally administered environment like Google, we are speaking here in
terms of IETF, ie. global generic standards. If we choose to create a
name service of our own the scope of the workgroup will grow
considerably, it'll become much less likely to succeed and much less
likely to be approved as an official IETF working group (the WGs should
be rather small and limited in scope).
I would second Paul's idea of defining the DNS mapping but not
necessarily requiring the rest of SP to use it. That could be done IMO,
by separating the DNS mapping document form other docuements (pub/sub
spec and alike).
2. If people want to play with different naming service architectures, I
can add a hook to 0MQ to plug in naming service of your choice. That
would allow us to get some actual hands-on experience.
Martin
Ilya Dmitrichenko
> Hi all,
>
> I am not an expert on name services, so I can't really comment on the
> technical stuff. However, few practical comments follow:
>
> 1. While it can make a lot of sense to use an alternative to DNS in a
> centrally administered environment like Google, we are speaking here in
> terms of IETF, ie. global generic standards. If we choose to create a name
> service of our own the scope of the workgroup will grow considerably, it'll
> become much less likely to succeed and much less likely to be approved as an
> official IETF working group (the WGs should be rather small and limited in
> scope).
I see that this discussion is getting away from the problem, thought there had
been no outline of the problem itself. Could everyone define their concerns,
preferably as a list of priories.
In my opinion, any of the existing IETF protocols should sufficient.
If the amount of traffic is of great concern, then of the solutions would
be to implement a optimised server which would meet the needs.
As said, there is no need to worry about priorities and load balancing
on DNS level, this part can be simply ignored since it's well known
to be insufficient (please post anything what you find that proves
that it can be otherwise).
What do you think of this scenario:
A client gets a list with >=1 of SRV records for SP servers at domain
'example.com', which all have priorities fields set to X but that is ignored
and DNSsec is in use, hence the records must be all genuine.
Then client starts communicating with any of the servers on that list
but it may receive a reply from a different IP. For additional security the
data may be signed (provided there exists hardware crypto unit which
give insignificant signature verification latency). Another measure here
would be to use IPsec also.
I am going to some additional research of existing RFCs on the subjects
which had been discussing. Meanwhile, to continue this conversation
which should really outline the problem in short.
> I would second Paul's idea of defining the DNS mapping but not necessarily
> requiring the rest of SP to use it. That could be done IMO, by separating
> the DNS mapping document form other docuements (pub/sub spec and alike).
Yes, that looks like the best approach for me also.
> 2. If people want to play with different naming service architectures, I can
> add a hook to 0MQ to plug in naming service of your choice. That would allow
> us to get some actual hands-on experience.
>
Martin, that'd be great to have there :)
Martin Sustrik
> I see that this discussion is getting away from the problem, thought there had
> been no outline of the problem itself. Could everyone define their concerns,
> preferably as a list of priories.
From my point of view the main problem is to standardise interaction
patterns between multiple applications (think: pub/sub).
The rationale for that is that the same interaction patterns are
implemented over and over again, often in a leaky or non-scalable way,
and often with little on no added value.
In theory, existing solutions could be used (e.g. MQTT for pub/sub),
however, the problem is that all the solutions I know of assume that the
whole environment is centrally controlled (single broker, single
omnipotent and omniscient administrator etc.) which doesn't play well
with typical decentralised Internet environment.
The above can be done is more or less reasonable time and would make a
sensible charter for IETF working group.
What follows is more of a research topic IMO and cannot be standardised
in IETF any time soon (although there's IRTF that may be appropriate for
this kind of work).
And here we go: It's important to cleanly separate the developer
interface from the administrative interface.
The idea follows current Internet design: Developers interact with the
Internet at the edges using simple stable API (mostly BSD socket API).
The internals of the Internet are completely hidden from the developer
ensuring that whatever changes happen to the infrastructure won't break
existing applications, won't require developers to learn about them or
even be aware of them.
The administrative interface, on the other hand, is complex and evolving
all the time. New protocols and technologies are added to the stack
(5000+ RFCs at the moment) and administrators are required to manage it
and keep track of all of it.
The whole name service discussion is an attempt to find the solution for
the above problem.
We want to limit developer API to something like this:
connect (topology-name)
send (msg)
recv (msg)
To do that we need some mechanism to translate the abstract "topology
name" into actual network address/connection/whatsoever. That way we can
separate the developer from the administrative details of the topology.
Anyway, as already said, this work is highly experimental and can't be
standardised in a short term.
Luckily, the interaction patterns can be cleanly separated from the name
resolving. We can standardise the patterns (dealing with send and recv
basically) while leaving the name resolution part (dealing with connect)
to be solved in the future.
Btw, this kind of stuff should go to SP introductory draft. Originally,
I tried to give a big picture describing the current state of Internet
service infrastructure, but thus kind of up-to-point discussion would be
much more useful. I'll try to come with something shortly.
> In my opinion, any of the existing IETF protocols should sufficient.
> If the amount of traffic is of great concern, then of the solutions would
> be to implement a optimised server which would meet the needs.
> As said, there is no need to worry about priorities and load balancing
> on DNS level, this part can be simply ignored since it's well known
> to be insufficient (please post anything what you find that proves
> that it can be otherwise).
Existing name resolution protocols can at least serve as a good starting
point. If there are deficiencies identified, they can be solved in that
context, benefiting everyone even outside of the SP context.
> What do you think of this scenario:
> A client gets a list with>=1 of SRV records for SP servers at domain
> 'example.com', which all have priorities fields set to X but that is ignored
> and DNSsec is in use, hence the records must be all genuine.
> Then client starts communicating with any of the servers on that list
> but it may receive a reply from a different IP. For additional security the
> data may be signed (provided there exists hardware crypto unit which
> give insignificant signature verification latency). Another measure here
> would be to use IPsec also.
I am really not an expert, so my opinion would be next to useless here.
However, if you want to do such thing you should:
1. Be very clear about what problem you are solving.
2. Explain why the existing solutions are not sufficient.
3. Explain how your solution addresses the deficiencies outlined above.
Btw, writing I-Ds is a pretty good way to keep you thinking in check:
http://www.ietf.org/ietf-ftp/1id-guidelines.html
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
http://xml.resource.org
> I am going to some additional research of existing RFCs on the subjects
> which had been discussing. Meanwhile, to continue this conversation
> which should really outline the problem in short.
Great, let us know what you find.
>> 2. If people want to play with different naming service architectures, I can
>> add a hook to 0MQ to plug in naming service of your choice. That would allow
>> us to get some actual hands-on experience.
>>
> Martin, that'd be great to have there :)
Ok. I'll have a look at that.
Martin