(As WG chair)
I have just requested publication of:
http://www.ietf.org/internet-drafts/draft-ietf-sip
-gruu-14.txt
The next stage for submitting comments is therefore the IESG
last call.
The PROTO writeup submitted with the publication request is
as follows.
Please feel free to respond if you consider any of the
information
incorrect.
Regards
Keith
------------------------------------------------------------
------------
---
PROTO writeup for
http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-
14.txt: "Obtaining and Using Globally Routable User
Agent (UA) URIs
(GRUU)
in the Session Initiation Protocol (SIP)"
(1.a) Who is the Document Shepherd for this document?
Has the
Document Shepherd personally reviewed this version
of the
document and, in particular, does he or she
believe this
version is ready for forwarding to the IESG for
publication?
Keith Drage
The document has been reviewed and is ready for forwarding
to IESG for
publication.
(1.b) Has the document had adequate review both from key
WG members
and from key non-WG members? Does the Document
Shepherd have
any concerns about the depth or breadth of the
reviews that
have been performed?
Document history:
* draft-rosenberg-sipping-gruu-reqs-00 was submitted 29th
July
2003 and
expired 27th January 2004.
* draft-rosenberg-sipping-gruu-reqs-01 was submitted 20th
October
2003
and expired 19th April 2004.
* draft-rosenberg-sip-gruu-00 was submitted 20th October
2003 and
expired 19th April 2004.
* draft-rosenberg-sip-gruu-01 was submitted 5th December
2003 and
expired 4th June 2004.
* draft-ietf-sip-gruu-00 was submitted 6th January 2004 and
expired 6th
July 2004.
* draft-ietf-sip-gruu-01 was submitted 15th February 2004
and
expired
15th August 2004.
* draft-ietf-sip-gruu-02 was submitted 2nd July 2004 and
expired
31st
December 2004.
* draft-ietf-sip-gruu-03 was submitted 21st February 2005
and
expired
22nd August 2005.
* draft-ietf-sip-gruu-04 was submitted 14th July 2005 and
expired
15th
January 2006.
* draft-ietf-sip-gruu-05 was submitted 28th September 2005
and
expired
1st April 2006.
* draft-ietf-sip-gruu-06 was submitted 20th October 2005
and
expired 23rd
April 2006.
* draft-ietf-sip-gruu-07 was submitted 6th March 2006 and
expired
7th
September 2006.
* draft-ietf-sip-gruu-08 was submitted 14th June 2006 and
expired
16th
December 2006.
* draft-ietf-sip-gruu-09 was submitted 19th June 2006 and
expired
21st
December 2006.
* draft-ietf-sip-gruu-10 was submitted 31st July 2006 and
expired
1st
February 2007.
* draft-ietf-sip-gruu-11 was submitted 23rd October 2006
and
expired 26th
April 2007.
* draft-ietf-sip-gruu-12 was submitted 5th March 2007 and
expires
6th
September 2007.
* draft-ietf-sip-gruu-13 was submitted 9th April 2007 and
expires
11th
October 2007.
* draft-ietf-sip-gruu-14 was submitted 25th June 2007 and
expires
27th
December 2007.
WGLC was initiated in the SIP WG on draft-ietf-sip-gruu-00
on 13th
January
2004 with comments requested by 28th January 2004. A second
WGLC was
announced on draft-ietf-sip-gruu-03 on 5th July 2004 with
comments
requested
by 17th July 2004. A third WGLC was announced on
draft-ietf-sip-gruu-06
on
26th October 2005 with comments requested by 6th November
2005. A fourth
WGLC
was announced on draft-ietf-sip-gruu-10 on 5th August 2006
with comments
requested by 21st August 2006. A fifth WGLC was announced
on
draft-ietf-sip-
gruu-11 on 13th November 2006 with comments requested by
27th November
2006.
Review was made and comments were received during the last
call
identified
above from: Andrew Allen, Jeroen van Bemmel, Vijay Gurbani,
Paul
Kyzivat,
Xavier Marjo, Eric Rescorla, Robert Sparks, Dale Worley,
(with an
indication
that all had performed a full review of the draft. During
the course of
the
work comments have also been made by at least the following:
Jesus
Javier
Arauz, Francois Audet, Darshan Bildikar, Spencer Dawkins,
John Elwell,
Miguel Garcia, Michael Hammer, Juha Heinanen, Christer
Holmberg, Cullen
Jennings, Erkki Koivusalo, Jiri Kuthan, Scott Lawrence,
Rohan Mahy,
Peter
Musgrave, Kasturi Narayanan, Aki Niemi, Klaus Nieminen, Sean
Olsen,
Michael
Proctor, Adam Roach, Brian Stucker, Dean Willis (in addition
to the
above).
See also the acknowledgements list in the document. See
http://www.softarmor.com/sipwg/reviews/gruu/index.html
for documentation
of
the final extensive review.
There have been key issues in the discussion that have been
resolved to
the
satisfaction of the SIP working group, but which are worth
mentioning
here:
* A grid parameter existed as part of the earlier drafts up
to
draft-
ietf-sip-gruu-10. The GRID parameter was removed from GRUU
in response
to comments received. Instead, loose routing is proposed to
provide
the ability of 'end-instance switching'. The gr URI
parameter
(formerly gruu URI parameter) now takes a value, replacing
opaque as
the server-side 'switch'.
* Up to and including draft-ietf-sip-gruu-10, GRUU did not
provide
any
anonymity functions at all. Indeed, the recommendations for
construction of gruus were such that they would contain the
users AOR.
The point was raised that there were many places, such as
Europe,
where anonymous calls are the norm. This is because privacy
laws
require that caller ID be given out as an opt-in feature,
and the
default is privacy. Conclusion in -11 was that serial
pseudonymity is
provided. A user is given lots of anonymous GRUU, allowing
it to use a
different one for each call. Each remain valid the entire
duration of
the registration.
(1.c) Does the Document Shepherd have concerns that the
document
needs more review from a particular or broader
perspective,
e.g., security, operational complexity, someone
familiar with
AAA, internationalization or XML?
Whilst not specifically a security related document, the
document has
been
reviewed by Eric Rescorla (the security adviser to the SIP
working
group),
and there are no remaining unresolved issues.
(1.d) Does the Document Shepherd have any specific
concerns or
issues with this document that the Responsible
Area Director
and/or the IESG should be aware of? For example,
perhaps he
or she is uncomfortable with certain parts of the
document, or
has concerns whether there really is a need for
it. In any
event, if the WG has discussed those issues and
has indicated
that it still wishes to advance the document,
detail those
concerns here. Has an IPR disclosure related to
this document
been filed? If so, please include a reference to
the
disclosure and summarize the WG discussion and
conclusion on
this issue.
The document defines a new SIP protocol extension for a
particular
purpose
in a form that has been used for many other extensions. The
document
shepherd has no concerns with the document.
There is one patent disclosure against this document from
Microsoft
Corporation. They have indicated they are prepared to
license any rights
on
the basis of "Reasonable and Non-Discriminatory License
to All
Implementers
with Possible Royalty/Fee". This has been brought to
the attention of
the
working group and no concerns were expressed.
(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?
The document has been well discussed and extensively
reviewed by a
significant number of members of the working group (see
answer in 1(b)).
(1.f) Has anyone threatened an appeal or otherwise
indicated extreme
discontent? If so, please summarise the areas of
conflict in
separate email messages to the Responsible Area
Director. (It
should be in a separate email because this
questionnaire is
entered into the ID Tracker.)
None indicated.
(1.g) Has the Document Shepherd personally verified that
the
document satisfies all ID nits? (See
http://www.ietf
.org/ID-Checklist.html and
http://tools.iet
f.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has
the document
met all formal review criteria it needs to, such
as the MIB
Doctor, media type, and URI type reviews? If the
document
does not already indicate its intended status at
the top of
the first page, please indicate the intended
status here.
The document has been reviewed against the guidelines in RFC
4485 and it
is
believed that the document is conformant with those
guidelines.
While the document defines a new SIP option tag, these have
been
performed
as a SIP working group item, and therefore this draft is in
conformance
with
RFC 3427.
The document passes ID-NITS (idnits 2.04.09) with the
exception of the
following:
** There are 4 instances of too long lines in the
document, the
longest
one being 6 characters in excess of 72.
(1.h) Has the document split its references into
normative and
informative? Are there normative references to
documents that
are not ready for advancement or are otherwise in
an unclear
state? If such normative references exist, what
is the
strategy for their completion? Are there
normative references
that are downward references, as described in
[RFC3967]? If
so, list these downward references to support the
Area
Director in the Last Call procedure for them
[RFC3967].
The document has split its references into normative and
informative
references. All the normative references are appropriate
normative
references. All the normative references are published
except:
* reference [13] to draft-ietf-sip-outbound which is still
in the
final
stages of development within the SIP working group.
All the normative references are standards track documents
except:
* reference [4] to RFC 2119 which is a BCP.
* reference [8] to RFC 3968 which is a BCP.
* reference [9] to RFC 3969 which is a BCP.
All the informative references are also published except:
* reference [18] to draft-ietf-sipping-cc-transfer which is
still
in
progress in the SIPPING WG.
* reference [27] to draft-ietf-sipping-gruu-reg-event for
which
publication has been requested by the SIPPING WG.
* reference [28] to draft-rosenberg-sip-ua-loose-route for
which a
charter milestone exists in the SIP WG, and for which this
is a
candidate.
(1.i) Has the Document Shepherd verified that the
document's IANA
Considerations section exists and is consistent
with the body
of the document? If the document specifies
protocol
extensions, are reservations requested in
appropriate IANA
registries? Are the IANA registries clearly
identified? If
the document creates a new registry, does it
define the
proposed initial contents of the registry and an
allocation
procedure for future registrations? Does it
suggest a
reasonable name for the new registry? See
[RFC2434]. If the
document describes an Expert Review process, has
the Document
Shepherd conferred with the Responsible Area
Director so that
the IESG can appoint the needed Expert during IESG
Evaluation?
Section 11.1 of the document registers two new header field
parameters.
This
registration is consistent with RFC 3968 which defines the
registry and
is
also consistent with the current format of the registry.
Section 11.2 of the document registers a new SIP URI
parameter. This
registration is consistent with RFC 3969 which defines the
registry and
is
also consistent with the current format of the registry.
Section 11.3 of the document registers a new option-tag; the
new
option-tag
is defined elsewhere in the document. This registration is
consistent
with
RFC 3261 which defines the registry and is also consistent
with the
current
format of the registry.
(1.j) Has the Document Shepherd verified that sections
of the
document that are written in a formal language,
such as XML
code, BNF rules, MIB definitions, etc., validate
correctly in
an automated checker?
The ABNF within the document passes the checks in Bill
Fenner's ABNF
parsing
web service.
(1.k) The IESG approval announcement includes a
Document
Announcement Write-Up. Please provide such a
Document
Announcement Writeup? Recent examples can be
found in the
"Action" announcements for approved
documents. The approval
announcement contains the following sections:
Technical Summary
Several applications of the Session Initiation Protocol
(SIP) require a
user
agent (UA) to construct and distribute a URI that can be
used by anyone
on
the Internet to route a call to that specific UA instance.
A URI that
routes to a specific UA instance is called a Globally
Routable UA URI
(GRUU).
This document describes an extension to SIP for obtaining a
GRUU from a
registrar and for communicating a GRUU to a peer within a
dialog.
Working Group Summary
The document complements work already performed in RFC 4474
for
authenticated request identity, and forms an integral part
of the
chartered
work in this area. There is consensus in the working group
to publish
this
document.
Document Quality
The document has been well discussed by a significant number
of members
of
the working group.
Personnel
The document shepherd for this document was Keith Drage. The
responsible
Area Director was Cullen Jennings. 'The IANA Expert(s) for
the
registries in
this document are <TO BE ADDED BY THE AD>.
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
