Subject: [Ecrit] Re: Review: draft-ietf-ecrit-mapping-arch-01.txt

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jul 2007 20:06:37 -0400

Shida,

thanks again for your comments, which I'm trying to integrate into  
-03. It will appear shortly at

http://www.cs.columbia.edu/sip/draft/lost-arch/draft-ietf-ecrit- 
mapping-arch-03.html

which I will update as this discussion unfolds.

Please see inline below.

On May 9, 2007, at 7:10 PM, Shida Schubert wrote:

> Draft: draft-ietf-ecrit-mapping-arch-01
> Reviewer: Shida Schubert
> Review Date: 2007.05.09
>
> Summary:
> ----------------------------------------
> - The draft looks really really good and solid and very  
> informative   indeed. I think the draft is ready for WGLC if the  
> draft was a   stand alone draft, but raises some questions on its  
> value when   I view it as a draft providing overall picture for how  
> mapping   works.
>   It may be simply because of my ignorance, but I had a really    
> hard time trying to map some of the logical entity to real   world  
> deployment introduced in this draft such as forest guide.
>   It would be good to expand the text a bit to show for example    
> what entity would serve forest guide and what logical entity   LoST  
> server generally serves etc.

I've tried to add additional text to clarify that these are logical  
roles within the mapping architecture and that all of these are  
speaking LoST. Some, such as FGs, may also speak the sync extensions.

>
>
> Technical Comments:
> ----------------------------------------
> T1: Section 3, seeker. - Description of the seeker seems to  
> contradict what's   mentioned in the section 5. In section 3, it is  
> clearly   stated that skeeker may cache mapping result for its    
> own use and not provide any mapping service to others,   yet  
> section 5 mentions about outbound proxy caching the   mapping  
> result to provide its user.. How would the outbound
>   proxy provide the caching? I am assuming it is when it sees    
> LoST query from its user, wouldn't it be providing mapping    
> service once it's responding to a LoST query?
>
>

I don't quite understand this comment. A SIP proxy is a (LoST) seeker  
in this architecture. The proxy issues queries and can cache the  
results locally. If it gets another SIP-carried location, it can thus  
consult its (seeker) cache and route the SIP request without issuing  
another LoST query to its resolver.

Does that make sense?

Henning

> --
> Shida Sven Schubert           [email-masked]	PHONE: (604) 762-5606

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

---

From: Shida Schubert <[email-masked]>
Date: Sun, 15 Jul 2007 22:57:10 -0700

Hi Henning;

 My comments inline..

>> - The draft looks really really good and solid and very informative   
>> indeed. I think the draft is ready for WGLC if the draft was a   
>> stand alone draft, but raises some questions on its value when   I 
>> view it as a draft providing overall picture for how mapping   works.
>>   It may be simply because of my ignorance, but I had a really   hard 
>> time trying to map some of the logical entity to real   world 

The section 4 looks good with the added text.. Thanks.

>> clearly   stated that skeeker may cache mapping result for its   own 
>> use and not provide any mapping service to others,   yet section 5 
>> mentions about outbound proxy caching the   mapping result to provide 
>> its user.. How would the outbound
>>   proxy provide the caching? I am assuming it is when it sees   LoST 
>> query from its user, wouldn't it be providing mapping   service once 
>> it's responding to a LoST query?
>>
>>
>
 Yes it makes complete sense and it does not contradict the definition 
of section 3 at all.

 I am not sure what I was taking when I wrote this comment.. I can only 
assume what
I had in mind, but I guess from the comment I wrote, I must have assumed 
that the SIP proxy
would actually respond to LoST query sent from a UA and proxy the LoST 
query and cache
the response from the resolver.. So after reading the text in section 3 
once again, I see no
problem with the text, the text looks good..

 Thanks & Regards
  Shida