Naming BoF -- GGF 13 -- Seoul, Korea - What has been going on - Timeline RNS is in GFS-WG, why do we need new WG? - There was some discussion about moving it outside of GFS - Increasingly RNS has less and less to do with GFS, but has become extracted to much larger set of resources (arbitrary). - One of the things going on in GGF is that design teams will not produce specifications or profiles. You must have a working group to do that. The RNS is a part of a continue spectrum of naming from high level to low level. Proposed timeline is very aggressive, but there is no reason to take a long time Why Names? - Usual Distributed Systems Transparencies Desireable Properties of Naming - Unique - Provide Identity - Comparable - Location Portable - Widely adopted - Scalable - high performance - Extensible - Dynamic Binding - ... - Two and three levels Two level schemes - Human - Address Three level schemes - Human -> Abstract -> Address Many schemes in the past Propsed OGSA Three Level Scheme - Human -> Abstract -> Address - Addresses represented by WS-Addressing EPRs - Abstract Names realized by WS-Naming - etc. Suspicious of why 3 levels? Can one accomodate other people's naming schemes? In general, you can have an arbitrary number of layers. In the Human to abstract space, there are many possible ways to do it. We shouldn't proclude any number of mappings. What we are suggesting is that these three have traditionally been found to be very useful. We would like to have this in order to build other services in OGSA. There are a lot of systems out there that do logical to phsyical mappings. They then require this to be very fast. They hvae specially tuned infrastructures for doing that. Would that carry on as a special case or would that map into this space. We are not procluding other naming schemes. You can insert lots of different ways into this scheme. We are not talking about how mappings are done, only what the resolution scheme is. Replica location scheme would map very well into this. RNS) 10 minute clip of RNS Came out of GFS WG. Originally focus was on data and particularly on files. As that began to mature, factor out and factor out until it was very abstract and therefor applicable at a higher level. This is why there may be a need to have RNS adopted by a WG under OGSA. What is feeling of maturity of the proposal so far? - Certainly it's a question of maturity and where it will mature. Naming is a large enough problem to substantiate a working group focus. Three tiered naming system. Basic Naming Components - Virtual Directories - Junctions -- Virtualized References -- Endpoint References -- Referrals -- Aliases Document Style Messaging - RNS Context - RNS Entry Operations Regarding tying in to other resolution serviecs. - Originally wanted to accomodate RLS. Virtualized References are one of the tie in points. Literally we are potentially federating other resolution services. What is a logical name? - Generally speaking -- Unique (potentially globally) -- What Andrew's been calling the Abstract Name What do you mean by EPR? - WS-Addressing EPR. - In the current specification, we don't mandate WS-Addressing. -- These are all strings, no mandate on format. We are proposing three levels. Human readable to whatever WS-Names are, and those in turn will get mapped again. Can you name the naming scheme that something comes from? - Could be a property, or could be addressed by WS-Naming. RNS Document Style Messaging - Beyond Traditional RPC - WSRF Compliant Service - RNS Context - RNS Entry Iterators are over persistent Context. You can extend the Qnames for an entry, but there are base QNames. WS-Naming - A Profile on WS-Addrssing EPR's - Adds two extensibility elements - Existing tooling that usesx EPRs would also work using WS-Naming EPRs Abstract Name - Unique in space and time - Strings - Comparable == only ReferenceResolver - Must be able to map abstract name to an EPR if it is possible (named entity may no longer exist) - Is also an EPR - EPR resolve (AbstractName) - EPR resolve (EPR) Are you prepared to have a big discussion about how to do these Abstract Names? Are you trying to federate different naming schemes? - We currently believe that strings are all we need. You have a string -- how do you know that the string is unique? There are many protocols that people have used over time for rapid generation of unique name. What if we have a number of different name generations? Requirements are what are important, not the actual format. How do you resolve one of these Abstract Names in order to get to an EPR? - Stress that it may not be possible -- the AN could have died. Note that ReferenceResolver is at this time an EPR. Two resolve functions EPR resolve(AbstractName) EPR resolve(EPR) Also EPR resolve() Why not use Address as the Abstract Name? Good discussion to have. Problem is that many people put URL's here which aren't invarient. We would like to say that RNS maps to EPRs, but that's up to RNS. One thing is missing -- we don't have the concept of the issuer of the binding in this example. Why not use a SAML security assertion? The resolver is the ultimate authority on this binding. We are not doing cryptographic identity. Who says that that name belongs to the entity? There has been discussion that said that that isn't in scope of this. We propose that this should be put in a charter and we should discuss it. Two issues: - Do we trust the EPR - Different authorities could be saying that the same abstract name generates two different bindings. If the resolver changes over time, then you're either stuck, or you have to have the ability to resolve the resolver. Seems to be a lot of interest in the topic. Subject to the decision of the GFSG a new working group may be approved which is where a lot of this discussion would take place. Do you think you'll get consensus from the wider community in the timeline given? Real question is can we come to consensus in here, and who are the parties we want involved. This schedule may not be realistic, but it seems like a good start. We were under the impression that moving RNS out of GFS was an OK thing to do. Normative spec will come in here and GFS will end up doing a profile for a file system. Will that slow down GFS? - It will by some amount, but it seems like a small price to pay for the level of generality we'll get. Is there going to be a document specificying what target or use cases this will satisfy. - We have requirements document (5 use cases). - But this isn't on the list of milestones. Good point. - They should be information documents and would be useful. What is the risk that WS-Addressing changes again and breaks us? - It seems like small breaking is possible, but nothing significant. - There has been talk about WS-Addressing being fixed in a month or so. Why is RNS chosen? Why not Handle System? - RNS is very simple. - RNS is about high level, but Handle System has got implementation in it. - The first specification should be a factored piece of RNS. - How you bind abstract names to endpoint references -- don't need to detail that information. - We should look at Handle System more. The deliverable in June -- is that a profile for use? - There are two pieces here -- RNS and WS-Naming. - Do the naming piece as a profile over a number of possible directories. Should this charter separte the human readable to abstract and abstract to EPR into different milestones. Should there be two different working groups or just one. We'd like to keep it as one, but seperate the milestones. The seven questions aren't part of the charter. They are things that the steering committe will expect you to answer. GGF allows us to set up a BoF discussion list before we submit to committee. How many people would participate in this WG? - Seems like enough. - We will tell Stacey to turn on bit for mailing list. 16 March 2005 Open issues still remain as to whether or not the Handle System satisfies all of the requirements for Naming. It's not clear one way or the other. There has been a decision to discuss this on a soon telecon (next perhaps). With slides and materials ahead of time that address the various points. In particular, does the system support existing naming schemes, is it human interfaceable? Etc. Should RNS be moved out of GFS or kept. One question is of timing. Can we get it out in time with a move? Also, one of credit. Can we make sure that credit isn't taken away from the GFS people. There is nothing that says that the document can't be submitted from both groups. We are still waiting for the official response from the GFS working group. Ultimately our goal is a consensus within GFS. GFS wants to see RNS ultimately in Naming, but the question is do we do that now, or does GFS get it out first, and then Naming picks it up? If GFS thinks that they will have it out in the next couple of weeks, then they should go ahead and do it. They go ahead and submit it into the document pipeline and then naming takes over after that. Decision! Turning on mailing list on which the draft charter will then be sent out for continued discussion. There is an OASIS proposal going through the room. Charter Stuff ------------- mailing list ogsa-naming-bof@ggf.org Early on it will be Charter Discussion. Also getting feedback on the milestones. Interested Consumers are People at Microsoft UVa UK e-Sciences IBM Researchers in USA and Japan.