[ESDS] ESDS and bootstrapping

[Stephen van Egmond <[e-mail]>]

To paraphrase the definition of bootstrapping in the ESDS problem
statement, bootstrapping starts with the problem of an entitty that has
only an object identifier (probably an RFID tag) and wants to find out
more about the thing it's attached to.

In the current EPCglobal architecture, the answer involves ONS and
ultimately the DNS root servers.  The answer also opens a number of
information leaks about every participant's manufacturing process,
internal structure, and inventory, to name just a few.

What we would like to do is come up with a solution that doesn't rely
on DNS, and provides better security. Here's some ideas.

The main challenge is discovery: given a object identifier (hereafter oid),
which DS instance can tell me more about it? 

We're thinking maybe an out-of-band communication protocol that has less
stringent security, on a different SOAP endpoint:
http://ds.company.biz/ -- regular DS traffic
http://ds.company.biz/announce -- peer to peer information exchange


The information exchange would understand some straightforward requests.
We presume that the peer is able to formulate a reasonably random peer ID that
would uniquely identify it.  This is open to spoofing, but given the protocol
that's easy to detect and track down.

setPeerProfile(peer_id, profile)
- This announces that peer_id conforms to the given profile.
  The profile might have information about the company or department,
  and what object identifier ranges it answers.  A simple example for
  an airplane manufacturer (AirTrain) is to announce that it understands
  object identifiers:
	aircar.*

  This profile information should at least indicate:
	- object ID patterns that it understands
	- publically routable IP/port combinations for their DS
	  servers, along with order of preference, similar to MX 
	  servers for SMTP
	- ownership information (company, administrators, and phone/email
	  contact info)
	- an expiry timestamp after which the profile should be considered expired.
	- of course it would be extensible
	- how many DS peers it knows about

The peer profile should be updated periodically, certainly well within
the expiry timeframe.

getSupernodes()
 
- Publically-spirited DS operators could offer to act as supernodes
  for peer profiles, which will let them collect peer profiles and act as
  clearinghouses within the network.  This function would return a list
  of other DS's that the requestor should offer its profile to.

getPeerProfiles(spec)

- This would return a list of currently-valid peer profiles that DS
  instance knows about that match the specification. So if you have an
  object ID that is aircar.581.958198705171 you might reasonably inquire
  about aircar.581.* and aircar.*.


Other possibilities

The DS bootstrap problem may eventually converge on the same problem as Internet routing tables?

What about something like XMPP's Service Discovery (draft) extension? This
might provide a way for peers to publish information about the extensions
(the E in ESDS) they offer.
http://www.xmpp.org/protocols/disco/


References

I'm borrowing from the bittorrent specification, which is admirably brief.
http://www.bittorrent.org/protocol.html

XMPP Standards Foundation is a clear and lucid standards body.
http://www.xmpp.org/protocols/

UDDI contributed the idea of a service discovery protocol that uses the same
protocol as the service itself.





----- End forwarded message -----

_______________________________________________
ESDS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/esds