Subject: [cuss] AD review: draft-ietf-cuss-sip-uui-isdn-08

From: Alissa Cooper <[email-masked]>
Date: Tue, 29 Apr 2014 16:58:37 -0700

I have reviewed this draft in preparation for IETF LC.  Overall, it's in
good shape, and I have requested the LC.  A couple of comments to address
with any LC comments:

Section 4 says:

"If the SIP-T method of encapsulation of ISDN instead of interworking is
used, this is a
   reasonable mechanism and does not require any extensions to existing
   SIP-T.  However, if true ISDN interworking is being done, this
   approach is not reasonable."

It’s not clear from this text why the mechanism is described as “not
reasonable.” This text should be clarified to explain that encapsulation
is not needed when ISDN interworking is being done.

Section 6 says:

"If an interworking point is reached, and
   the limitations are not met, then the UUI data will not be
   transferred, although the SIP request will otherwise be interworked.
   As a result there is also only one encoding value specified."

This text needs to be more explicit about which “limitations” it is
referring to. If it is the size limitation (128 octets plus the protocol
discriminator) or the limitation to one UUI data element, those should be
made explicit. Same goes for the text in section 7 about "the ISDN service
restrictions" — the restrictions should be made explicit.

Sections 7 and 8 say:

"When receiving UUI, when multiple User-to-User header fields are
   received in the same response with the "purpose" header field
   parameter to "isdn-uui", or with no "purpose" header field parameter,
   or with some combination of these, the UAC MUST discard all these
   header fields.  There are no mechanisms for determining which was the
   intended data packet so all are discarded."

s/data packet/UUI object/

Section 13:

The “Contact:” fields need to be filled in.

Thanks,
Alissa