Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols
draft-ietf-opsec-igp-crypto-requirements-04

INTRODUCTION, paragraph 3:
>            Cryptographic Authentication Algorithm Implementation
>                    Best Practices for Routing Protocols

  It is odd to see the term "best practices" in the title of a document
  that is not actually targeted as a BCP. Plus, the contents of the
  document aren't best practices, they are rather suggestions to
  implementors to avoid potential future interoperability issues.
  Suggest to reword the title.


Section 4.1, paragraph 4:
>    all conformant implentations MUST support this.

  Nit: s/implentations/implementations/


Section 11.1, paragraph 2:
>    [ISO]       "Intermediate system to Intermediate system routeing

  Nit: s/routeing/routing/

For consistency, add citations to the defining RFCs that define the use of 
HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 in the various routing protocols; e.g.,

   Implementations may start providing support for HMAC-SHA-256/HMAC-
   SHA-384/HMAC-SHA-512 [RFC5310] as these algorithms may be necessary in the 
   future.

at the end of section 3.2

  Two spellings are used: "Null authentication" and "NULL
  authentication".  Please pick one. 

  In the Introduction, I think it is better to talk about the overall
  technique before particular algorithms like MD5.  Below I suggest
  rewording for 3rd and 4th and 5th paragrahs of the introduction.
  
    In a cryptographic authentication scheme, routers share a secret
    key which is used to generate a message authentication code for
    each of the protocol packets.  Today, message authentication codes
    often use a keyed MD5 digest.  The recent escalating series of
    attacks on MD5 raise concerns about its remaining useful lifetime.
    These attacks may not necessarily result in direct vulnerabilities
    for keyed MD5 digests as message authentication codes because the
    colliding message may not correspond to a syntactically correct
    protocol packet.  There is a however a need felt to deprecate MD5
    in favor of stronger message authentication code algorithms.

1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract.  Move them to the Introduction.

2) Section 2 and the "conventions used in this document" section are the same.  Keep the 2nd (that's where the RFC editor will put it).

3) It's probably worth adding a reference to SHS (for the SHA family):

[SHS]  National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.
 
4) Sec 6: Is there something missing from the end of this sentence maybe "packet": 

   If the Address Family Identifier of the 
   first (and only the first) entry in the message is 0xFFFF, then the 
   remainder of the entry contains the authentication.

5) Sec 3.1: r/scheme as provides no/scheme as it provides no 

I support Sean's discuss issue #4