ecrit@ietf.org
[Top] [All Lists]

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

Subject: [Ecrit] Re: Review: draft-ietf-ecrit-mapping-arch-01.txt
From: Shida Schubert
Date: Sun, 15 Jul 2007 22:57:10 -0700

Hi Henning;

My comments inline..


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.


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




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


Henning


--
Shida Sven Schubert           shida@xxxxxxxxxx    PHONE: (604) 762-5606




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

<Prev in Thread] Current Thread [Next in Thread>