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

From: Laura Liess <[email-masked]>
Date: Fri, 25 May 2012 12:54:48 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 May 2012 10:31:37 -0400

On 5/25/12 6:54 AM, Laura Liess wrote:

> like “Newly defined UUI packages MUST define new "content" value>>s
> and the default<<.”

It seems that this section was not updated to be consistent with the 
language now present in section 5. (The 2nd paragraph #3.) Not only can 
there be multiple valid content values for a package, but a package can 
reuse content values defined elsewhere. This means that it might not be 
necessary to define new content values when defining a package.

While looking at this I realized something else. Given the way we have 
evolved the use of "encoding", I think it would make sense to bind the 
valid encodings to a particular content value, rather than to a 
particular package. So, when defining a new "content" one would have to 
specify which encoding(s) it may have. When specifying a new package one 
would only need to specify what content values it may have.

Does that make sense to anybody else?

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Tue, 29 May 2012 10:57:54 +0200

Paul,

2012/5/25 Paul Kyzivat <[email-masked]>:

> evolved the use of "encoding", I think it would make sense to bind the valid
> encodings to a particular content value, rather than to a particular
> package. So, when defining a new "content" one would have to specify which
> encoding(s) it may have. When specifying a new package one would only need
> to specify what content values it may have.

I agree with you.  It makes much more sense to bind the encodings to
content values instead of packages. And easier to understand.

Just I am not sure which consequencies would this change have for both
drafts and if we do not run again into the "existing implementation"
issue.

I would like to know Alan's and Keith's and FT's opinion.

Thanks a lot
Laura

>        Thanks,
>        Paul
>
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss