BGP-4 Implementation Report
RFC 4276

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

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.