Subject: Fwd: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt

From: Richard Shockey <[email-masked]>
Date: Thu, 03 Jul 2003 10:31:02 -0400

DISCLAIMER: I was asked to cross this posting from the ENUM WG list here....

>From: Stastny Richard <[email-masked]>
>To: Richard Shockey <[email-masked]>, [email-masked]
>Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t
>         xt
>Date: Thu, 3 Jul 2003 06:46:58 -0400
>X-Mailer: Internet Mail Service (5.5.2653.19)
>
>
>Hi all,
>
>I have some comments and also some serious problems with this draft.
>
>General comment:
>
>It may be a dogma in the religion of SIP, but SIP is not the center of
>the world ;-)
>
>General comment: what kind of RFC this will be?
>
>The good news first: it is nice to hear that "the most widespread
>application for
>SIP today is voice", or "the most common application in SIP is
>telephony" and
>that "in most cases, these are request for a telephone session (voice
>communication)"
>
>Comment:
>
>I am getting a bit tired to be lectured permanently without asking for
>it that there is two
>types of SIP URIs (if this is such a problem, then why not put a
>parameter or create
>a sipL: URI) and no contact addresses should appear in ENUM. As far as I
>know from
>praxis, nobody ever tried to do this.
>
>  "SIP URIs in ENUM do not convey capability information.  SIP has
>       its own methods for negotiating capability information between
>       user agents (see SDP [13], the use of Require/Supported to
>       negotiate extensions in RFC3261, and callee capabilities [11]);
>       providing more limited capability information within ENUM is at
>       best redundant and at worst potentially misleading to SIP's
>       negotiation system.  Also, addresses-of-record do not have
>       capabilities (only devices registered under an address-of-record
>       have actual capabilities), and putting contact addresses in ENUM
>       is not recommended."
>
>Amen, btw, a tel URI is also an address-of-record (better: a name) and
>does not
>convey any cabability information. On the other hand, if an "author"
>want to put capability
>information in ENUM, it is his problem
>
>Comment:
>"Only one SIP URI appears in an ENUM record set ..."
>This is up to the ENUM subscriber, is it necessary for them to read this
>document?
>See also section 5. Authoring of NAPTR records
>
>Comment: 5.1
>"It is strongly RECOMMENDED that authors of NAPTR records use the
>'E2U+sip'
>service field whenever the regexp contains a SIP address-of-record URI."
>
>Are we doing commercials in IETF drafts?. If another enumservice with
>sip URI
>is registered with IANA the "authors" may use, if not, not.
>
>Major problem: 5.2
>5.2 Flags in NAPTR RR
>
>"Authors of NAPTR records MUST use the terminal "u" flag when
>'E2U+sip' is specified as a Service field."
>
>Why?, and if this is so, it must go into the draft-ietf-enum-sip IANA
>registration.
>
>Major problem: 5.3
>"Authors of
>    records intended to be used for SIP applications SHOULD always use a
>    greedy regexp; no use-cases have been identified today in which a
>    different antecedent is necessary."
>
>I strongly object this.
>First, the use of regular expessions is a feature in ENUM and DDDS,
>second, there are use cases (e.g. in wildcards) and
>third, if there is no-use cases, why is are regular expression there in
>the first place?
>
>Comment: 5.4
>"NAPTR records that
>    are intended to be used for session initiation (including SIP
>    telephony) SHOULD use a SIP URI."
>
>"It is RECOMMENDED that authors of ENUM records should always use the
>    SIP or SIPS URI scheme when the service field is 'E2U+sip', and the
>    URIs in question MUST be addresses-of-record, not contact addresses."
>
>Another commercial?
>
>Comment: 5.4
>
>'E2IPv4+sip'
>
>What is this?
>
>Comment: 5.6
>
>"$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa.
>       IN NAPTR 100 10 "u" "E2U+sip"    "!^.*$!sip:[email-masked]!"
>.
>       IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:[email-masked]!"
>."
>
>?
>I am glad that at least "email:mailto" is allowed beside SIP ;-) No spam
>problem?
>
>Comment: 5.
>
>"These guidelines do not by any means exhaustively describe the NAPTR
>    algorithm or the processing of NAPTR records; implementers should
>    familiarize themselves with the DDDS algorithm and ENUM before
>    reviewing this section."
>
>MM will like to hear this one ;-)
>
>Richard
>
> > -----Original Message-----
> > From: Richard Shockey [mailto:[email-masked]]
> > Sent: Wednesday, July 02, 2003 10:39 PM
> > To: [email-masked]
> > Subject: [Enum] Fwd: [Sipping] I-D
> > ACTION:draft-ietf-sipping-e164-03.txt
> >
> >
> >
> > FYI
> >
> > >To: IETF-Announce: ;
> > >Cc: [email-masked]
> > >From: [email-masked]
> > >Reply-to: [email-masked]
> > >Date: Wed, 02 Jul 2003 16:33:49 -0400
> > >Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt
> > >Sender: [email-masked]
> > >X-BeenThere: [email-masked]
> > >X-Mailman-Version: 2.0.12
> > >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
> > >         <mailto:[email-masked]?subject=unsubscribe>
> > >List-Id: SIPPING Working Group (applications of SIP)
> > <sipping.ietf.org>
> > >List-Post: <mailto:[email-masked]>
> > >List-Help: <mailto:[email-masked]?subject=help>
> > >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
> > >         <mailto:[email-masked]?subject=subscribe>
> > >
> > >
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> > >directories.
> > >This draft is a work item of the Session Initiation Proposal
> > Investigation
> > >Working Group of the IETF.
> > >
> > >         Title           : Using ENUM for SIP Applications
> > >         Author(s)       : J. Peterson, H. Liu, J. Yu, B. Campbell
> > >         Filename        : draft-ietf-sipping-e164-03.txt
> > >         Pages           : 22
> > >         Date            : 2003-7-2
> > >
> > >Although SIP was one of the primary applications for which ENUM was
> > >created, there is nevertheless a need to define procedures for
> > >integrating ENUM with SIP implementations.  This document
> > illustrates
> > >how the two protocols might work in concert, and clarifies the
> > >authoring and processing of ENUM records for SIP applications.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-03.txt
> > >
> > >To remove yourself from the IETF Announcement list, send a
> > message to
> > >ietf-announce-request with the word unsubscribe in the body of the
> > >message.
> > >
> > >Internet-Drafts are also available by anonymous FTP. Login with the
> > >username "anonymous" and a password of your e-mail address. After
> > >logging in, type "cd internet-drafts" and then
> > >         "get draft-ietf-sipping-e164-03.txt".
> > >
> > >A list of Internet-Drafts directories can be found in
> > >http://www.ietf.org/shadow.html or
> > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > >Internet-Drafts can also be obtained by e-mail.
> > >
> > >Send a message to:
> > >         [email-masked].
> > >In the body type:
> > >         "FILE /internet-drafts/draft-ietf-sipping-e164-03.txt".
> > >
> > >NOTE:   The mail server at ietf.org can return the document in
> > >         MIME-encoded form by using the "mpack" utility.  To use this
> > >         feature, insert the command "ENCODING mime" before
> > the "FILE"
> > >         command.  To decode the response(s), you will need
> > "munpack" or
> > >         a MIME-compliant mail reader.  Different
> > MIME-compliant mail readers
> > >         exhibit different behavior, especially when dealing with
> > >         "multipart" MIME messages (i.e. documents which
> > have been split
> > >         up into multiple messages), so check your local
> > documentation on
> > >         how to manipulate these messages.
> > >
> > >
> > >Below is the data which will enable a MIME compliant mail reader
> > >implementation to automatically retrieve the ASCII version of the
> > >Internet-Draft.
> > >Content-Type: text/plain
> > >Content-ID:     <[email-masked]>
> > >
> > >ENCODING mime
> > >FILE /internet-drafts/draft-ietf-sipping-e164-03.txt
> > >
> > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipping-e164-03.txt>
> >
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Marian Durkovic <[email-masked]>
Date: Mon, 7 Jul 2003 14:51:13 +0200

OK, but all this still translates to me as "use with care" and not as 
"don't use at all". Sure the DNS admins should be aware of the issues
described in RFC1912. Regarding the DNSSEC, ENUM could perhaps apply the 
attitude described in draft-ietf-dnsext-dns-threats-03.txt:

     ...since the alternative of giving up wildcards entirely is not 
     practical due to widespread use, we are going to have to live with 
     wildcards, and the question just becomes one of whether or not the 
     proposed optimizations would make DNSSEC's wildcard proof mechanisms 
     more or less fragile.

Anyway, the original topic was, that we all should always use a greedy
regexpr which is (not only but also) due to possible use in wildcards
and/or in synthesizing DNS servers certainly not a good idea.

	With kind regards,

		M.

On Mon, Jul 07, 2003 at 11:35:09AM +0200, Patrik Fältström wrote:
> On måndag, jul 7, 2003, at 10:42 Europe/Stockholm, Martin Streller 
> wrote:
> 
> >> The wildcard in DNS
> >> have many side effects -- most of them today felt being negative.
> >
> > you may admit such a statement is a bit vague and nebulous.
> >
> > Given an example like Marian's or mine - what are the definite
> > side effects that you feel negative about ?
> 
> (1) If you have an owner which have a CNAME, you can not have any other 
> RR with the same owner. Many many people fail on this (for example, 
> they add an MX record).
> (2) The implications with DNSSEC is not known in enough detail. 
> Especially when looking at negative caching. Yes, compared to some 6-12 
> months ago, there are ideas on how it might work, but the proposal is 
> still to run wildcards in either a delegated zone which is not secure, 
> or you synthesize your records, which in turn means you need to have 
> the private key online.
> (3) It is easy to forget the wildcard when you later need to delegate 
> something, and understand the implications (together with (1) above).
> 
> But, the largest problems are with (1) and (2).
> 
> As DNSSEC is important for ENUM, I rather stay away from wildcards. The 
> wildcards _can_ be simulated by either generating many records, or by 
> having a DNS server which synthesizes the records.
> 
> Another problem when you do ENUM is that there will be responses if 
> someone query for for example:
> 
>   NAN.1.2.3.4.6.4.e164.arpa. + IN + NAPTR
> 
> and in the DNS I have
> 
>   *.1.2.3.4.6.4.e164.arpa. IN NAPTR ....
> 
> I don't like that. You might want to store other RR types with similar 
> names in the same hierarchy, for example SRV records (which Microsoft 
> Active Directory uses heavily) or whatever.
> 
>      paf
> 
> 
> >
> > Martin
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Patrik Fältström [mailto:[email-masked]]
> > Gesendet: Sonntag, 6. Juli 2003 18:32
> > An: Marian Durkovic
> > Cc: [email-masked]; [email-masked]
> > Betreff: Re: [Enum] Fwd: [Sipping] I-D
> > ACTION:draft-ietf-sipping-e164-03.t xt
> >
> >
> > On söndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic
> > wrote:
> >
> >> On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik Fältström wrote:
> >>> Can we please keep the discussions about the wildcard in DNS separate
> >>> from the regular expression in NAPTR as separate as possible?
> >>
> >> I don't think this is fully possible. If you want to use wildcard in
> >> DNS,
> >> you must use non-greedy regular expression with a subpattern ( ) to
> >> extract
> >> and reuse the digits matched by the wildcard:
> >>
> >> $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa.
> >> * IN  NAPTR   100 10 "u" "E2U+sip"
> >> "!^\\+42155555(.*)$!sip:1\\[email-masked]!" .
> >
> > Yes, you are absolutely correct. And one can say dependencies exists in
> > the other direction as well.
> >
> > BUT, today I still see a large number of arguments (especially when
> > looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards
> > in DNS.
> >
> > My point is that that is not enough as an argument for removing the
> > regular expression in the NAPTR for ENUM. It is needed anyway, and I
> > gave an example.
> >
> > You say you don't want a million NAPTR records in your DNS server, and
> > I can understand that given the most common provisioning mechanisms
> > which exists.
> >
> > The IETF do though concentrate on what goes on the wire between hosts,
> > and not so much of how things are inside the host itself.
> >
> > I.e. you might have some DNS software that you can configure given some
> > kind of wildcard, BUT, it will not be a wildcard from a DNS
> > perspective. That is a very very big difference. The wildcard in DNS
> > have many side effects -- most of them today felt being negative.
> >
> >      paf
> >
> >
> > enum mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/enum