The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry
RFC 5341

[Ballot comment]
Section 3., paragraph 1:
>    The tel URI parameters and values for these parameters MUST be
>    documented in a RFC or other permanent and readily available public
>    specification in order to be registered by IANA.

  Section 4.2 defines the polocy as "Specification Required, Designated
  Expert" from RFC2434 - could you use that same term here?


Section 4.2., paragraph 1:
>    As per the terminology in [6] and actions accorded to such a role,
>    the registration policy for tel URI parameters shall be
>    "Specification Required, Designated Expert" (the former implicitly
>    implies the latter.)

  Why does "Specification Required" imply "Designated Expert"? That's
  not the case IMO.

[Ballot discuss]
Section 3., paragraph 3:
>    RFCs defining tel URI parameters or parameter values MUST register
>    them with IANA as described below.

  Discuss-discuss: By "below", I assume you mean the IANA Considerations
  section. But what about tel URI parameters that aren't specified via
  RFCs (the policy is "Specification Required, Designated Expert",
  right?) Don't those also need to follow those guidelines?

[Ballot comment]
Who is proposed as the designated expert for this registry?

I strongly concur with all of Pasi's comments and recommend the authors
consider them seriously.  As a suggestion for clarity: instead of a
yes/no for "predefined value", have a three-state "value-type" column
that says one of: no-value, constrained, unconstrained.  BTW, it appears
there are no "unconstrained" parameters defined -- if that's likely to
continue in the future, perhaps it's simpler to just omit the column
altogether.

[Ballot comment]
The distinction between URI parameters that accept a set of predefined
values vs. parameters that can accept any value would benefit from
some clarification. Originally, I thought "predefined values" meant an
enumeration (like "isub-encoding"), but later in the document, things
like domain names, URIs, or strings of digits are also counted as "set
of predefined values".

Also, apparently there are currently no parameters in the "can accept
any value" category -- so perhaps instead of talking about "predefined
values", we could just classify parameters as "has a value" vs.  "does
not have a value"?

The document probably should have "Updates: RFC 3966" on cover page
since it changes the procedures defined in RFC 3966 (which says that
"New mandatory parameters must be described in a standards-track RFC,
but an informational RFC is sufficient for optional parameters.")

Should the parameters used in obsolete RFC 2806 be marked as
"reserved" in this registry? ('tsp' and 'postd')

IANA Last Call comments:

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD

Registry Name: tel URI registry
Reference: [RFC-ietf-iptel-tel-reg-05.txt]
Registration Procedures: Expert Review with Specification Required

Registry:
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
isub Yes [RFC 3966]
isub-encoding Yes [RFC 4715]
ext Yes [RFC 3966]
phone-context Yes [RFC 3966]
enumdi No [RFC 4759]
npdi No [RFC 4694]
rn Yes [RFC 4694]
rn-context Yes [RFC 4694]
cic Yes [RFC 4694]
cic-context Yes [RFC 4694]
tgrp Yes [RFC 4904]
trunk-context Yes [RFC 4904]

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

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 chair (Jonathan Rosenberg) has personally reviewed this
version of the document. The chair believes the I-D is ready to
forward for publication. The sole chair is the shepherd.

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 not had a deep review from WG members besides the
chair, who conducted an extremely detailed review. This is a very
simple draft that is largely procedural. WG discussion around this
draft had active participation from many key participants,
including the authors of the various tel URI extensions whose
parameters are registered by this draft. Given the simple nature of
the document, the level of involvement on the list, and the good
expertise of the chair on IANA procedures, I have no concern over
either the depth or breadth of the reviews that have been performed.

The document has not had a review from outside of the working group.

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. The document needs reviews from experts in telephony and IANA
procedures, and it has had those.

  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.

There was some discussion about whether this document was really
needed. It is possible to go too far in the creation of IANA
registries, creating unneccesary work. However, a poll was taken and
there was consensus that this was a good idea.

  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?

Working group consensus is good. The draft was originally posted in
October 2005. After that point, there was discussion around its need,
and conclusion that it was needed. It was made a WG item in December of
2005 and then underwent several revisions based on comments and
inputs. The group is small, but there was participation by all of the
active members.

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?

Yes.

        Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?

No. There are references to I-Ds, but two have already been published
as an RFC, and the other is currently under IESG evaluation.

        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]?

No.

        Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.


  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

This document is a procedural specification that defines a new IANA
registry for parameters to the tel URI (RFC 3966). RFC 3966 allowed
extensions to the tel URI through new URI parameters, or new values to
previously defined parameters. However, it created no registry for
such parameters. Several extensions have since been defined for the
tel URI, including trunk groups (draft-ietf-iptel-trunk-group), number
portability (RFC 4694) and ENUM dip indicator (RFC 4759). Additional
drafts have appeared proposing further extensions. To ensure that
there are no overlap of values, and to provide a simple place for
developers to find the meaning of these new parameters, this document
defines an IANA registry and populates it with values from the
existing specifications that pre-date the creation of the registry.

        *    Working Group Summary

The draft is a charter item of the IP Telephony (iptel) working group,
and is targeted for Proposed Standard. It updates the tel URI
specification (RFC 3966) as well as several tel URI extensions. It was
adopted as a working group item in December 2005 and discussed on the
mailing list since its creation.

        *    Protocol Quality

The specification has received discussion by all of the authors of the
specifications whose parameters are registered. It has also received
review by an expert in IANA registry procedures.