Document: draft-ietf-idr-bgp-implement-02.txt
Review: Mary Barnes
Date: 1 december 2004 

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.