Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents
draft-ietf-v6ops-ipv4survey-intro-06

[Ballot comment]
I have completed a careful reading of this and I think it did a good job.  I appreciate the excellent response to my early review which was sent to the v6ops WG chairs - this review stated that the organization of the document focused on Transport documents that would have been deprecated if our policy was not to let old PS's lie, and on documents which had been obsoleted (e.g. RFC 2543).  The new review is very thorough and accurate, now of the right range of documents.

[Ballot comment]
draft-ietf-v6ops-ipv4survey-intro-05:

  In section 1.1, 4th paragraph: s/robudt/robust/

  In section 1.1, 7th paragraph, the document says: 'To do this the Internet
  has sacrificed the underlying "End-to-End" principle.'  I hope that we
  have not 'sacrificed' it entirely.  While I understand the point, I think
  that the sentence is too terse for many readers.  The end-to-end principle
  was waterered-down, not completely sacrificed.

  In section 1.2, 1st paragraph: s/Experimental Standards/Experimental RFCs/


draft-ietf-v6ops-ipv4survey-apps-03:
 
  In section 3.16, the formatting is messed up.  Please fix as follows:

    OLD:

    Also, Section 5.3.2
    (FTP COMMAND ARGUMENTS) contains:


    " ::= ,,,
    ::= , ::= any decimal
    integer 1 through 255"

    NEW:

    Also, Section 5.3.2
    (FTP COMMAND ARGUMENTS) contains:

    " ::= ,,,
    ::= ,
    ::= any decimal integer 1 through 255"

  In Section 5.57, formatting of the quoted text almost impossible to follow.

  In section 7.2.1, what is the value of the expired ID name in the document?

[Ballot discuss]
draft-ietf-v6ops-ipv4survey-sec-03:

  In Section 5.051, there is a problem.  RFC 3280 (and RFC 2459 before it)
  accommodate IPv4 and IPv6 in the ipAddress variant of GeneralName.  In
  fact, Section 4.2.1.11 of RFC 2459 explains name constraint processing
  of IPv6 adressess.  Since RFC 2538 references RFC 2459, I do not belive
  there is any issue to address.

  In Section 5.101, you claim there are not any dependencies on IPv4.
  I expected a discussion that said it handles both IPv4 and IPv6.

[Ballot comment]
Checked the routing doc. There has been a discussion on this doc on the routing area mailing list and the rev seems to reflect the comments.

[Ballot comment]
The Internet document says:

"3.1 RFC 791 Internet Protocol

  This specification defines IPv4 and is replaced by the IPv6
  specifications."

...which I think is a bit strange.  IPv6 does not update or
obsolete IPv4.  It's a different beast altogether.

But, I don't think that this is a serious enough issue to
block the document.

[Ballot comment]
I have only reviewed the security document.  It looks pretty good, but Section 7 doesn't mention 2514.  As far as I know, it's not in use, but with increasing attention to routing security there may be some push to move it to standards track.

[Ballot discuss]
Minor omission: RFC 2192, IMAP URLs, is dependent on RFC 1738 URL
definitions. This should be noted as was done for RFC 2193 and 2384.

Same applies to RFC 2255, LDAP URLs.

Section 5.127 states that RFC 2821 has no IPv4 dependences. In a word, nonsense.
For one thing, RFC 2821 talks at length about using A records; AAAA records are
never mentioned. And for another, RFC 2821 is where MX record handling is specified.
The specific details of how to handle MX records that point at hosts which have a
mixture of A and AAAA records need to be worked out and specified. For example,
suppose you have an MX that points at two hosts A and B with equal preference
values. A only has an A record and B only has an AAAA record. Unless the rules are
carefully specified this could lead to failures for an IPv4-only or an IPv6-only host.

[Ballot comment]
I have only scanned the apps document. There are some inconsistencies - for instance, TIP (RFC 2371) has v4 dependencies, but is not mentioned in section 7, which seems intended to list all the dependencies and what should be done about them, and the title of section 7.2.3 is missing one letter.
Grammar-wise, I think the sentence "This specification only requires a text update, to become IPv6 compliant", which occurs many times in section 7, has a comma too much.
But I think these are minor things. I think the document should go out.