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

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

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.

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.

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.

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.

  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.