Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-11

Summary: Needs 2 more YES or NO OBJECTION positions to pass.

Note: This ballot was opened for revision 09 and is now closed.

Alissa Cooper Yes

Jari Arkko No Objection

Comment (2014-08-06 for -09)
Scott Brim made the following comment in his Gen-ART review:

A new sentence needs reworking:

"If an interworking point is reached, and the limitations of the ISDN (see
section 3.1) are not met, then the UUI data will not be transferred, although
the SIP request will otherwise be interworked, rather than have the
interworking point attempt to resolve the non- compliance with the limitations
of ISDN."

I suggest splitting it into two sentences, something like:

"If an interworking point is reached, and the limitations of the ISDN (see
section 3.1) are not met, then the UUI data will not be transferred, although
the SIP request will otherwise be interworked. This is  rather than have the
interworking point attempt to resolve the non- compliance with the limitations
of ISDN."

( Richard Barnes ) No Objection

Spencer Dawkins No Objection

Comment (2014-08-05 for -09)
In this text from 10.  Considerations for ISDN interworking gateways

   ISDN interworking gateways MUST support only the "isdn-uui" package
   on dialogs that are interworked.

I'm confused as to whether this is saying that this package is only supported
on dialogs that are interworked, or saying that this is the only package
gateways support on dialogs that are interworked. Could you help me understand
what's being intended?

Either way - is this saying only if the gateway is doing interworking, as
opposed to encapsulation?

( Adrian Farrel ) No Objection

Stephen Farrell (was Discuss) No Objection

Comment (2014-11-12 for -11)
Thanks for handling my discuss and sorry for being slow to clear.

Brian Haberman No Objection

Barry Leiba No Objection

Comment (2014-08-05 for -09)
No response or discussion needed for any of this; just please consider:

-- Section 2 --

   This usage is not limited to scenarios where interworking will occur.
   Rather it describes a usage where interworking is possible if
   interworking is met.

Say what?

-- Section 6 --

   The general principals of this package of the UUI mechanism are
   therefore as follows:

"principles"

-- Section 13 --
I'll make my usual comment that it's always seemed inappropriate to me to
specify an individual, usually the primary editor of the document, as the
contact for registrations done in working group documents.  As this seems to be
the norm in RAI documents (and has been done in other areas as well, including
APP), that's all I'll say: just please consider specifying a role (such as
rai-ads@tools.ietf.org) instead.No response or discussion needed here.

-- Section 15 --

   Joanne McMillen was a major contributor and co-author of earlier
   versions of this document.

We are allowed to use a "Contributors" section, which goes before the
"Acknowledgments" section, to identify especially significant contributors, and
such a section is particularly used to identify former authors.  Might it be
appropriate to do that here?

Kathleen Moriarty No Objection

Comment (2014-08-04 for -09)
Thanks for addressing the SecDir review comments.  I just have one additional
comment that is non-blocking as I would not expect this draft to address
security concerns, but rather just make sure it is clear they are handled
elsewhere.  I think the last paragraph of the Security Considerations section
makes that point clear enough.

I had a little trouble reading the second paragraph of the Security
Considerations section, and it's too long.  I'd suggest rephrasing it.  Since
you are talking about information that has higher security requirements, I'd
just say it needs a higher level of protection in that case rather than using
the word may.  If it doesn't need a higher level of protection, this sentence
doesn't apply to their decision process.  How about...

Change from:
   Information that might otherwise reveal private information about an
   individual, or where a level of authenticity needs to be guaranteed,
   may need a higher level of protection, and may indeed not be suitable
   for this package, particularly taking into account the statement in
   the following paragraph.
To:
   Information that might otherwise reveal private information about an
   individual or where a level of authenticity needs to be guaranteed,
   requires a higher level of protection and may not be suitable
   for this package.

( Pete Resnick ) No Objection

Comment (2014-08-05 for -09)
7:

                                             The UAC SHOULD set the
   "purpose" header field parameter to "isdn-uui".  Non-inclusion of the
   "purpose" header field parameter is permitted, but this is primarily
   to allow earlier implementations to support this package.

It seems to me that SHOULD ought to be MAY, and you can strike the second
sentence. It is already the case that draft-ietf-cuss-sip-uui defaults to
isdn-uui, so there is no harm in not including it.

8:

   When sending UUI for the ISDN package, the UAS SHOULD set
   the User-to-User "purpose" header field parameter to "isdn-uui".
   Non-inclusion of the "purpose" header field parameter is permitted,
   but this is primarily to allow earlier implementations to support
   this package.

Same comment as above.

Martin Stiemerling No Objection