70 likes | 79 Views
This draft discusses the service types, caching, and database replication in Emergency Contacts (ECON) system. It addresses the issues of hierarchies, caching of answers, and methods of conducting database replication. It also highlights the challenges of intermixing server-to-server and server-to-client semantics, and the considerations of object signing.
E N D
Emergency Contacts (ECON)draft-hardie-ecrit-iris-02Andrew Newton, VeriSignTed Hardie, QualcommHannes Tschofenig, Siemens Andrew Newton IETF ECRIT Working Group 2 August 2005 Paris, France
Service Type • Current approaches to service type are hierarchical lists. • Certain functions are duplicated in the list. • Hierarchy implies preference order. • Do forest rangers have a policing function or just a fire prevention function? • We have broken it down into: • Function • Area • Target • We are not wed to this solution. • Many of the approaches are questionable as to their true applicability to users and user interfaces. • <listServices> query added to support locally-scoped queries.
Caching • We added caching of answers by end clients. • In the case of civic addresses… • If your civic address does not change within X number of minutes, do not requery. • In the case of geo… • If your coordinates stay within polygon Y for X number of minutes, do not requery.
Database Replication in ECON • We take no single position on database replication with ECON. • It most likely will differ greatly throughout the world. • Isn’t it out of scope? • But we have identified 3 methods of conducting database replication with ECON. • Serialized database entries to a file as specified in IRIS. • And the file transfer protocol of your choice. Many people like SFTP. • ECONREP (ECON Replication) • Interactive IRIS profile. • Replication of entries before they become active. • Incremental replication. • Anything you find that works better for your situation. • RDBMS replication • Shared Network Memory • Osmosis, crystal balls, and strong hope
Caching / Database Replication • Problematic • Are the requirements for a cache or for database replication? • What are the aggregation properties? • What about aggregation of data from different schemas? • How are relationships managed? • Do we really know all the requirements for specifying this? • Intermixing server-to-server semantics with server-to-client semantics is bad. • If a client detects a one millimeter change in location, does it requery? • Charter Issue • Isn’t this out of scope for the working group?
Object Signing Considered Harmful • My house is on fire. Who do I call? • Please update your client with the proper trust anchors. • My house is still on fire. • Please cryptographically verify these URIs. • It’s getting hotter. • Please check this CRL. • Did I mention that my house is on fire? • Object signing is useful for diagnosing problems. • But that happens after the incident, not during. • All the mechanisms to get object signing to work seem to be a pretty heavy price to pay for a diagnostic tool.
Don’t Believe the FUD • IRIS was created in the CRISP working group by TLD operators. • We know a thing or two about high resolution loads, operations of highly available services, and moving data around the globe. • If simple framing of XML is a concern, then we have bigger problems to worry about in ECRIT.