A Telephony Gateway REgistration Protocol (TGREP)
RFC 5140

Note: This ballot was opened for revision 09 and is now closed.

(Ted Hardie) Discuss

Discuss (2007-02-20 for -)
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.

(Cullen Jennings) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2007-02-22 for -)
No email
send info
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.)

(Lars Eggert) No Objection

Comment (2007-02-22 for -)
No email
send info
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.

(Bill Fenner) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2007-02-19)
No email
send info
  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.

(David Kessens) (was Abstain) No Objection

Comment (2007-02-22 for -)
No email
send info
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.

(Chris Newman) (was Discuss) No Objection

Comment (2007-11-22)
No email
send info
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.

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

Comment (2007-02-19 for -)
No email
send info
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.

(David Ward) No Objection

Magnus Westerlund No Objection