Subject: [Enum] Review of draft-ietf-enum-combined

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 06 Oct 2006 12:55:15 +0200

Hi,

i've reviewed draft-ietf-enum-combined for NITS (and more) - here are my
comments to the current version:

- idnits checker: The automatic check found no NITS - good

- The draft refers to RFC2119 in the terminology section - however,
subsequent text does not contain any such references. Please do either
actually use those normative key words, or remove the paragraph (plus the
related reference) from the document.

- Terminology: please expand "WG" to "working group"

- 2. Introduction: please expand "NS" (first para) and "URI" (third para).
I'd put "DDDS" (last para) in parentheses.

- The introduction section talks about a "proper" solution, while the
subsequent section "Interim solution" mentions a "right" solution. I'd
prefer unified terminology.

- 4. Introducing a branch into the e164.arpa tree:

There is a typo in the headline ("164.arpa")

The first paragraph seems not to reflect what is needed, but rather already
presents a solution (which is repeated in the last para of the smae
section), and might be a bit confusing without background knowledge. I'll
think about some text - please stay tuned.

Please expand NRA, NPA, ITU

- Section 5.: The first bullet on page 5 is not completely clear to me. It's
unclear what the "proper" means, and how "at the country code level" and
"into a subdomain in the country code zone" interact. probably something
like "at a defined label directly below the domain name corresponding to a
country code" or something similar is clearer.

The "insertion position" leaves out such trivial things like:
- Do we start counting the "insertion position" at 0 or 1? (i assume, it is
the number of digits to be skipped, so the "position" of 1 would indicate to
put the label between the first and second digit.
- From which side of a number do we count? I assume it's "top down" (so,
from left to right in an E.164 number), but that's not entirely clear.

Apex:
- can that be an empty string? Since it's about "replacement", an empty
string could make sense

the last bullet leaves it open whether those operations are applied to the
output of RFC3761 (which would actually lead to a fqdn ending in
e164.arpa.e164.arpa), or which steps are to be followed/skipped. Since this
is actually ome of the most important parts of this draft (because it
updates RFC3761 in respect of the transformation of E.164 to FQDN), i'd
appreciate to have this flesed out like section 2.4 of RFC3761 - it must be
completely clear how the FQDN is being constructed. eg. That bullet also
says the apex from the EBL is to be "appended", while the "apex" bullet
above says that it should be "replaced".

Perhaps making a dedicated subsection of the "transformation" logic would be
good, because it could then be referenced from section 7.

- Section 6.

I'm missing "Figure 1" - the draft just contains the bullet list of country
codes types.

- Section 7

1st bullet: The number might not be the "called" number - eg. for CNAM, it
might be the originating number for which a lookup is performed. I suggest
to change that into "The E.164 number in fully qualified (international)
format".

2nd bullet: typo - "wether".

resolver behaviour: the second bullet indicates that some "cache table" is
being used. I'm missing how this correlates to the DNS based caching of the
resolver itself.

The third star bullet roughly describes the "iteration" algorithm to find an
EBL - maybe that behaviour should be fleshed out in section 6, and just
referenced from here. "iterate over the number up to five digits" could be
interpreted in a few ways.

4th star: "inserting a label" into a fqdn automatically adds a dot, because
a fqdn by definition consists of labels which are seperated by dots.

The last sentence mentions "EBL values" as well as "EBL parameters". I
suggeset to change that into "It is assumed that parameters already
discovered from EBL records for a certain country coded are stored in a
cache table"

- 8. Security considerations

I'd change the 5th para by putting a full stop after "... the identity of
the end-user.", and change the subsequent sentence into ".... recommended to
use either anonymized UserIDs or the E.164 number itself in the user-part of
the SIP URI, such as..." (BTW: "SIP" needs to be expanded/referenced here).

- 9. IANA considerations

It's unclear to me whether the label where the EBL resides
("infrastructure") is of concern to IANA. It definitely is when more
applications are being deployed.

cheers

Alex

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