Subject: Re: [Enum] draft-ietf-enum-operation-00.txt

From: Patrik Fältström <[email-masked]>
Date: Tue, 1 Aug 2000 11:00:31 -0400

I heard that this document was discussed when I was not in the room 
(I had to be at LDAP Replication), I got email from Scott, run over, 
but arrived too late.

Anyway, conclusion is that I will talk with Greg about these two issues:

(1) TTL issues

This was discussed a lot on the mailing list, and I proposal was to 
explicitly differ between the need for "fast" and "slow" updated, and 
how each one of these can be implemented. In the case of "slow" 
updates, I claim that it is ok to store the URI directly in the 
NAPTR, while when you need "fast" updates, you should store the data 
somewhere else, and have a URI referencing this "other" data storage 
in one NAPTR.

(2) Other issues

You can the same way have a need for storing information for other 
reasons than for "speed of updates", and those can include the need 
for authentication of the querying party before giving back 
information etc.

We definitely need a separate draft talking about how this secondary 
service which will be referenced in both case (1) above and this 
point.

(3) Section 4.2

I wrote:
>>4.2 Second Level: Determining the service registrar and retrieving
>>Resource records.
>>
>>    The second level uses MX or SRV RRs to discover the NAPTR RRs to
>>    discover the URL for other service- identity of the appropriate
>>    service-specific directory such as an LDAP directory server, H.323
>>    gatekeeper, or specific endpoint addresses.
>>
>
>You do not use MX and SRV RRs to discover NAPTR RRs.

I.e. section 4.2 doesn't explain how you really are using DNS or 
whatever to find the actual information you look for. The paragraph 
above is wrong.

The only way I could understand (it might have been too early in the 
morning, but anyway) this part was by looking at the examples, which 
from my point of view is not about the same things as what is 
described in section 4.2. I.e. 4.2 says one thing, and the examples 
are doing something else.

(4) About the examples

A meta-issue:

This wg is about how to find a URI given a E.164 number. We all know 
that. This decision was taken just because some people like myself 
belive that doing

  E.164 -> URI -> whatever service

is better than doing directly

  E.164 -> whatever service

just because one normally always need additional information than the 
E.164 to be able to use the "whatever service", and that that 
additional information in most cases can be part of the URI scheme 
defined by the "whatever service".

A client which want to get more information given a E.164 need to 
know what to do. I claim that the correct thing a client should do is 
to query for NAPTRs for the E.164 and that way get back URIs, which 
can be used for further exploration for each one of the URI schemes 
the client supports.

Greg in this draft directly query for the SRV RR which is created by 
the interest in "a specific srv-service" and the domainname which is 
given by the E.164.

This means that the wg has two different ways a client can get more 
information. One is to look up a URI, and a second which is (from my 
point of view) guessing what service might be supported and query for 
the SRV.

You all understand what I feel about this :-) but I want advice from 
the wg chair on what to do.

Regardless of this discussion, I would like to have some more 
examples and ideas in the enum operations draft which uses the 
mechanisms defined in draft-ietf-enum-e164-dns.

      Patrik

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum