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

[Shida Schubert <shida at ntt-at.com>]

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


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