Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification
draft-iesg-tcpmd5app-01

-------
draft-ietf-idr-bgp-implementation-01.txt
-------
Section 1 speaks about:
    Section 1.3 provides the quick survey results on inter-operability.
    Section 1.4 provides an inter-operability of the 4 implementations.
but there are no such section 1.3 and 1.4

Actually, the whole numbering of sections needs to be checked I think.

---------- 

Additional Comment from Pekka on 26 Nov 2004:

> Procedural:
> 
> 1)
> 
> The results of the implementation report do not seem to be completely 
> reflected in the document.  For example:
> 
>       b) SHALL NOT - Question 228, regarding section 9.2.2.2
> 
>           Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall
>           not (meaning they did).  One vendor (NextHop) indicated "O"
>           matching the specification.
> 
>         Text:  Routes that have different MULTI_EXIT_DISC attribute
>                SHALL NOT be aggregated.
> 
> ==> one implementation does not fulfill the criteria of two 
> implementations of a feature, which is required prior to advancing to 
> Draft Standard.  Therefore the BGP specification must be changed.
> 
> I have not gone through the implementation report in detail, but it 
> should be carefully reviewed to ensure that features for which there 
> aren't at least two interoperable implementations are removed.
> 
> 
> 2) A normative reference may need to be moved over to Informative:
> 
> Normative References:
>     [RFC2474] Nichols, K., et al.,"Definition of the Differentiated
>     Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474,
>     December 1998
> 
> ==> this is a Proposed Standard, and a Draft Standard cannot 
> reference it normatively.
> 
> Nit:
>   'Working Group Summary' in the announcement needs to be updated.
> 
>

draft-ietf-idr-bgp-implementation-01 and -02 reviewed by Mary Barnes, Gen-ART
draft-ietf-idr-bgp4-24 and -26 reviewed by Brian Carpenter, Gen-ART
draft-ietf-idr-bgp4-mib-14 reviewed by John Loughney, Gen-ART
draft-ietf-idr-bgp-vuln-00 reviewed by Kent Crispin, Gen-ART
                       -01 reviewed by Elwyn Davies, Gen-ART
draft-ietf-idr-bgp-analysis-05 reviewed by Lucy Lynch, Gen-ART
                           -06 reviewed by Elwyn Davies, Gen-ART
draft-ietf-idr-bgp4-experience-protocol-04 reviewed by Mark Allman, Gen-ART
                                       -05 reviewed by Suzanne Woolf, Gen-ART
draft-ietf-idr-bgp-mibagent-survey-02 reviewed by Michael Patton, Gen-ART
draft-iesg-tcpmd5app-00 reviewed by Spencer Dawkins, Gen-ART

I have added reviews as comments on the individual documents, not on the ballots. There are no show-stopper issues identified, but lots of details worthy of notice (still).

  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.

  draft-ietf-idr-bgp4-24:

  Please replace the first sentence of the Security Considerations with:  A
  BGP implementation MUST support the authentication mechanism specified in
  RFC 2385 [RFC2385].

  draft-ietf-idr-bgp4-mib-14:

  The security considerations section contains non-ASCII characters.

  draft-ietf-idr-bgp-vuln-00:

  Nice job.

  It would have helped me if the event tags had been explained before I 
  encountered the first one in section 3.1.1.  Perhaps an additional
  paragraph in section 3 would explain them.

  In the whole document: s/IPSEC/IPsec/

  In section 1, 5th paragraph: s/msut/must/

  The lists in section 1 and section 2 have a different format.  In section 1,
  each item in the list ends with a comma (the "and" appears one entry before
  it should), and in section 2, the list members are full sentences.  I would
  like to see the same style for both lists.

  draft-iesg-tcpmd5app-00:
  
  The security Considerations say:
  >
  > The IESG believes that the variance described here will not affect
  > the security of the Internet.
  >
  I think we should insert "adversely" before "affect."

  draft-ietf-idr-bgp4-experience-protocol-04:

  In section 17.6: s/rationelle/rationale/

  Section 17 includes stuff that is not security relevant, including the
  acknowledgements section.  A minor reorganization is appropriate.

draft-ietf-idr-bgp-mibagent-survey:
The Security Considerations should be something more detailed than "This document does not address any security issues".  If anything, those words are an admission that something more should be written!  A reading of RFC 3552 would explain why I think this could be better, even if there's not much in this document that has a security impact.

draft-ietf-idr-bgp4-experience-protocol:
draft-ietf-idr-bgp-vuln:
References need to be split normative/informative.

In draft-ietf-idr-bgp4-24.txt, an informative reference to RFC1930 seems likely to be
useful, especially since that reserves specific ASNs as private use.

The abstract in draft-ietf-idr-bgp4-mib-14.txt says:

  This memo is an extension to the SNMP MIB.  It obsoletes RFC 1657 and
   RFC 1269..

That doesn't seem quite right.  1657, which this obsoletes, says:

This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects used for managing the
   Border Gateway Protocol Version 4 or lower [1, 2].

An extension to the SMI, maybe, instead of the snmp mib?

In draft-idr-bgp-implementationt:

The abstract states the the editors make no claim as to the accuracy 
of the information provided.  This is repeated in section 1. Not blocking 
but this seems strange in an implementation report.  

In draft-ietf-idr-bgp4-experience-protocol-04.txt , I assume the RFC Editor 
will talk to them about "hot potatoe" spellings in US terms.  This sentence:

Seemingly more intuitive references that fall outside the vegetable
   kingdom refer to cold potatoe routing as "best exit routing", and hot
   potatoe routing as "closest exit routing", though vegetable.

also looked like it might have gotten interrupted in mid-edit.

I note the this document says that folks use IPSEC to protect BGP
in some circumstances, where the TCPmd5 variance says that
IPSec and TLS  are rarely if ever used.  Not blocking, just thought it worth
noting that these don't quite agree.  Hopefully this means folks are looking
at how to augment TCPmd5.