Subject: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow.

From: Richard Shockey <[email-masked]>
Date: Tue, 22 Apr 2003 10:29:12 -0400

Speak now or forever hold your send button..

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 22 Apr 2003 17:25:00 +0100

>Speak now or forever hold your send button..
Hi again folks,

Apart from 
<http://www.ietf.org/mail-archive/working-groups/enum/current/msg02502.html>,
(to which still no response yet :(

These are D3S questions (Michael ?) but impinge on 2916bis.

Question - can D3S allow a "switch" in between non-terminal processing
rounds from one D3S application to another? (i.e. can a subsequent round
look for rules with a different D3S application from the one considered
in the current round?)

[This is important as without it I don't think we can use E2U NAPTRs in
which the D3S processing starts outside the golden tree - it's not quite
clear in 3401/3402, and There IS a change from 2916/2915 due to the
restrictions on NAPTR use introduced when 2915 was obsoleted by 340x.

=> 2916bis could spell the answer to the question out (perhaps in a
new (short) subsection immediately after 1.3 in the "general use" stuff)]

Question - can D3S allow one database to be examined for rules for a D3S
application in one round, and a different database to be examined for
rules for that application in a subsequent round? (i.e. if a D3S
application defines use of more than one database to store its rules,
can it "switch" databases in between non-terminal rounds?)

[My goal here is to be able to re-use the majority of 2916bis if we
ever decide to plant some rules in another database (i.e. not all data
need be in DNS) - it could happen.

=> I'm not sure that 2916bis is as "database-clean" as I think Michael
originally intended in 340x; a single sentence spelling out what can
or cannot be done in terms of Rule DB switching might be useful,
in the "general use" section; again, after 1.3]

Question - is the "1st Well Known Rule" application-specific or
database-specific?

As defined in 3402, the "1st Well Known Rule" is used to produce the first
key. As this is described in 3401 as being in the D3S Application definition
section (rather than the supported database section) I had thought that this
meant that it is NOT a database-specific key. It is defined for 2916bis
(section 2.4) to be identity; however, the "end" of this step is a domain
name, so *IS* database-specific. Thus this implies that there should be one
"1st Well Known Rule" for each supported D3S database.

=> Can we at least name this sequence of steps used to convert from
(AUS (x) Identity) into a database-specific key?

My suggestion is "Database-specific Key Generation", as that's what it
does. This would split the text in the current section 2.4 into two
parts, with a separate sub-section to cover the (reverse digits, interpose
periods, append .e164.arpa.) DNS key generation text that's there already.
so, new subsection 2.4.1. with text from "The output of the..."
up to and including the "form of domain-names from the DNS".

Looking at it, the BIND-specific stuff that follows starting "Some
nameserver implementations" might me moved above the key generation
stuff as well, but a minor point.

atb,
   Lawrence

-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Tue, 22 Apr 2003 13:18:55 -0400

>These are D3S questions (Michael ?) but impinge on 2916bis.

Impinge yes but are you suggesting clarifying text or something...are your 
comments more appropriate for a DDDSbis or 2916?

There are lots of issue , like the partial number, that may be appropriate 
for another draft on ENUM Operations etc.

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 22 Apr 2003 19:52:05 +0100

At 1:18 pm -0400 22/4/03, Richard Shockey wrote:
>Impinge yes but are you suggesting clarifying text or 
>something...are your comments more appropriate for a DDDSbis or 2916?
>
>There are lots of issue , like the partial number, that may be 
>appropriate for another draft on ENUM Operations etc.
>

Hi Richard, folks,
  BTW, I'm not just doing the traditional IETF "comments at the
last moment" for fun. I also considered whether these comments
were appropriate for an Admin/"Care and Feeding" doc or were for
2916bis, hence the long pause.

I AM asking for the clarifications on 2916bis, as the questions
I raised were to do with this document - they were all aimed at
"can we re-use the text when introducing other docs"?

The Partial Number stuff is advice on how one populates a valid
golden tree zone set. That's usage and provisioning.

These Qs relate to some poor sod trying to write a D3S/E2U client,
and relate to how it should handle the NAPTRs. For that, 2916bis
and 340x are the one and only guide, so they have to be clear.

E2U *is* different from other D3S applications in that the AUS
and the database-specific key are in reverse order. This gives
problems with REGEXP processing - it's hard to convert the order
of the AUS by a REGEXP into a "golden tree" FQDN. The DNS key
generation step is not mentioned as such in 3402, and confusion
over this (whether or not this happened ONLY at the same time as
the 1st Well Known Rule is generated or on loop back between
non-terminal processing D3S rounds as well) triggered an earlier
set of mail exchanges on this list - (see the "D3S details redux",
"ENUM root shift" and "Relief Area Codes and REGEXP" threads from
last September). Having gone through that learning experience
(many thanks to Michael), I'd like others not to fall into the same
confusion.

Hence the proposals to spell out that this happens only at the
start of the first round and to highlight it as a separate sub-step,
and that you can/can't change rule database or D3S applications
between non-terminal rounds.

all the best,
   Lawrence

---

From: Richard Shockey <[email-masked]>
Date: Tue, 22 Apr 2003 16:18:17 -0400

A
>>Impinge yes but are you suggesting clarifying text or something...are 
>>your comments more appropriate for a DDDSbis or 2916?
>>

So my question still stands Is this a 2916bis issue?   DDDS bis issue?  or 
ENUM Care and Feeding issue?

Your chair would like to avoid another round trip here....

---

From: Michael Mealling <[email-masked]>
Date: 29 Apr 2003 13:08:49 -0400

> >Speak now or forever hold your send button..

Apologies for just now getting to this....

> (to which still no response yet :(

You are correct. The document was simply changed to this:

In order to be a registered ENUM Service, the entire
specification, including the template, requires approval by the IESG and
publication of the Enumservice registration specification as an RFC.

> new (short) subsection immediately after 1.3 in the "general use" stuff)]

The problem is that delegations higher in the process may not be aware
of what you are doing. But it is a 'may' only. Since the input to a rule
is always the AUS and not the output of the last rule, each node in the
delegation process is essentially 'stateless'. Thus a Rule can't know or
care about why it got requested, as long as the Services and Flags
fields are interpreted consistently with that Rule's application.

I would say it this way: you SHOULD not switch from one application to
another, but as long as you really know what you're doing, it might be
ok. But, you should never switch from one application to another one
'willy nilly'. I.e. be VERY aware of what you are doing.

As far as the document goes I'm not sure if I'd really want to put that
in there. It doesn't say anything about it right now and that's probably
a good thing.

> can it "switch" databases in between non-terminal rounds?)

Icky! Umm..... by 'round' do you mean an iteration through the algorithm
or a completely new start at the beginning of the algorithm? I'm going
to assume you mean the first. I would strongly suggest against it unless
you really standardized the process. I can't really say definitively if
you can or can't since I only know of two databases. Is it generally ok?
Probably not. Might it be ok in controlled circumstances? possibly.

> in the "general use" section; again, after 1.3]

I really don't want to open up that issue in this document. The
pedagogical requirements around making it understandable by the average
reader would be prohibitive. I would suggest we simply keep that in our
drawer of 'things some crazy person might do one day' to keep an eye out
for. Believe me, I've come up with crazier stuff! ;-)

> Question - is the "1st Well Known Rule" application-specific or

The AUS is application specific. The database format method converts the
general Key to a database specific one.

> meant that it is NOT a database-specific key. 

Correct....

> It is defined for 2916bis
> (section 2.4) to be identity; 

Actually, the mention of that in 2.4 is just to recall the actual
definition of the AUS which is in Section 2.2. Section 2.4 is the
database specific part.

> however, the "end" of this step is a domain

Correct. 2.4 is the database part which handles converting the new,
database agnostic Key into a domain-name.

> up to and including the "form of domain-names from the DNS".

Hmm.... Isn't section 2.2 sufficiently separate?

> stuff as well, but a minor point.

I might make it a subsection considering the fact that its
implementation advice for that particular database.

-MM