Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

[Shida Schubert <[e-mail]>]

Hi Cullen;

 Thanks for your review and comments. 

 My comments inline.

On Jun 22, 2011, at 8:08 AM, Cullen Jennings wrote:

> 
> Privacy issue: There is no way to know that the next downstream proxy support the processing required by the privacy header. 

 That is generally true for any privacy mechanism based on 3323, this is not a problem limited to 4244/4244bis. 

 Most deployments I am aware of have these servers that handle the privacy. 

> What's this for: The most concrete use is making sure a call arriving at a voice mail servers goes to the correct mailbox. However, the draft is woefully underspecified to be able to implement this from the draft. This draft specifies a bunch of data that can get dumped in a bag, but to allow interoperable implementation, it needs to say how one could use that data for some actually feature. 

 We tried to cover these use-cases in section 3.3/3.4 of 4244bis-callflow draft.

 I am not sure, the example will satisfy you, but let me know what you think.

> 
> As a coauthor of 4244, I agree this draft is better than 4244 but I don't think it is ready to publish.Given what we have learned about 4244 since it was published, I would support 4244 being changed to historic. 
> 
> Does it work? Consider text such as  
> 
>       Note, this would be
>       the original AoR if all the entities involved support the
>       History-info header field and there is absence of an "mp" header
>       field parameter prior to the "rc" header field parameter in the
>       hi-target-param in the History-info header field.  However, there
>       is no guarantee that all entities will support History-Info, thus
>       the hi-entry that matches the value of the "rc" parameter of the
>       first hi-entry with an "rc" parameter in the hi-target-param
>       within the domain associated with the target URI at the
>       destination is more likely to be useful.
> 
> This amounts to you might some information you want at X but then again you might not. The whole draft is like this - it's pretty hard to imagine this will reliably work for nearly any purpose I can think of given the limitations of the draft. 

 I think it definitely has some uses and is valuable, even it is only supported within one domain 
which intend to use this. 

 Sure, there is a good chance that some information may get lost or may not exist in the 
first place when it crosses the domain due to the reason you mentioned above, but as long 
as all the entities within a domain who wants to use it, supports it, I believe it provides useful 
information.. 

> 
> Backwards Compatibly - yes the syntax is backwards compatible but no effort has been put into consider what would happen if some elements in the network were doing 4244 and some where doing 4244bis.

 I am looking at this in more details right now, as I had some internal people form my company 
showing concern about this as well. I am hoping to add the summary of my findings in the next 
revision. 

> 
> Implementations: I'd like to know about implementations that were going to use this data. And by use, I don't mean write to the history header but instead ones that are going to read from it and use the information for some purpose. 
> 
> Does not meet requirements. As far as I can tell, the draft does not meet the requirements outline in section A.1 of the draft. 

 Do you mind being more specific if it is particular requirement you are talking about or 
are you saying all the requirements aren't satisfied by the mechanism?

 Thanks
  Shida

> 
> 
> 
> 
> 
> 
> On Jun 5, 2011, at 17:33 , Paul Kyzivat wrote:
> 
>> [as co-chair]
>> 
>> The current editor of draft-ietf-sipcore-rfc4244bis believes that the document has no remaining technical issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Sunday, June 19.
>> 
>> The latest version of the document can be retrieved here:
>> 
>> http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis
>> 
>> Any comments on the document should be sent to the SIPCORE mailing list.
>> 
>>    Thanks,
>>    Paul
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
>