Subject: RE: [Ecrit] draft-polk-dhc-emergency-dialstring-option-00

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 16 Jun 2006 08:23:26 -0600

Both mechanisms seem to answer the same high-level requirements (Id4.)
and both have pros and cons.

I am not sure there has to be only one mechanism for getting the local
dial string and providing some flexibility to some network operators &
enterprises may help achieve the end goal: facilitate the dissemination
of the local dialstring so that the UA can apply the special procedures.

There are networks where the DHCP option would be an easy add-on while
waiting for a ubiquitous ecrit mapping service, the finalization and
implementation of the LoST protocol in UAs. Plus in some deployment
architectures (3gpp for e.g.), it may be a proxy in the network that
does the mapping resolution (not all UAs may have to implement LoST).

DHCP also offers some advantages in enterprise environments (dial 9-911
in a US office but 0,112 in some office places in Europe). With LoST,
you get the local dialstring as 911 or 112 and then the phone's dial
plan needs to be applied (and localized properly...).
In terms of implementation complexity, I'd say quite low on both the
client and server side if support for DHCP is available: requesting an
option in DHCPv4 option 55 or the DHCPv6 ORO is something all DHCP
clients should have hooks for, then there is no difference between
passing the returned DHCP or LoST value. Also a client knows right away
whether the DHCP server supports it or not... 

Jean-Francois.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, June 15, 2006 1:59 PM
> To: James M. Polk
> Cc: [email-masked]
> Subject: Re: [Ecrit] draft-polk-dhc-emergency-dialstring-option-00
> 
> I re-iterate my concern, particularly based on the recent consensus in
> the LoST discussion: LoST will have a dialstring element which will
> allow to map services (sos and other) and locations to dial strings.
> I'm
> missing why we need a second mechanism. A second mechanism presumably
> means that all clients need to implement both since they'll never know
> which service will be implemented in any particular environment. (And
> if
> that isn't the case, the "environment" [ITSP, corporation, etc.] won't
> know which one the client is implementing, so they have to provide
> both.)
> 
> Sometimes we need to have two means to do roughly the same thing since
> the requirements of different environments are so substantially
> different that no single solution works well in both types of
> environments (BGP vs. OSPF, say). This doesn't seem to be such a case.
> 
> Henning
> 
> James M. Polk wrote:
> > At 10:47 AM 6/15/2006 +0200, Hannes Tschofenig wrote:
> >> Hi all,
> >>
> >> I would like get some feedback regarding a draft published by James
> >> and Brian in Feb. 2006:
> >>
> >> http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-
> dialstring-option-00.txt
> >>
> >>
> >> Do we want/need such a solution?
> >
> > FYI -- I have -01 about to come out in the next few days. But I do
> not
> > have any major changes planned since the discussion in February was
> > centered about this ID somehow inventing a new protocol (??).  I
> didn't
> > understand what Henning said then, though I think I knew what he
> meant.
> > He was focusing on the residential user, which I do not believe will
> > move out of a country too often (necessitating a new dialstring
> > download).  I do see this extension to an existing mechanism being
> > useful in an Enterprise where users from different areas travel to
> other
> > in-enterprise sites.  This can also be useful in more public coffee-
> shop
> > type scenarios.
> >
> > I also see no reason why requiring a replacement of an existing, old
> > Linksys router to take advantage of this extension should prevent it
> > from being developed and standardized for when that router is
> replaced.
> > We have the exact same issue wrt Location using this same protocol
> in
> > that router...
> >
> >
> >> Ciao
> >> Hannes
> >>
> >> PS: Henning provided feedback some time back
> >> http://www1.ietf.org/mail-archive/web/ecrit/current/msg01578.html
> >> but I don't recall a conclusion.

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