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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 15 Jun 2006 10:47:27 +0200

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?

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 15 Jun 2006 14:06:23 -0500

>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...

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 15 Jun 2006 15:58:37 -0400

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:
>> I would like get some feedback regarding a draft published by James 
>> and Brian in Feb. 2006:
>>
> 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.
> 
> 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
>>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Jun 2006 10:35:54 -0400

> environments (BGP vs. OSPF, say). This doesn't seem to be such a case.

I'm in agreement here with Henning.  This seems to be the case where we 
can get away with one mechanism regardless of environment.

-andy