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

[Laura Liess <[e-mail]>]

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 <<).

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<<.”

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?


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.“

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