Received changes through RFC Editor sync (changed abstract to 'This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).

The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. This memo provides information for the Internet community.')

Review by Mary Barnes, Gen-ART

It doesn't appear that all the previous Discusses have been adequately addressed.

1.  Previous Comment: Russ Housley: Comment: draft-idr-bgp-implementation-01: The abstract and the introduction state that the the editors make no claim as to the accuracy of the information provided. It would be much better to make a positive statement in the introduction, and say nothing in the abstract. Perhaps something like: The editors have assembled information provided by four implementors: Alcatel, Cisco, Laurel, and NextHop. 

The draft currently states the following, which doesn't seem to match the intent of the suggestion:
"This document provides a survey of the BGP-4 implementation draft-
ietf-idr-bgp4-24.txt.  After a brief summary, each response is listed.
The editors created the draft based on the input given by those contributors responding to  the survey.

The editors did not verify the accuracy of the information submitted by contributor by an exterior means. The contributors are experts with the products they reported on."

I would agree with Russ' suggestion that the whole concept of accuracy of the information be dropped from the abstract (i.e. that second paragraph).  think it's quite clear that the information is survey results (and not from some sort of validated interop event), thus there's no need to even discuss that. 

2. Previous Comment: Margaret Wasserman comment on the following statement:
    For every item listed (259 questions), the respondents indicated
    whether their implementation supports the Functionality/Description
    or not (Y/N) indicated by the RFC2199 [RFC2119] language. Of the 259
    questions in the survey, had two implementations giving an
    affirmative response (two "y" or "y" and "O") 

    Also, what is an "O" response?  This is
    >> explained later, but it would help to explain it before this
    >> section.

3. My previous comment on the past review was that the security considerations section states "This document does not address any security issues."

However, section 3.53 "Security Considerations" does highlight that RFC2385 is a MUST authentication mechanism.  For completeness, it might be useful to highlight in the security considerations section that all the implementations, as reported, did satisfy the security requirements.