RE I-D:draft-kaplan-enum-source-uri-00.txt - Next Steps.

Chair hat on ...

There has clearly been a fast and furious discussion of this draft so what
I'd like to get a sense of is two things.

A. Is the problem statement contained in this Document well understood by
the WG? Does it need more clarification?

B. Is this a problem that needs to be worked on?

I'm assuming that the authors will be incorporating some of the recent
comments into a new version.

Clearly the chairs are going to have to seek some guidance from the AD's on
how to address this document and where it properly belongs.



>  -----Original Message-----
>  From: Hadriel Kaplan [mailto:[email protected]]
>  Sent: Wednesday, December 12, 2007 5:04 PM
>  To: Dwight, Timothy M (Tim); [email protected]
>  Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
>  
>  Yes exactly - it lets you do this:
>  
>                        +--------------+
>                        | PSTN routing |
>                        | logic & DB   |
>                        +--------------+
>                                |
>                                |
>  +------------+ INVITE    +--------+ ENUM+EDNS query +--------+
>  | Call       | --------> | SIP    | --------------> | ENUM   |
>  | Processing |           | app    |                 | server |
>  | Device     | <-------- | server | <-------------- |        |
>  +------------+       302 +--------+   ENUM response +--------+
>  
>  
>  OR, this:
>  
>                        +--------------+
>                        | PSTN routing |
>                        | logic & DB   |
>                        +--------------+
>                                |
>                                |
>  +------------+ ENUM+EDNS +--------+
>  | Call       | --------> | ENUM   |
>  | Processing |           | server |
>  | Device     | <-------- |        |
>  +------------+ ENUM resp +--------+
>  
>  -hadriel
>  
>  
>  > -----Original Message-----
>  > From: Dwight, Timothy M (Tim)
>  [mailto:[email protected]]
>  > Sent: Wednesday, December 12, 2007 2:12 PM
>  > To: [email protected]
>  > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
>  >
>  > I agree with Richard as to the need.  There are many cases in which
>  the
>  > response to the ENUM query needs to be different, depending on
>  "where
>  > the query came from".  The latter phrase sometimes refers to the
>  > caller's telephone number (e.g., in the case of selecting a PSTN
>  gateway
>  > to which to terminate the call, you need to determine whether
>  calling
>  > and called party are in the same rate center and if so, select an
>  > ingress point to the appropriate class 5 exchange;  otherwise select
>  an
>  > ingress point to the long distance network) and sometimes to the
>  > "administrative entity" from which you received the call (carriers
>  may
>  > have business arrangements that they need to honor, e.g., a special
>  set
>  > of ingress points for business partners).
>  >
>  > Today there are products that can vary the ENUM query response based
>  on
>  > information not present in a standard DNS/ENUM query.  Usually they
>  > combine an application server that supports both PSTN routing and
>  SIP
>  > redirect, and an ENUM server.  Sorta like this:
>  >
>  >                       +--------------+
>  >                       | PSTN routing |
>  >                       | logic & DB   |
>  >                       +--------------+
>  >                               |
>  >                               |     (augmented?)
>  > +------------+ INVITE    +--------+ ENUM query      +--------+
>  > | Call       | --------> | SIP    | --------------> | ENUM   |
>  > | Processing |           | app    |                 | server |
>  > | Device     | <-------- | server | <-------------- |        |
>  > +------------+       302 +--------+   ENUM response +--------+
>  >
>  >
>  > I suppose there must be a proprietary interface between the two;
>  which
>  > Hadriel's proposal might standardize.  That seems useful.
>  >
>  > I agree that SIP redirect overhead is much higher than that of a
>  > DNS/ENUM query.  As diagrammed above this wouldn't go away, because
>  the
>  > "dumb" call processing device still needs to talk to the "smart" app
>  > server, and SIP redirect is typically the only way to do so.
>  However
>  > obviously there are "smart" call processing devices that implement,
>  or
>  > can implement, PSTN routing logic.  In that case performance might
>  > improve substantially.
>  >
>  > Whether this has to be done by enhancing the DNS/ENUM query as the
>  draft
>  > suggests, I'm not close enough to the implementation to say.
>  >
>  > Tim
>  >
>  >
>  > > -----Original Message-----
>  > > From: Richard Shockey [mailto:[email protected]]
>  > > Sent: Wednesday, December 12, 2007 12:05 PM
>  > > To: 'Hadriel Kaplan'; 'Otmar Lendl'
>  > > Cc: [email protected]; 'Robert H. Walter'; 'Creighton, Tom'; 'Raja
>  Gopal'
>  > > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
>  > >
>  > >
>  > > Chair hat off..
>  > >
>  > > It is worth noting again that this is NOT intended for
>  > > e164.arpa or probably
>  > > any domain within the single root DNS.
>  > >
>  > > Adding a new protocol for this function would guarantee it
>  > > would not be
>  > > used...ever.
>  > >
>  > > The DNS protocols have been "fiddeled" with so long they are
>  barely
>  > > recognizable as it is. I don't see what the problem is.
>  > >
>  > > The issue of identifying where the query is coming from was
>  > > an issue in my
>  > > CNAM draft. Though it did not require identification and
>  > > authentication it
>  > > just as easily could have. The issue in using 3761 for CNAM
>  > > queries was much
>  > > more practical.
>  > >
>  > > No vendor at this stage of ENUM deployments is ever going to
>  > > put another
>  > > protocol stack in the softswitches or SMB's for this type of
>  number
>  > > translation function. In order to deploy a working protocol
>  > > to deal with a
>  > > specific use case like this you deal with the cards your
>  > > dealt and in this
>  > > case again that is 3761.
>  > >
>  > > Obviously people using SIP redirect for number translations
>  > > don't have this
>  > > problem but we all know what the issues with SIP redirect
>  > > are, for one you
>  > > get a 10X performance hit on query-response time.
>  > >
>  > > The first order issue to resolve is,  does this proposal identify
>  a
>  > > practical problem in ENUM deployments that needs to get
>  > > fixed,  and IMHO the
>  > > answer to that is unquestionably YES.
>  > >
>  > > >
>  > > >  > As this is not for e164.arpa, but private trees instead, do
>  you
>  > > >  actually
>  > > >  > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM
>  just
>  > > >  used
>  > > >  > as a simple query protocol into a single database?
>  > > >
>  > > >  Both.  The sub-tree model is incredibly useful for scaling
>  > > in bigger
>  > > >  networks or handling federations/registries, and it's also the
>  case
>  > > >  that it sometimes is just a simple query protocol to a single
>  DB.
>  > > >
>  > > >  -hadriel
>  > > >
>  > > >  _______________________________________________
>  > > >  enum mailing list
>  > > >  [email protected]
>  > > >  https://www1.ietf.org/mailman/listinfo/enum
>  > >
>  > >
>  > > _______________________________________________
>  > > enum mailing list
>  > > [email protected]
>  > > https://www1.ietf.org/mailman/listinfo/enum
>  > >
>  >
>  > _______________________________________________
>  > enum mailing list
>  > [email protected]
>  > https://www1.ietf.org/mailman/listinfo/enum
>  
>  _______________________________________________
>  enum mailing list
>  [email protected]
>  https://www1.ietf.org/mailman/listinfo/enum