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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Feb 2002 07:36:57 +0100

> it the TOC, or the Database one?".)

Problem is that we don't know the RFC numbers yet. The DDDS documents will
be done 2 weeks from today (my guess) and when they have numbers, they will
fall into place. The other number is the number this document will get.

This is a normal way of writing in I-D's.

What should be there is a reference at the first occation to the reference
list where the full title is. If that is missing somewhere, it should be
corrected.

When the document is turning into an RFC, these references / writings are
resolved by the RFC Editor, so they will have real numbers when published.

> line 145:  s/specify/specifies/

Ok.

> the URI (assuming that it's a terminal :)?

Maybe a combination of URI scheme and destination. But, the important thing
is that the client _can_ choose. The choice of URI scheme or service field
can in turn be different depending on available resources locally? I.e. not
only statically configured.

Say that you in the U.S. get two NAPTR RR for my phone number. One has
higher priority and is a PSTN/voice thing, and the other with lower
priority is SIP/voice. The text makes it _possible_ for you to choose the
SIP/voice NAPTR even though the other has higher priority, and that because
the PSTN/voice selection would impose higher costs for you.

I.e. it is still the case that for many ways of communicating, it is the
originator which pays. So, for me personally it is important that both the
receiver of the communication and the originator can "express" their policy.

> If not, then please add text to explain why a Key needs the initial '+'

The + should be there as part of the input to the NAPTR regexp matching,
but is not part of the domain name. This is Michaels part of the draft, and
he has to see that the WNR, AUS etc ends up being correct.

Explanation why the leading + is there is already in section 1.2. Is that
enough for you, or do you want a pointer from the WNR section to 1.2?

> new keys in the form of domain names" - suggest you add "from the DNS"
> instead). </comment>

Good catch. Thanks!

> happen some time before I retire) that appears in the D3S DNS draft.

I think this part is coming from some other DDDS specification Michael has
written. I.e. to me it seems like a general DDDS document spec. It should
be tuned more specifically to E2U.

Michael?

> NAPTR - it isn't Database.

Well, "Database" is here a DDDS terminology thing. But I guess it can be
changed so people understand the sentence. I have no problem with this.

> here. In the D3S Algorithm draft, the term "non-terminal rule" is used.

This is for Michael.

> line 271 - still has "protocol and rs" -> "enumservice".

I don't know myself if we _really_ should change the grammar from what it
is in the DDDS documents. Michael suggested it, and it is crystal clear how
this works. But, if you are used to DDDS things, you might be confused,
maybe?

One alternative is to use the same grammar as the DDDS documents, but then
have constraints for each of the values.

I personally still like this way of describing things, and I agree with you
that line 271 should be changed.

> groups he has definite views that the use of "X-" is harmful :).

:-)

Sure, but what does he use before something is really registered? Note that
we force the enumservices to exist as RFC's. When creating an RFC, I really
like writing code, and the question is what I use during that process. I do
_NOT_ like what some people do (I don't know if Henning like this more ;-)
and that is to "grab" some random string they think is free.

Problem is that if people don't get the ability to just picking something,
they will start using something (like "sipvoice"). They write the RFC, and
in the RFC say they want that string. Now, IANA or IESG say "no, but you
can get "foobar" instead. It has then happened too many times that we in
IESG get back angry email saying "but, this is already deployed, you can
not change the string for us _now_". The response is some polite version of
"Watch us".

> line  360 - s/have/will have/

Thanks.
 
> that could be expanded without mentioning the "M" word directly.

If you suggest text, I will cut and paste. I think we in this section
should list as much as possible. _ANY_ likely issue should be listed.

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

The specification (the RFC) can become historic, but the enumservice it
defines ends up being OBSOLETE. The possible "states" are normal IANA ones.
Look at the registration mechanism for content-types for example. RFC 2048.

>        * IN NAPTR 100 10 "u" "E2U+ldap"
> "!^+46(.*)$!ldap://ldap.se/cn=\1!" . </comment>

Yes, I need to look at these in detail.

Maybe someone can send in more fun examples? These are pretty boring. Or?

> </typo>

Ok.

> on lines 546-564. You might think that, but I couldn't possibly...

Well, the LDAP example existed in the previous version?

The changes is a more crisp binding to the DDDS architecture and need for
registration mechanism of enumservices.

Really needed things from my point of view.

It might be that I don't understand...

   paf

---

From: Michael Mealling <[email-masked]>
Date: Fri, 22 Feb 2002 14:23:32 -0500

I'm working on these now. I hope to be done within the hour. I won't
get all of these since some of them seem more like points of discussion.
If you don't see a particular comment here then either I've fixed it or
else I didn't have any comments since I couldn't figure out if there
was supposed to be some action taken.

> enough for you, or do you want a pointer from the WNR section to 1.2?

I've added some examples and some clarity here that I hope helps...

> be tuned more specifically to E2U.

(I hope I'm getting the line numbers right. Since I'm editing the XML
it'd be much easier if folks mentioned things by section number.)
I'm not quiet sure what the concern is here. Obviously the SRV and A 
record stuff needs to be changed but is there a general problem with the
paragraph beyond that?

> changed so people understand the sentence. I have no problem with this.

Yes. The term Database is used the way the DDDS draft is using it.
If you see terms capitalized then you know it has a very specific meaning.

> > here. In the D3S Algorithm draft, the term "non-terminal rule" is used.

Good point... How's this:

If this flag is not present then this rule is non-terminal. If a Rule is
non-terminal then clients MUST use the Key produced by this Rewrite Rule
as the new Key in the DDDS loop (i.e. causing the client to query for 
new NAPTR records at the domain-name that is the result of this Rule).

> Really needed things from my point of view.

I could change all of the examples so they just all point to VeriSign's
LDAP server! ;-)
              ^
             /|\
              |
              |

         Note: SMILEY!

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net