2.4.21 Registry Information Database Exchange Formats & P (ride)

Minutes of the RIDE BOF Meeting

Reported by Wilfried Woeber <woeber@cc.univie.ac.at>

The session started with a review of the agenda. It was asked what the position of the IESG and the area directors of APPS and OPS is for the status of the group since the group already met for the second time. Keith Moore (area director APPS) stated that he was not convinced yet to form a WG. John Curran (area director OPS) suggested to review the charter and to think about potentially structuring the work around a somewhat larger set of documents. Therefore, a second review of the draft charter was added to the agenda. Furthermore, the relation between coredb and this group was clarified. This group viewed the regional IP registries as its primary constituency. This doesn't preclude the use of the work of this group by the coredb developers, but at the same time, means that no special consideration is given to the coredb work.

A short presentation and discussion of the latest revision of the RIDE classes draft followed. The main changes to the previous version can be summarized as follows:

The layout of the document was changed on request of the group. Added recommendation on the use of the attributes:

· Required / optional - single / multiple
· Added host object (as required by InterNIC)

The next agenda item was the discussion of a proposal on how to handle RIDE references. The proposal was presented and triggered a lengthy discussion on the issues involved and helped us to decide on setting priorities for the work of the group.

The principle of the proposed reference mechanism is summarized below:

· Define a globally unique component.
· Define a local identifier for every object
· Clarification: IDs can be regarded as the equivalent of Handles
· The combination of local and global identifier will create a globally unique key for every registry object
· Use (part of) "your" domain name as the (by definition) unique registry identifier. An example is the following NIC Handle:

· An object reference can now be resolved using the following procedure:

The consequences of DNS going bad for a "mission critical" function specifically when there are already problems on the net were discussed. Given the finite number of registries, it might be feasible to use a flat table structure. It was suggested to put a note into the document, stating that an implementation might do clever things to optimize the system and to make it more stable by using the DNS for generating a local structure containing the required information.

Another issue was the impact of the scheme on the user agent(s) and the implementation at a particular registry. One could implement all this without changes to the user agents, which is one of the goals of the group. This doesn't mean that user agents could not be designed to take direct advantage of the scheme. It was proposed to avoid that rathole by separating structure from implementation details. These details, as well as other implementation hints should go to an appendix of the document, maybe even to a different doc.

The mapping between the registry identifier and the local representation was also discussed. It was suggested to make that a local problem for the registry.

Another remark suggested that we shouldn't overload DNS and take a look at the new SRV stuff in DNS. This brought us to the point how and if we should store authoritative information on were to find information regarding IP numbers, AS numbers or TLD information. It was suggested that IANA could do this, however, there were concerns raised since this is not a "strictly mechanical" assignment process. Assignment simply offers uniqueness but does not indicate any level of authority. John Curran then asked what the priorities were of the prospective WG? It was decided that this particular item could be considered one of the lower priority items. We decided that the charter should contain a prioritized list of items that we want to accomplish.

The following agenda item was a strawman proposal for the protocols and formats. It was intended to get the discussion started on the topic. The proposal helped us to iron out the requirements for the protocol and some details for the draft charter. The strawman proposal was presented and is described below including the amendments made by the group:

Requirements and Preconditions:

· Initial customers are: regional registries, routing registries, and domain registries.
· Simple to implement and to gain support.
· The system is solely for interaction between registries and does NOT replace any of the existing systems.
· Exchange data amongst the existing registries and resolve references.
· Make proper provisions for supporting extensions or new protocol versions.
· Consistency and security issues for the registries should not become more complicated or difficult (we should not make it worse).
· Timing is important, i.e., we need results *now*, yesterday would even be better.
· Implementation at a larger registry might generate high load at some servers.
· What are the required operations?

· Accept updates?

The Formats

· All data in 7bit ASCII
· It would be nice to have internationalization support, but none of the current registries was using something else then 7bit US ASCII.
· Furthermore, in an operational and international environment, the use of another character set then one's local character set on a simple system at the middle of the night fixing an operational problem was considered to be too challenging. Note that this doesn't preclude registries from adding comments to the information being presented to point to a local language version of the information.

The presentation included some more detailed discussion of some of the items. One of the topics that came up was DNSSEC. It was recommended that we should make sure that we are compatible with DNSSEC; however, a comment was made that this should probably not be an issue since DNSSEC is supposed to have no operational impact and be transparent to the users. It was agreed that we should at least check these assumptions when we decide to use the DNS for certain functionality.

The whole business of version negotiation was discussed in detail. It was proposed to replace version negotiation by capabilities announcement and negotiation. However, the group felt that this solution, while a good idea in general, could be too complicated for what we are aiming for. It was proposed to stay with a simple straightforward mechanism right now.

It was suggested to use an existing protocol, which is already explicitly mentioned in the draft charter as a possibility. This could be more practical than defining a new one. Implementation time could be cut. Also, for a new protocol proposal, we would have to defend the "limited-security" point of view. We concluded that we needed first a requirements document that allows us to start the search for an existing protocol that would suit our needs or that we could adapt an existing protocol or define a new one..

Finally, the group went line by line through the proposed charter. Wording was changed for clarification and priorities were set. Many small, but nevertheless important, changes were made to reflect the discussions earlier during the meeting. It was decided to make a revision of the charter and mail it to the list for a last review.


RIDE- Agenda
RIDE - NIC handles
RIDE - Proposal for Formats and Protocols

Attendees List

go to list

Previous PageNext Page