Subject: [cuss] Comments on draft-johnston-cuss-sip-uui-reqs-00

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 23 Sep 2010 16:39:49 +0200

1)	Terminology: Abstract. The name of the ISDN service is the User-to-user signalling supplementary service, best prefixed by ISDN rather than Q.931. Thus "ISDN user-to-user signalling supplementary service"

2)	Editorial: Section 1, 2nd paragraph: type in "application".

3)	Terminology: Section 3.1. 

"If it is an ISDN gateway, it could map the UUI into the appropriate Q.931 or Q.763 element." 

Would be more accurate to revise this to: 

"If it is an ISDN gateway, it could map the UUI into the appropriate DSS1 information element or QSIG information element or ISUP parameter."

4)	Technical: Section 3.4: 

   Some scenarios involving referral have been proposed to use a REFER
   sent during an early dialog.  This NOT RECOMMENDED call flow is shown 
   in Figure 5.  This flow is not recommended due to the number of
   messages exchanged (due to the REFER, CANCEL, and 487 responses) and
   the sending of the REFER in the early dialog.  Also, there are race
   conditions that can occur if a 200 OK to the INVITE is received by
   the Originator while the REFER is in progress.

I don't see how this statement belongs in the overall requirements document, at least not in RFC 2119 language. This needs to work its way into the solutions document if it is going to be made.

Note also that "200 OK" should be "200 (OK) response", and "INVITE" should be "INVITE request" etc.

5)	Editorial: Section 4:

   REQ-2: The mechanism will allow UAs to insert and receive UUI data in
   SIP call teardown requests and responses.

Use a different word from "teardown". RFC 3261 talks about "terminating the dialog".

6)	Terminology: Section 4:

   REQ-7: The mechanism will support interworking with call control
   related ITU-T Q.931 User to User Information Element (UU IE) [Q931]
   and ITU-T Q.763 User to User Information Parameter [Q763].

Change as in comment 3) against section 3.1.

7)	Technical: Section 4:

      Understanding the mechanism means that the UAS will extract and
      utilize the UUI information transported.  Understanding the
      protocol, format, and nature of the actual UUI data is not covered
      by this requirement.  Note that this requirement is not strictly
      needed to implement the UUS 1 implicit service, but maps more
      accurately to the UUS 1 explicit service.  

I don't understand how this statement has any relationship to the UUS1 explicit service. The explicit service is about establishing the service using specific signalling ("I want UUS service 1") rather than implicitly ("Because I have sent you data in a SETUP message it must be assumed that I want UUS service 1"). Are you referring to the "UUS required" versus "UUS not required" conditions where the call is only established if the UUI is able to be sent end to end?

8)	Technical: Section 5:

   Received User-to-User information should only be trusted if it is
   authenticated or if it is received within a trust domain.  For
   example, Spec-T, defined in [RFC3324] could be used to define a trust
   domain.  When utilized by a gateway to map information to or from
   ISDN Q.931 and ISUP Q.763, appropriate policy should be applied based
   on the PSTN trust domain.

I'm not sure what sort of trust domain exists for UUI. The whole ethos of the capability is to get the information end to end, and there are no privacy statements associated with it. RFC 3325 trust domains are about only passing on the information if you believe the recipient can meet the privacy considerations.

regards

Keith

---

From: Alan Johnston <[email-masked]>
Date: Thu, 23 Sep 2010 10:52:10 -0400

Keith,

Thanks for the comments on the draft.  See mine below.

- Alan -

On Thu, Sep 23, 2010 at 10:39 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> 1)      Terminology: Abstract. The name of the ISDN service is the
> User-to-user signalling supplementary service, best prefixed by ISDN rather
> than Q.931. Thus "ISDN user-to-user signalling supplementary service"
>
>
OK

> 2)      Editorial: Section 1, 2nd paragraph: type in "application".''
>

OK

> "If it is an ISDN gateway, it could map the UUI into the appropriate DSS1
> information element or QSIG information element or ISUP parameter."
>
>
OK

> I don't see how this statement belongs in the overall requirements
> document, at least not in RFC 2119 language. This needs to work its way into
> the solutions document if it is going to be made.
>
>
Yes, this text should be moved to the mechanism draft.

> Use a different word from "teardown". RFC 3261 talks about "terminating the
OK

> Change as in comment 3) against section 3.1.
OK

> I don't understand how this statement has any relationship to the UUS1
> explicit service. The explicit service is about establishing the service
> using specific signalling ("I want UUS service 1") rather than implicitly
> ("Because I have sent you data in a SETUP message it must be assumed that I
> want UUS service 1"). Are you referring to the "UUS required" versus "UUS
> not required" conditions where the call is only established if the UUI is
> able to be sent end to end?
>

Yes.

> I'm not sure what sort of trust domain exists for UUI. The whole ethos of
> the capability is to get the information end to end, and there are no
> privacy statements associated with it. RFC 3325 trust domains are about only
> passing on the information if you believe the recipient can meet the privacy
> considerations.
>
>
This text needs to be clarified - we'll do so in the next version.

>
> regards
>
> Keith
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>