[Ballot discuss]
It's really scary to progress this ahead of GRUU. The issues is that it is not clear what GRUU will do with the anonymous property. If some GRUU decides to have the anonymous property, then we need to decide if the security considerations for anonymous GRUU are different than non anonymous GRUUs. It seems likely that due to the stateless implementations of GRUU, this will not be able to report every GRUU but only one non anonymous one.

I realized later my comment had not made it obvious enough how this could be resolved. GRUUs, being a URI, have the potential to have many properties as GRUU points out. The security section probably wants to mention say that what gets handed out in a reg event depended on the properties of the GRUU and the authenticated users of the subscribe. Specifically one could say something along lines of if a GRUU also has the anonymous property, then it MUST NOT be handed out to any one other than users that can authenticate as the same principal as the AOR in question. This allows this draft to be correct regardless what way we go on GRUU with regards to anonymous properties.

I think it would also be worth discussing what gets handed out to users that can not authenticate as the same AOR. Some systems that are deployed today allow any user anywhere, say Alice, to subscribe to Bob's reg event so that when Bob comes "on-line", Alice can send a subscribe for presence to Bob. This allows Alice to track when Bob's soft-phone is on or offline and the location of the IP address for Bob. This more or less circumvents all authorization work we did for presence. Now you can argue this is a good or bad thing but the security sections of gruu-reg-event and reg-event that it depends on don't even give a hint to implementers about what to do here or even that the issues exists. I don't think we should get too worked up about hiding information that Alice could discover by sending a probe INVITE to Bob. I do think we should mention this.

I do think there are ways to get this done before GRUU.

IANA Last Call comment:

First action:

Upon approval of this document, the IANA will make the following assignments
in the XML:NS registry located at
http://www.iana.org/assignments/xml-registry/ns.html


ID URI template REF
gruuinfo urn:ietf:params:xml:ns:gruuinfo see_below [RFC-sipping-gruu-reg-
event]

--- start template

URI: The URI for this namespace is urn:ietf:params:xml:ns:gruuinfo

Registrant Contact: IETF, SIPPING working group, ,
Paul Kyzivat

XML:


BEGIN

Namespace for Reg Information GRUU Extension

urn:ietf:params:xml:ns:gruuinfo

See RFCXXXX [[NOTE
TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of
this specification]].

---- end template

Second acation:

Upon approval of this document, the IANA will make the following assignments
in the XML:Schema registry located at
http://www.iana.org/assignments/xml-registry/schema.html
ID URI Filename Reference
gruuinfo urn:ietf:params:xml:schema:gruuinfo file below [RFC-sipping-gruu-
reg-event]


---- file containts





--end file

We understand the above to be the only IANA Actions for this document.

[Ballot comment]
While I'm sympathetic to Cullen's discuss, I think the normative dependency on the GRUU spec is enough here.  If the GRUU spec does something that would cause this to change, it can be brought back to the IESG or the WG without having published the spec.  In the mean time,
the IANA actions (registering the namespace and schema) will be done and available for our
risk-taking early implementation folk.  I don't think anything in the GRUU spec could change those.

In the mean time, there is a lot of real world stuff waiting on GRUU.  If the folks involved are
time constrained, can they be assisted?  If there are other impediments, can they be removed
in an unmarked van to out-of-the-way locations?

[Ballot discuss]
It's really scary to progress this ahead of GRUU. The issues is that it is not clear what GRUU will do with the anonymous property. If some GRUU decides to have the anonymous property, then we need to decide if the security considerations for anonymous GRUU are different than non anonymous GRUUs. It seems likely that due to the stateless implementations of GRUU, this will not be able to report every GRUU but only one non anonymous one.

[Ballot comment]
Section 13.2., paragraph 1:
>    [5]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
>        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
>        Session Initiation Protocol", RFC 3261, June 2002.

  Nit: Unused Reference: '5' is defined on line 458, but not referenced


Section 13.2., paragraph 3:
>    [7]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
>        Agent Capabilities in the Session Initiation Protocol (SIP)",
>        RFC 3840, August 2004.

  Nit: Unused Reference: '7' is defined on line 467, but not referenced

[Ballot comment]
Section 1 paragraph 3 refers to RFC 3860. Is this a misprint for 3680?

The Gen-ART reviewer (Eric Gray) found this sentence in the Abstract quite confusing:

  The Globally Routable User Agent URI (GRUU)
  has been defined for SIP as a URI that is capable of reaching a
  particular contact, however this URI is not present in the format
  defined in RFC 3680.

Perhaps it means:

  According to RFC 3680, a SIP URI known as the Globally Routable User               
  Agent URI (GRUU), capable of reaching a particular contact, is needed.
 
Other review comments:

Security Example? -

In your security section, you make the following statement -

  "The proxy may control access as desired, just as it may for
    the AOR."

In my opinion, it would be good if you could provide either an
explicit example (one or more) of what you mean by "control access
as desired", or provide a more explicit reference to where this is
already described for AOR.

Minor wording issue (NITs) -

Also in the security section, there are a few wording, or
grammar glitches:

  "Security considerations for the registration event package is"

SHOULD BE

  "Security considerations for the registration event package are"

AND

  "its disclosure may arguably be considered of minimal security risk"

is a bit awkward, and I would suggest

  "its disclosure may arguably be considered a minimal security risk"

(When you use "of", you imply that "minimal security risk" is a group
or class that "its disclosure" may belong to, and that is a somewhat
more formal association than I believe exists in this case)

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes, the WG chairs have reviewed and believe the ID is ready.
Mary Barnes is the WG Chair Shepherd for this document.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has been reviewed by WG members, with no concerns about the
depth or breadth of the review.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative. There is one
normative reference that must be progressed prior to publication of this
document, draft-ietf-sip-gruu-xx (currently -06). The -07 version is
anticipated to be the version to be progressed and it is a high priority
to get that completed as there are many dependencies on that document.
There are no normative references which are downward references.

------

Protocol write-up for: draft-ietf-sipping-gruu-reg-event-05
by Mary Barnes, mary.barnes@nortel.com, 28 April 2006

Technical Summary

This document defines an extension to the Session Initiation
Protocol(SIP) Event Package for Registration (RFC 3680) for representing the
Globally Routable Unique URI (GRUU) associated with a Contact. The addition
of GRUU support to the REGISTER message, introduces another element of state
to the registrar. Subscribers to the registration event package will
sometimes have need for the new state.


Working Group Summary

The SIPPING WG supports the development and advancement of this
document.

In the context of this document, there was discussion around
enhancing the Registration Event Package for other information, but that
was deemed beyond the scope of this draft, which is explicitly
intended to extend the Registration Event Package to support GRUUs.


Protocol Quality

This document defines no new protocol elements, but rather uses the
existing extensibility mechanism defined in RFC 3680 to add an
extension to support GRUUs.

This document was thoroughly reviewed by WG chairs and WG members,
including those with XML expertise.

Mary Barnes is the WG chair shepherd. Jon Peterson is the responsible
Area director.