A Telephony Gateway REgistration Protocol (TGREP)
draft-ietf-iptel-tgrep-09

[Ballot comment]
I am clearing my discuss based on Ted's comment on November 12, 2007.
In my review, I missed that -09 made a one word change addressing Ted's
first issue, and apparently Ted did not consider the other two issues
to be worth blocking the document for an extended period.

[Ballot discuss]
Carrying forward Ted's DISCUSS with no changes.  As far as I can tell
from the diffs, there was no attempt to address the issues Ted raised
in this document revision.

---
In 4.1, the document says:

  The TotalCircuitCapacity attribute is used to reflect the
  administratively provisioned capacity as opposed to the availability
  at a given point in time as provided by the AvailableCircuits
  attribute. Because of its relatively static nature, this attribute
  MAY be propagated beyond the LS that receives it.

  TotalCircuitCapacity represents the total number of active calls at
  any instant. This is not expected to change frequently. This can
  change, for instance, when certain telephony trunks on the gateway
  are taken out of service for maintenance purposes.

The first sentence of the last paragraph seems to run contrary to the
previous statements in this section.  Is it a doc bug?  If not, can it be
explained further?

In 4.2.5, the document says:

  Routes MUST NOT be disseminated with the AvailableCircuits attribute.
  The attribute is meant to reflect capacity at the originating gateway
  only. Its highly dynamic nature makes it inappropriate to disseminate
  in most cases.

While I understand the desire not to constantly update the attribute,
there seem to be conditions under which the document's summarization
strategy is affected by this attribute.  Consider the case where routes
to 4081...4089 are being summarized to a rout to 408.  If circuits are
available to all of these, then this summary will be useful.  If
circuits cease to be available to 4087, though, the aggregate as a
whole might need to be withdrawn.  For a route where
TotalCircuitCapacity and number in use are very close, the aggregation
may be a wrong choice.

I have to say, I also find the summarization of Carrier out of the
announcement somewhat surprising, and that I would have expected it to
be present, even if it meant multiple announcements.  This is partly
because Carrier is a key element for determining cost, an area I
understand the WG did not feel it could tackle here.
---

[Ballot discuss]
The document says:
>
> Implementations of the protocol defined in this document employing
> the ESP header SHALL comply with section 3.1.1 of [13], ...
>
But, [13] is listed as an informative reference.  It should be a
normative reference.

The document says:
>
>  Implementations SHOULD use IKEv2 [7] ...
>
But [7] is not a reference to the IKEv2 specification.
[7] is a reference to the ESP specification.

[Ballot comment]
I changed my ABSTAIN to NoObj as Cullen assured that the story was not
as dire as the write-up mentioned:

As Dan already noticed, the proto write-up says:

I have no concerns on the document itself. It should be noted that
this specification has been around for a while and has been stable for
a long time. It has had very limited implementation and almost no
deployment, which is why the community has not been clamoring for its
publication.

I don't see why we need to spend valuable resources on a document where
the community apparently doesn't believe it is needed.

[Ballot comment]
Section 12.1., paragraph 5:
>    [5] J. Yu, "New Parameters for the "tel" URI to Support Number
>    Portability," Internet Draft, Internet Engineering Task Force, August
>    2006.

  Should refer to RFC4694.

[Ballot comment]
This seems to be a quite sophisticated routing protocol
inlcuding QoS support and intriguing features such as
success-dependent routing:

4.3.2. Route Origination and CallSuccess

  Routes MAY be originated containing the CallSuccess attribute. This
  attribute is expected to get statistically significant with passage
  of time as more calls are attempted.  It is RECOMMENDED that
  sufficiently large windows be used to provide a useful aggregated
  statistic.

I'd like to see something more scientific than "sufficiently"
and "useful" for this recommendation to actually help an implementer.

Has the protocol been analyzed like any other routing protocol?
(For example, I found nothing about loop prevention.)

[Ballot comment]
As Dan already noticed, the proto write-up says:

I have no concerns on the document itself. It should be noted that
this specification has been around for a while and has been stable for
a long time. It has had very limited implementation and almost no
deployment, which is why the community has not been clamoring for its
publication.

I don't see why we need to spend valuable resources on a document where
the community apparently doesn't believe it is needed.

[Ballot discuss]
In 4.1, the document says:

  The TotalCircuitCapacity attribute is used to reflect the
  administratively provisioned capacity as opposed to the availability
  at a given point in time as provided by the AvailableCircuits
  attribute. Because of its relatively static nature, this attribute
  MAY be propagated beyond the LS that receives it.

  TotalCircuitCapacity represents the total number of active calls at
  any instant. This is not expected to change frequently. This can
  change, for instance, when certain telephony trunks on the gateway
  are taken out of service for maintenance purposes.

The first sentence of the last paragraph seems to run contrary to the
previous statements in this section.  Is it a doc bug?  If not, can it be
explained further?

In 4.2.5, the document says:

  Routes MUST NOT be disseminated with the AvailableCircuits attribute.
  The attribute is meant to reflect capacity at the originating gateway
  only. Its highly dynamic nature makes it inappropriate to disseminate
  in most cases.

While I understand the desire not to constantly update the attribute, there
seem to be conditions under which the document's summarization strategy
is affected by this attribute.  Consider the case where routes to 4081...4089
are being summarized to a rout to 408.  If circuits are available to all of
these, then this summary will be useful.  If circuits cease to be available to
4087, though, the aggregate as a whole might need to be withdrawn.  For
a route where TotalCircuitCapacity and number in use are very close, the
aggregation may be a wrong choice.

I have to say, I also find the summarization of Carrier out of the announcement
somewhat surprising, and that I would have expected it to be present, even if
it meant multiple announcements.  This is partly because Carrier is a key element
for determining cost, an area I understand the WG did not feel it could tackle here.

[Ballot comment]
I do not understand the top line of digits in Figure 2.  In some
  places, there is a space between each digit.  In some places, the
  digits appear above the lines separating the fields, but in other
  places there is a '|' character as a place holder.

  The top two lines of digits in Figures 3 and 4 would make more sense
  to me if they were shifted one space to the right.  As they appear
  now, the digits appear above the lines separating the files, not
  above the content of the fields.

  In Figure 5, the plus sign should appear between the digits
  representing 23 and 24, not under the digit representing 23.

  Figure 6 is missing a caption.

  I do not understand the lines on the right side of Figures 6 and 7.
  The lines to not connect, so it is not clear to me how they connect
  with session management.

[Ballot discuss]
The IPsec references are quite out of date.  Please update them as:

    [3] RFC 2401 --> RFC 4301
    [6] RFC 2402 --> RFC 4302
    [7] RFC 2406 --> RFC 4303
    [8] RFC 2409 --> RFC 4306

  The Security Considerations say:
  >
  > Implementations of the protocol defined in this document employing
  > the ESP header SHALL comply with section 5 of [7], which defines a
  > minimum set of algorithms for integrity checking and encryption.
  > Similarly, implementations employing the AH header SHALL comply with
  > section 5 of [6], which defines a minimum set of algorithms for
  > integrity checking using manual keys.
  >
  The algorithms are no longer specified in the AH and ESP documents.
  Please see RFC 4305 and draft-manral-ipsec-rfc4305-bis-errata-03.txt.
  Which of these protocols is mandatory to implement AH or ESP?
  It appears that support for AH requires support for manual keys, but
  there is no guidance about key management when ESP is used.  Please
  review RFC 4107, which strongly encourages automated key management.

  The Security Considerations say:
  >
  > Implementations SHOULD use IKE [8] to permit more robust keying
  > options.  Implementations employing IKE SHOULD support authentication
  > with RSA signatures and RSA public key encryption.
  >
  Please change IKE to IKEv2.  This algorithm guidance is not sufficient
  to achieve interoperability.  Please see RFC 4307 for information about
  IKEv2 algorithms.  The MUST and MUST- algorithms in this document are
  probably the ones that you want to identify.

[Ballot comment]
1. With the PROTO write-up making the following statements:

'It should be noted that
this specification has been around for a while and has been stable for
a long time. It has had very limited implementation and almost no
deployment, which is why the community has not been clamoring for its
publication.'

' Iptel is a small group overall, and
an even smaller part of it has had an interest in this work.'

I am wondering if there is a need for this document to become a Proposed Standard.

2. The document is missing any operational and manageability considerations. Is any initial configuration required for the TGREP entities? How much traffic is TGREP supposed to generate in a network? Are there any recovery or notifications means in place if something goes wrong?

3. Running idnits points to a number of references issues:

  Checking references for intended status: Proposed Standard

  - Looks like a reference, but probably isn't: 'RFCXXXX' on line 1140 (?)
    '|  5          Carrier                        [RFCXXXX]...'

  - Unused Reference: '11' is defined on line 1288, but not referenced
    '[11] J. Rosenberg and H. Schulzrinne, "A framework for telephony routi...'

  - Unused Reference: '12' is defined on line 1292, but not referenced
    '[12] ITU-T List of ITU Carrier Codes (published periodically in the IT...'

  - Unused Reference: '13' is defined on line 1295, but not referenced
    '[13] J. Rosenberg, "Requirements for Gateway Registration," Internet D...'

  - Unused Reference: '14' is defined on line 1298, but not referenced
    '[14] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service locatio...'

  * Obsolete Normative Reference: RFC 2401 (ref. '3')
  - Possible downref: Non-RFC Normative Reference: ref. '4'
  - Possible downref: Non-RFC Normative Reference: ref. '5'
  * Obsolete Normative Reference: RFC 2402 (ref. '6')
  * Obsolete Normative Reference: RFC 2406 (ref. '7')
  * Obsolete Normative Reference: RFC 2409 (ref. '8')
  * Obsolete Normative Reference: RFC 2234 (ref. '9')

Also idnits points to the lack of Intended Status in the header and lack of RFC 4748 boilerplate.


4. Section 2 - if there is a need for a reference for SIP Proxy there should be one for a H.323 gatekeeper as well. In general it may be better to refer the terminology to RFC 2871 wherever possible.

5. A bracket never closes in 'there are two components, the "Ingress LS"
  (a.k.a. "TGREP Receiver" and the "Egress LS".'

6. LS should be expanded at first occurence.

7. TGREP Sender and TGREP Receiver are sometimes capitalized, sometimes not. I suggest to do it in a consistent manner.

8. The LS Architecture figure seems to be mixed-up, figure 6 seems to be missing, figure 7 duplicated.

IANA Last Call Comments:

IANA has a question about the IANA actions related to
this document.

------

Upon approval of this document, IANA understands that
there are three actions to be completed.

First, in the Telephony Routing over IP (TRIP) Parameters
registry located at:

http://www.iana.org/assignments/trip-parameters

in the TRIP Attributes subregistry the following new
codes will be added:

Code Attribute
---- ---------
13 TotalCircuitCapacity
14 AvailableCircuits
15 CallSuccess
16 E.164 Prefix
17 Pentadecimal Routing Number Prefix
18 Decimal Routing Number Prefix
19 TrunkGroup
19 Carrier

IANA has a question about the attribute codes listed in
section 9.1 of the document. IANA notes that TrunkGroup
and Carrier have the same code specified.

Is this an oversight or should they indeed have the same
attribute code?

Second, also in the Telephony Routing over IP (TRIP)
Parameters registry located at:

http://www.iana.org/assignments/trip-parameters

in the subregistry called TRIP Address Families two new
values are to be registered.

Code Address Family
----------- ---------------------------
TBD TrunkGroup
TBD Carrier

IANA notes that the document makes suggestions for the
values for these Address Family Codes ( 4 and 5 respectively ).

IANA understands that these are the only actions
required upon approval of 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 had review from several key members over the years,
including Vijay Gurbani, Bob Penfield, and Cullen Jennings. It has had
contribution from many in the group as well that have participated in
mailing list discussions. I do not have any concerns over the breadth
or depth of reviews.

The document has not had any review from experts outside of the WG.


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.)?

It
might benefit from comment from routing experts; however, the draft
upon which TGREP is based (TRIP) was reviewed by the routing community
when it was first published. Consequently, additional reviews seem
less important at this time.


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.

I have no concerns on the document itself. It should be noted that
this specification has been around for a while and has been stable for
a long time. It has had very limited implementation and almost no
deployment, which is why the community has not been clamoring for its
publication.

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. Iptel is a small group overall, and
an even smaller part of it has had an interest in this work. Most of
the group is interested in the tel URI and related documents, which
have seen more widespread adoption and implementation. However,
amongst the participants that have taken an interest in it over the
years, the document has WG consensus.

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?

There is one normative reference to an I-D, the trunk group
specification, which is currently under consideration by IESG.

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

Telephony Gateway Registration Protocol (TGREP) is a companion
protocol to Telephony Routing over IP (TRIP, RFC 3219). TRIP itself is
a variation on BGP used to distribute routes to telephony gateways
between administrative domains. TGREP is an intra-domain protocol that
allows a gateway to feed its routes to a TRIP entity, which can then
distribute them inter-domain via TRIP. TGREP is identical to TRIP
itself in terms of state machinery and protocol messages. However, it
adds additional processing steps not needed in TRIP, and adds
attributes that are unique to intra-domain route propagation (such as
available capacity).

* Working Group Summary

The draft is a charter item of the IP Telephony (iptel) working group,
and is targeted for Proposed Standard. Work began in March of
2000. The document was adopted as a working group item in December
2002. Work progressed steadily over the next few years. A first WGLC
was issued in March of 2004 and again in Feburary of 2006.

* Protocol Quality

The specification has been reviewed by many participants over the
years, most recently by the chair, who did a detailed review of the
document.