Re: [cuss] WGLC review for draft-ietf-cuss-sip-uui-06

Alan,

Thank you.

Laura

2012/7/13 Alan Johnston <alan.b.johnston@gmail.com>:
> Laura,
>
> Thanks for the detailed review.  I have a few comments below.
>
> - Alan -
>
> On Fri, May 25, 2012 at 5:54 AM, Laura Liess
> <laura.liess.dt@googlemail.com> wrote:
>> Dear Vijay,
>>
>> You asked me to provide a WGLC review of the document
>> draft-ietf-cuss-sip-uui-06.
>>
>> I read the document and I think it is in good shape.
>>
>> Just a few minor comments:
>>
>> Section 3, 5-th paragraph:
>> Add explicit reference to draft-ietf-cuss-sip-uui-isdn.
>> Old text:  “Since the basic design of the UUI header field is similar
>> to the ISDN UUI service, interworking with PSTN protocols will be
>> straightforward and will be documented in a separate specification,
>> meeting REQ-6.”
>> New text: “Since the basic design of the UUI header field is similar
>> to the ISDN UUI service, interworking with PSTN protocols will be
>> straightforward and >>is<< documented in a separate specification
>>>>[I-D.draft-ietf-cuss-sip-uui-isdn]<<, meeting REQ-6.”  (changed or
>> added text is between >> and <<).
>
> Done.
>
>>
>> Section 4:
>> -       My understanding is that more than one content values can be defined
>> for a UUI package. If this is the case, the sentence “Newly defined
>> UUI packages MUST define a new "content" value.” should be something
>> like “Newly defined UUI packages MUST define new "content" value >>s
>> and the default<<.”
>
> Done.  I've also tried to incorporate text explaining that encoding is
> tied to content rather than package (purpose), as we have discussed on
> the list.
>
>>
>> Section 4.1, the example at the end of the section:
>> -       The current text: “redirection response F2 of Figure 3”.
>>          Is “Figure 3” correct here?
>>
>> -       The current text:  “The resulting INVITE F5 would contain:”  But in
>> the RFC 6567 Figure 3 (and also in Figure 2), F5 is a 200 OK.   Or did
>> I miss something?
>
> Good catch, it is actually Figure 2, and the INVITE is F4. (These all
> refer to RFC 6567)
>
>>
>>
>> Section 4.3:
>> Proxies/B2BUAs at a network border may anonymize SIP URIs in the
>> History-Info (the DT SBCs do that when the redirecting party requested
>> privacy) or may drop it (also I don’t know about real implementations
>> doing that). This is OK and the issue was already discussed on the ML.
>> In most scenarios the application in the UA consuming the UUI data
>> will be probably able to identify the sender at application level.
>> However, I think it could be useful to have some words about this
>> issue at the end of Section 4.3, something like:
>> “Proxies/B2BUAs at a network border anonymizing a SIP URI in the
>> History-Info SHOULD leave the corresponding User-to-User parameter, if
>> present, and the corresponding User-to-User header, unchanged.
>> Proxies/B2BUAs at a network border dropping a History-Info header
>> which contains User-to-User parameter, SHOULD not drop the
>> corresponding User-to-User header. In such cases the UA consuming the
>> UUI data are not able, at SIP level, to identify the source, but in
>> most cases it may be able to do it at the application level.“
>>
>
> I have included this text:
>
> Border elements such as proxies or B2BUAs which anonymize a SIP URI in
> a History-Info SHOULD leave the corresponding User-to-User parameter,
> if present, and the corresponding User-to-User header unchanged.
> Border elements removing a History-Info header containing a
> User-to-User parameter SHOULD not drop the corresponding User-to-User
> header. Otherwise, the UA consuming the UUI data may not be able at
> SIP level to identify the source of the UUI data.
>
>> But I am also OK if the authors think adding such a text is not useful.
>>
>> Section 10.2 and throughout the document:
>>         Replace [I-D.ietf-cuss-sip-uui-reqs] by [RFC6567].
>>
>> Thank you
>> Laura
>> _______________________________________________
>> cuss mailing list
>> cuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/cuss