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

[Alan Johnston <[e-mail]>]

Laura,

Thanks for the detailed review.  I have a few comments below.

- Alan -

On Fri, May 25, 2012 at 5:54 AM, Laura Liess
<[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cuss