Subject: [Sip] Comments on draft-ietf-sip-gruu-11

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 24 Nov 2006 22:04:43 +0100

My comments as follows (as you can see I have found nothing particularly
major in the document that requires correction). I have also sent some
NITs direct to the editor.

1)	This is really a NIT, but as it involves two documents I will
raise it on the list. We need to get the textual usages of the instance
id parameter consistent between draft-ietf-sip-gruu and
draft-ietf-sip-outbound. draft-ietf-sip-gruu seems to mainly call it a:

	"+sip.instance" parameter in the Contact header field
	"+sip.instance" Contact header field parameter

But I note at least instances of

	"sip.instance" media feature tag [14] as a UA characteristic [7]
	"+sip.instance" header field parameter

For exactly the same thing.

In draft-ietf-sip-outbound (-06 to appear) we have the following:

	"sip.instance" media feature tag as a UA characteristic
[RFC3840]
	the Contact header field as the "+sip.instance" Contact header
field parameter
	sip.instance media feature tag
	the +sip.instance Contact header field parameter
	an instance-id media feature tag 
	+sip.instance media feature parameter is present in a Contact
header field value 

Can Jonathan and Rohan work together to agree a common and consistent
usage.

2)	Again, a NIT, but the same thing. In both documents can we also
use "UA instance" rather than just "instance". Mostly consistent, but a
few exceptions. In outbound there is also a "SIP UA instance" where I
think the "SIP" is unnecessary.

Can Jonathan and Rohan work together to agree a common and consistent
usage.

3)	Again a NIT but the same thing.

"Instance ID" is used throughout in draft-ietf-sip-gruu.

In draft-ietf-sip-outbound we have the following definition:

   instance-id: This specification uses the word instance-id to refer to
      the value of the "sip.instance" media feature tag in the Contact
      header field.  This is a Uniform Resource Name (URN) that uniquely
      identifies this specific UA instance.

Followed by usage of that term throughout the document...except:

Title 4.1: "Instance ID Creation" and also within the contents of same
section.

Can Jonathan and Rohan work together to agree a common and consistent
usage.

4)	In section 4.1 we have:

   The contact URI MUST NOT be equivalent, based on the URI
   equality rules in RFC 3261, to the AOR in the To header field.

I was trying to work out why this was a normative requirement of the
GRUU document, given that it is followed by:

   If
   the contact URI is a GRUU, it MUST NOT be a GRUU for the AOR in the
   To header field.

Which is the normative statement within the scope of GRUU, is the first
statement really normative (with a MUST).

5)	Again a NIT, but can we please use RFC numbers in the
references. I know what you have done is allowed in the rules, but I get
fed up trying to remember that [14] is outbound. It is, isn't it?

6)	Section 5.1, current text is:

   Next, the registrar SHOULD create a new temporary GRUU for the AOR
   and instance ID with the characteristics described in Section 5.4.
   The temporary GRUU construction algorithm MUST have the following two
   properties:

   1.  The likelihood that the temporary GRUU is equal to another GRUU
       which the registrar has created MUST be vanishingly small.

   2.  Given a pair of GRUUs, it MUST be computationally infeasible to
       determine whether they were issued for the same AOR or instance
       ID or different AORs and instance IDs.

I would prefer to make this a registrar requirement by rephrasing the
text in the following manner. Also the MUSTs in 1) and 2) are not
necessary because they are part of the first MUST in the main text.

   Next, the registrar SHOULD create a new temporary GRUU for the AOR
   and instance ID with the characteristics described in Section 5.4.
   The registrar MUST apply a temporary GRUU construction algorithm 
   with the following two properties:

   1.  The likelihood that the temporary GRUU is equal to another GRUU
       which the registrar has created is vanishingly small.

   2.  Given a pair of GRUUs, it is computationally infeasible to
       determine whether they were issued for the same AOR or instance
       ID or different AORs and instance IDs.

7)	Section 5.3:

   If, as a consequence of the expiration of the contact, a particular
   GRUU no longer has any registered contacts bound to it, and the GRUU
   is a temporary GRUU, the GRUU MUST be destroyed.  

Change to:

   If, as a consequence of the expiration of the contact, a particular
   GRUU no longer has any registered contacts bound to it, and the GRUU
   is a temporary GRUU, the registrar MUST destroyed the GRUU. 

I assume the above is a registrar requirement but the current text does
not seem particularly clear in that regard.

8)	Section 5.4:

   When a registrar creates a GRUU, it is required to maintain certain
   information associated with the GRUU, regardless of whether it is a
   public or temporary GRUU.  Every GRUU is associated with a single AOR
   and a single instance ID.  A registrar MUST be able to determine the
   instance ID and AOR when presented with a GRUU.

I think the "MUST" is in the wrong place here. We need a wording that is
more like:

	Every GRUU is associated with a single AOR and a single instance
ID. 
	When a registrar creates a GRUU, a registrar MUST maintain
certain 
	information associated with a GRUU,
	regardless of whether it is a public or temporary GRUU, such
that it 
	can determine the instance ID and AOR when presented with a
GRUU."

9)	Section 5.4:

   There can be multiple GRUUs with the same instance ID and AOR.
   Indeed, this specification requires registrars to maintain many - one
   that is public, and several that are temporary.  However, if two
   GRUUs are associated with different AOR or different instance IDs or
   both, the GRUUs MUST be different based on URI equality comparison.
   A GRUU in a domain MUST NOT be equivalent, based on URI comparison,
   to any AOR in a domain except for the one associated with the GRUU.

Again I think we have lost the MUST requirement here. Surely the
requirement is that "A registrar MUST create GRUUs" that fulfil these
rules.

10)	Section 5.4:

   This specification does not mandate a particular mechanism for
   construction of the GRUU.  Several example approaches are given in
   Appendix A.  However, in addition to the properties described in
   Section 3.1, a GRUU constructed by a registrar MUST exhibit the
   following properties:

Again I think this needs to be rephrased as a registrar requirement.
Change to:

   This specification does not mandate a particular mechanism for
   construction of the GRUU.  Several example approaches are given in
   Appendix A.  However, in addition to the properties described in
   Section 3.1, a registrar MUST construct a GRUU such that it exhibits
the
   following properties:

11)	I note the following text in section 5.3:

   If, however, the GRUU was a public GRUU, the registrar SHOULD
   continue to treat the GRUU as valid.  Consequently, subsequent
   requests targeted to the GRUU, prior to re-registration of a contact
   to the GRUU, SHOULD return a 480.  In addition, since the GRUU
   remains valid, the rules in Section 5.1 will cause it to be retained
   when a contact with that instance ID is once again registered to the
   AOR.

And the following in section 6.1:

   If there are no registered contacts bound to the GRUU, the server
   MUST return a 480.  If there are more than one, the rules described
   in Section 7 of [14] for selecting a single registered contact apply.
   Any caller preferences in the request [19] SHOULD be processed
   against the contacts bound to the GRUU.

It appears to me that one requirement (6.1) is a more generic
requirement of the other, and as it is a MUST strength, the former one
is not valid at SHOULD strength.

12)	Section 7:

   The quoted strings for temp-gruu and pub-gruu MUST contain a SIP URI.
   However, they are encoded like all other quoted strings and can
   therefore contain quoted-pair escapes when represented this way.

I am not keen on writing MUSTs in grammer sections in this manner as I
am never sure if it is a sender or receiver requirement. It appears to
me that we have a requirement elsewhere in the document that says
(section 5.1):

   If the contact is not a SIP URI, the REGISTER request MUST be
   rejected with a 403.

Therefore I assume the only requirement here is one for the UA
generating GRUUs.

Regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip