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

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?

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

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.

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.

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?

Thanks for handling my discuss and sorry for being slow to clear.