[secdir] secdir review of draft-ietf-ospf-rfc3137bis-03
Tom Yu <tlyu@MIT.EDU> Sun, 10 February 2013 19:29 UTC
Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D223521F8794; Sun, 10 Feb 2013 11:29:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w83nco2gpFV4; Sun, 10 Feb 2013 11:29:16 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1548621F878F; Sun, 10 Feb 2013 11:29:15 -0800 (PST)
X-AuditID: 12074423-b7f5b6d000007e03-eb-5117f50bfc5a
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 29.17.32259.B05F7115; Sun, 10 Feb 2013 14:29:15 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r1AJTEBe007780; Sun, 10 Feb 2013 14:29:15 -0500
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1AJTCYM011001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Feb 2013 14:29:14 -0500
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r1AJTCYH014834; Sun, 10 Feb 2013 14:29:12 -0500 (EST)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ospf-rfc3137bis.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Sun, 10 Feb 2013 14:29:11 -0500
Message-ID: <ldvliawnf20.fsf@cathode-dark-space.mit.edu>
Lines: 23
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixG6nrsv9VTzQ4HmPtMWaA1dZLWb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK+PBs3amguvsFTc2P2NtYOxn62Lk 5JAQMJE4PPkSK4QtJnHh3nqwuJDAPkaJX5sUuxi5gOyNjBIzb91khHDOMUks2nmIGaKqi1Hi 82z1LkYODhGBKIlnTVogprCAucSZliQQk01AWuLo4jKQYhYBVYlvW78ygdi8AhYSk04eZgUp 4RHglJi0IBkiLChxcuYTFhCbWUBL4sa/l0wTGPlmIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3 ODkxLy+1SNdMLzezRC81pXQTIzjEXJR3MP45qHSIUYCDUYmHl+GxWKAQa2JZcWXuIUZJDiYl Ud6tn8UDhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwHj8ElONNSaysSi3Kh0lJc7AoifNeS7np LySQnliSmp2aWpBaBJOV4eBQkuBd8wWoUbAoNT21Ii0zpwQhzcTBCTKcB2j4UpDFvMUFibnF mekQ+VOMilLivEdBEgIgiYzSPLheWAp4xSgO9IowrzrICh5g+oDrfgU0mAloMGcO2OCSRISU VAMj98aY4CIW6XSBw8IZavOkf9gHZG8/Fq3OZ2EdqfNYcH2iZcnZpikfj2/u5T1SzTgrwvf8 tdiv89laZt/733Jx7xO5g8x5QbM/R/tYK21b8TXBWyC+RX3d8nbzmY+Vl9olXTj99+6mqddf POU7HHn5stTP+jxJ1v19Vj4FNcl5845mPHS72f9JiaU4I9FQi7moOBEA3h8MYtwCAAA=
Subject: [secdir] secdir review of draft-ietf-ospf-rfc3137bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Feb 2013 19:29:16 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The Security Considerations section of this document states: The technique described in this document does not introduce any new security issues into the OSPF protocol. I believe this is true. Editorial comments: * The acronym LSA appears in this document, but there appears to be no expansion of it in the document. * Section 2 mentions MaxLinkMetric, but the document doesn't define it until Section 3. I looked in vain in the OSPF RFCs until I realized this document newly defines this value. Consider indicating this forward reference in Section 2, e.g. "...set to MaxLinkMetric (defined in Section 3)".