Skip to main content

Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents
RFC 3792

Yes

(Bert Wijnen)

No Objection

(Bill Fenner)
(Ned Freed)
(Thomas Narten)

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

Bert Wijnen Former IESG member
Yes
Yes ()

                            
Alex Zinin Former IESG member
No Objection
No Objection (2003-12-18)
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.
Allison Mankin Former IESG member
(was Discuss) No Objection
No Objection (2003-12-18)
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.
Bill Fenner Former IESG member
No Objection
No Objection ()

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2004-01-05)
The -04 version of the apps doc addresses the specific concerns I had with it.
I think the document should go out.
Margaret Cullen Former IESG member
No Objection
No Objection (2003-12-17)
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.
Ned Freed Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2003-12-18)
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:


    "<host-number> ::= <number>,<number>,<number>,<number>
    <port-number> ::= <number>,<number><number> ::= any decimal
    integer 1 through 255"

    NEW:

    Also, Section 5.3.2
    (FTP COMMAND ARGUMENTS) contains:

    "<host-number> ::= <number>,<number>,<number>,<number>
    <port-number> ::= <number>,<number>
    <number> ::= 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?
Steven Bellovin Former IESG member
No Objection
No Objection (2003-12-16)
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.
Thomas Narten Former IESG member
No Objection
No Objection ()