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

[Henning Schulzrinne <hgs at cs.columbia.edu>]

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           shida at ntt-at.com	PHONE: (604) 762-5606


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit