Subject: [Enum] 2916bis initial review

From: Lawrence Conroy <[email-masked]>
Date: Fri, 22 Feb 2002 00:57:20 +0000

Hi Folks,
   as requested by our Learned authors, herewith some initial comments
on a brief readthrough of 2916bis.

<general>
First, a plea - PLEASE choose something more intuitive that RFC VVVV,
RFC WWWW, RFC XXXX, RFC YYYY, RFC ZZZZ.
This does not make things easier to read (Whilst reading through the
cycle, I keep finding myself pondering "Is YYYY the algorithn one, or is
it the TOC, or the Database one?".)
</general>

<typo>
line 145:  s/specify/specifies/
</type>

<comment>
lines 156-159 - client can choose its own ordering. Is this choice
restricted to being based on service fields and the resulting scheme of
the URI (assuming that it's a terminal :)?
</comment>

<comment disagree>
lines 187-191 - please make up your minds - either the initial Key
has a leading '+' sign, or it doesn't. The 1WNR converts from AUS
(with leading '+') to a Key. In list postings, I believe that Michael
agreed that the Key does NOT have this, so the 1ENR will NOT be null
- it has to remove the leading  '+' character. Thus AUS .NE. Key.

If this is changed (as on the list), then line 208 loses the "except for
the +", lines 212-214 go, and lines 215, 217 and 226 have the initial
number reduced. (and the text of lines 187-188 changes, of course).

If not, then please add text to explain why a Key needs the initial '+'
character.
</comment>

<comment disagree>
lines 229-230 - this *only* happens if the result of NAPTR processing is
non-terminal. Thus this is incorrect as stated.  (lose the "which produces
new keys in the form of domain names" - suggest you add "from the 
DNS" instead).
</comment>

<comment>
I'm surprised at tone of the statement on lines 232-238 - this does not
have the health warning (i.e. it's another IPV6/PKI/... and so might
happen some time before I retire) that appears in the D3S DNS draft.
</comment>

<comment disagree>
line 247 - "Database" - I think that this should be each record, or each
NAPTR - it isn't Database.
</comment>

<comment unclarity>
line 259-260 - This sentence needs work, as nothing exists at a Key; it
may exist at a record indexed by a key, or returned by a subsequent
query into the database indexed by a Key, but that is not what's stated
here. In the D3S Algorithm draft, the term "non-terminal rule" is used.
Why not use it here?
</comment>

<comment>
I like the rename from (protocol & RS) to enumservice (even though it's
slightly inconvenient for those writing specs). However, ...
line 271 - still has "protocol and rs" -> "enumservice".
</comment>

<comment>
lines 307-308 - Brave! Henning may well complain on this (in the SIP
groups he has definite views that the use of "X-" is harmful :).
(also lines 366-367).
</comment>

<typo>
line  360 - s/have/will have/
</typo>

<comment>
Security issues - lines 399-415
I recognise the template; however, one risk that is common to many of
the services "on offer" will be that a caller may be duped into
initiating an action that costs lots of money. Not exactly privacy, but
it sure is an attack. This is nearly covered in point 2, but perhaps
that could be expanded without mentioning the "M" word directly.
</comment>

<comment>
line 455 - Question: can a Service be declared Historic?
</comment>

<comment>
In addition to the changes to the examples mentioned on the list...
line 551 should be:
       * IN NAPTR 100 10 "u" "E2U+ldap" "!^+46(.*)$!ldap://ldap.se/cn=\1!" .
</comment>

<typo>
line 698 - s/URI's/URIs/
</typo>

<final comment>
The suspicious amongst us may conclude that the whole purpose of D3S and
this update (apart from frying a few surplus brain cells) is highlighted
on lines 546-564. You might think that, but I couldn't possibly...
</final>

-- 
[email-masked]: +44 1794 833666::<my opinions>:

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