[Ballot comment]
This is a borderline discuss/comment, and deserves to be talked
about in the call.

Based on Christian's and Pasi's reviews and looking at the document
myself, it would be served better by makings its purpose clearer
in the title/abstract/introduction. Are we asking for the domain
allocation with this document or not? Is this a proposal for future
work or all that the IETF needs to do and then someone else is going
to take over the domain part?

Christian Vogt's review:

This document proposes the use of a new DNS domain for Infrastructure ENUM registrations.  The document does not yet define which DNS domain this will be, though, leaving it "to be determined".  If the IESG believes that this amount of content is sufficient to justify the publication of a separate RFC, then this document can go ahead in the publication process, as there are no critical issues IMO.  Alternatively, the document could be held until the new DNS domain is known, so that the new DNS domain could be defined within the document.

[Ballot comment]
Based on Christian's and Pasi's reviews and looking at the document
myself, it would be served better by makings its purpose clearer
in the title/abstract/introduction. Are we asking for the domain
allocation with this document or not? Is this a proposal for future
work or all that the IETF needs to do and then someone else is going
to take over the domain part?

Christian Vogt's review:

This document proposes the use of a new DNS domain for Infrastructure ENUM registrations.  The document does not yet define which DNS domain this will be, though, leaving it "to be determined".  If the IESG believes that this amount of content is sufficient to justify the publication of a separate RFC, then this document can go ahead in the publication process, as there are no critical issues IMO.  Alternatively, the document could be held until the new DNS domain is known, so that the new DNS domain could be defined within the document.

[Ballot comment]
Christian Vogt's review:

This document proposes the use of a new DNS domain for Infrastructure ENUM registrations.  The document does not yet define which DNS domain this will be, though, leaving it "to be determined".  If the IESG believes that this amount of content is sufficient to justify the publication of a separate RFC, then this document can go ahead in the publication process, as there are no critical issues IMO.  Alternatively, the document could be held until the new DNS domain is known, so that the new DNS domain could be defined within the document.

[Ballot comment]
On first reading, I had big difficulties in understanding the document
because it doesn't seem to specify anything (that could be implemented
and used). The title certainly leads the reader to expect a technical
specification describing an alternative to RFC 3761. However, it seems
the document mainly describes the reasoning or motivation of why an
alternative to RFC 3761 would be useful in some circumstances. The
document title should be adjusted accordingly (perhaps "Motivation for
Infrastructure ENUM" or something similar?).

[Ballot comment]
On first reading, I had big difficulties in understanding the document
because it doesn't seem to specify anything (that could be implemented
and used). The title certainly leads the reader to expect a technical
specification describing an alternative to RFC 3761. However, it seems
the document mainly describes the reasoning or motivation of why an alternative to RFC 3761 would be useful in some circumstances. The
document title should be adjusted accordingly (perhaps "Motivation for
Infrastructure ENUM" or something similar?).

[Ballot discuss]
The Gen-ART Review by Elwyn Davies on 19-Jun-2008 has not been
  addressed.  Elwyn provides a couple of semi-editorial issues and
  the IANA considerations are incomplete.  Does this document require
  an IAB statement in line with RFC 3761 regarding the administration
  of the new .arpa sub-domain?

  The Gen-ART Review by Elwyn Davies can be found at:
    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-enum-infrastructure-07-davies.txt

[Ballot discuss]
Disregard my earlier DISCUSS - I was reviewing it based on the status in the document itself, which says "Intended Status: Proposed Standard". The ballot and writeup make it clear that the intent is to go Informational, which makes a lot more sense.

Please add an RFC Editor Note that corrects the Intended Status" in the document.

[Ballot discuss]
Why is this document going for PS? It "defines the use case for
Infrastructure ENUM and proposes its implementation as a
parallel namespace to "e164.arpa" as defined in RFC3761".
That's true, but it doesn't define how Infrastructure ENUM
would operate in detail, and it doesn't even request IANA
to allocate the parallel namespace. I think Informational is
much more appropriate.


** Downref: Normative reference to an Informational draft:
    draft-ietf-enum-infrastructure-enum-reqs (ref. '4')

Wasn't last-called, as far as I can tell. (And is no RFC 5067).

[Ballot discuss]
** Downref: Normative reference to an Informational draft:
    draft-ietf-enum-infrastructure-enum-reqs (ref. '4')

Wasn't last-called, as far as I can tell. (And is no RFC 5067).

Posted related IPR disclosure: Comcast IP Holdings I, LLC's Statement about IPR related to RFC 3953, RFC 4415, RFC 4759, RFC 4769, RFC 4002, RFC 4355, RFC 4414, RFC 4725, RFC 4969, RFC 4979, RFC 5028, RFC 5278, RFC 5346, RFC 5067, RFC 5076, RFC 5105, RFC 2168, RFC 3401, RFC 3402, RF...