From acee.lindem@ericsson.com Sat Jan 5 12:03:55 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B489221F84D0; Sat, 5 Jan 2013 12:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qZ44N1Fbp3xY; Sat, 5 Jan 2013 12:03:54 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C38EE21F84C0; Sat, 5 Jan 2013 12:03:54 -0800 (PST) Received: from EUSAAHC002.ericsson.se ([147.117.188.78]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r05KHw2F001199; Sat, 5 Jan 2013 14:18:00 -0600 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Sat, 5 Jan 2013 15:03:44 -0500 From: Acee Lindem To: Adrian Farrel , Stewart Bryant Thread-Topic: Request for Publication of "OSPFv3 Instance ID Registry Update" - draft-ietf-ospf-ospfv3-iid-registry-update-00.txt Thread-Index: AQHN63/E9LWy+7aFlkCnfg0lPBErRA== Date: Sat, 5 Jan 2013 20:03:44 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47086928@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/signed; boundary="Apple-Mail-22--995581270"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: OSPF List , IETF Secretariat Subject: [OSPF] Request for Publication of "OSPFv3 Instance ID Registry Update" - draft-ietf-ospf-ospfv3-iid-registry-update-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 20:03:55 -0000 --Apple-Mail-22--995581270 Content-Type: multipart/mixed; boundary=Apple-Mail-21--995581293 --Apple-Mail-21--995581293 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Adrian, Stewart,=20 The OSPF WG desires publication of the subject draft. The shepherding = write-up is attached.=20 Thanks, Acee=20 --Apple-Mail-21--995581293 Content-Disposition: attachment; filename=ospf-wg-ospfv3-iid-registry-update-writeup.txt Content-Type: text/plain; name="ospf-wg-ospfv3-iid-registry-update-writeup.txt" Content-Transfer-Encoding: quoted-printable (1) What type of RFC is being requested (BCP, Proposed Standard,=0D Internet Standard, Informational, Experimental, or Historic)? Why=0D is this the proper type of RFC? Is this type of RFC indicated in the=0D title page header?=0D =0D Proposed Standard=0D =0D (2) The IESG approval announcement includes a Document Announcement=0D Write-Up. Please provide such a Document Announcement Write-Up. Recent=0D= examples can be found in the "Action" announcements for approved=0D documents. The approval announcement contains the following sections:=0D =0D Technical Summary =0D =0D This draft modifies the "OSPFv3 Instand ID Address Family Values"=0D= IANA registry to have IDs 192-255 designated for "Private Use" =0D as described in RFC 5226. =0D =0D Working Group Summary =0D =0D The new range is for applications that do not justify a standards =0D= track OSPFv3 Instance ID allocation. An example would be "Routing =0D= for IPv4-embedded IPv6 Packets" -=0D draft-ietf-ospf-ipv4-embedded-ipv6-routing-05.txt. =0D =0D =0D Document Quality =0D =0D The document is short and to the point. It satisfies its =0D intended purpose. =0D =0D Personnel=0D =0D Acee Lindem is the document shepherd and Stewart Bryant is the =0D responsible AD. =0D =0D =0D (3) Briefly describe the review of this document that was performed by=0D= the Document Shepherd. If this version of the document is not ready=0D for publication, please explain why the document is being forwarded to=0D= the IESG.=0D =0D The document resulted from discussions regarding the "Routing=0D for IPv4-embedded IPv6 Packets" and was covered in the WG document=0D= status in Vancounver. The document was reviewed by Acee Lindem =0D and Stewart Bryant. Others may have reviewed it without comment. =0D =0D (4) Does the document Shepherd have any concerns about the depth or=0D breadth of the reviews that have been performed? =0D =0D No. =0D =0D (5) Do portions of the document need review from a particular or from=0D broader perspective, e.g., security, operational complexity, AAA, DNS,=0D= DHCP, XML, or internationalization? If so, describe the review that=0D took place.=0D =0D No.=0D =0D (6) Describe any specific concerns or issues that the Document Shepherd=0D= has with this document that the Responsible Area Director and/or the=0D IESG should be aware of? For example, perhaps he or she is uncomfortable=0D= with certain parts of the document, or has concerns whether there really=0D= is a need for it. In any event, if the interested community has=0D discussed those issues and has indicated that it still wishes to advance=0D= the document, detail those concerns here.=0D =0D None. =0D =0D (7) Has each author confirmed that any and all appropriate IPR=0D disclosures required for full conformance with the provisions of BCP 78=0D= and BCP 79 have already been filed. If not, explain why.=0D =0D Yes. =0D =0D (8) Has an IPR disclosure been filed that references this document?=0D If so, summarize any discussion and conclusion regarding the IPR=0D disclosures.=0D =0D No. =0D =0D (9) How solid is the consensus of the interested community behind this=0D= document? Does it represent the strong concurrence of a few individuals,=0D= with others being silent, or does the interested community as a whole=0D understand and agree with it? =0D =0D There is no opposition to the draft.=0D =0D (10) Has anyone threatened an appeal or otherwise indicated extreme =0D discontent? If so, please summarise the areas of conflict in separate=0D email messages to the Responsible Area Director. (It should be in a=0D separate email because this questionnaire is publicly available.) =0D =0D No. =0D =0D (11) Identify any ID nits the Document Shepherd has found in this=0D document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts=0D= Checklist). Boilerplate checks are not enough; this check needs to be=0D thorough.=0D =0D All idnits errors and warnings have been resolved.=0D =0D (12) Describe how the document meets any required formal review=0D criteria, such as the MIB Doctor, media type, and URI type reviews.=0D =0D Not applicable. =0D =0D (13) Have all references within this document been identified as=0D either normative or informative?=0D =0D Yes.=0D =0D (14) Are there normative references to documents that are not ready for=0D= advancement or are otherwise in an unclear state? If such normative=0D references exist, what is the plan for their completion?=0D =0D No. =0D =0D (15) Are there downward normative references references (see RFC 3967)?=0D= If so, list these downward references to support the Area Director in=0D the Last Call procedure.=0D =0D No. =0D =0D (16) Will publication of this document change the status of any existing=0D= RFCs? Are those RFCs listed on the title page header, listed in the=0D abstract, and discussed in the introduction? If the RFCs are not listed=0D= in the Abstract and Introduction, explain why, and point to the part of=0D= the document where the relationship of this document to the other RFCs=0D= is discussed. If this information is not in the document, explain why=0D the interested community considers it unnecessary.=0D =0D No. =0D =0D (17) Describe the Document Shepherd's review of the IANA considerations=0D= section, especially with regard to its consistency with the body of the=0D= document. Confirm that all protocol extensions that the document makes=0D= are associated with the appropriate reservations in IANA registries.=0D Confirm that any referenced IANA registries have been clearly=0D identified. Confirm that newly created IANA registries include a=0D detailed specification of the initial contents for the registry, that=0D allocations procedures for future registrations are defined, and a=0D reasonable name for the new registry has been suggested (see RFC 5226).=0D= =0D The document is solely devoted to a single IANA action. The=0D action is clear. =0D =0D (18) List any new IANA registries that require Expert Review for future=0D= allocations. Provide any public guidance that the IESG would find=0D useful in selecting the IANA Experts for these new registries.=0D =0D None. =0D =0D (19) Describe reviews and automated checks performed by to validate=0D sections of the document written in a formal language, such as XML code,=0D= BNF rules, MIB definitions, etc.=0D =0D Not Applicable. =0D =0D =0D --Apple-Mail-21--995581293-- --Apple-Mail-22--995581270 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDEwNTIwMDM0NFowIwYJKoZI hvcNAQkEMRYEFOOLKyHuOYC16cC+ZshBxbkwXFDcMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgF+KXDcfGSUwiUJoOQmuC5aKSssqeGSrx7LXuoDC8a6XQ1P9Z1LSRNgjRHKL92Lq uTJjNYZlQa7/XqlDsvS0FmMQx7ZmZ9J2TgFoT9lf3hZBxCOnvRO6hLsdZrpKZWkQH1S7EkeWtUFq 7wmnx5mnW+y0L0wXxGa+wmQT3G9h+REmAAAAAAAA --Apple-Mail-22--995581270-- From iesg-secretary@ietf.org Thu Jan 10 08:18:22 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52821F8956; Thu, 10 Jan 2013 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, 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 ytKe6r+y7A4Q; Thu, 10 Jan 2013 08:18:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7621F8936; Thu, 10 Jan 2013 08:18:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130110161821.32592.26982.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2013 08:18:21 -0800 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (OSPFv3 Instance ID Registry Update) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 16:18:22 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPFv3 Instance ID Registry Update' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-iid-registry-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-iid-registry-update/ballot/ No IPR declarations have been submitted directly on this I-D. From wwwrun@rfc-editor.org Sat Jan 12 18:50:16 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7446821F8992 for ; Sat, 12 Jan 2013 18:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 U++nXbHUP5Kw for ; Sat, 12 Jan 2013 18:50:15 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id AFB3821F89E1 for ; Sat, 12 Jan 2013 18:50:15 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 797A6622E9; Sat, 12 Jan 2013 18:39:28 -0800 (PST) To: jmoy@casc.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20130113023928.797A6622E9@rfc-editor.org> Date: Sat, 12 Jan 2013 18:39:28 -0800 (PST) Cc: ospf@ietf.org, davidjet@gmail.com, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC2328 (3452) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 02:50:16 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3452 -------------------------------------- Type: Editorial Reported by: David Jet Section: 11 Original Text ------------- Multiple LSAs may reference the destination, however a tie-breaking scheme always reduces the choice to a single LSA. Corrected Text -------------- Multiple LSAs may reference the same destination, however a tie-breaking scheme always reduces the choice to a single LSA. Notes ----- I think should add the "same" to describe it more clearly. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From acee.lindem@ericsson.com Sun Jan 13 04:04:54 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9460221F86C2 for ; Sun, 13 Jan 2013 04:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 HjErTkWpmDFA for ; Sun, 13 Jan 2013 04:04:53 -0800 (PST) Received: from usevmg20.ericsson.net (unknown [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B021A21F86C1 for ; Sun, 13 Jan 2013 04:04:53 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-2b-50f2a2e49ca9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 20.44.31450.4E2A2F05; Sun, 13 Jan 2013 13:04:53 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Sun, 13 Jan 2013 07:04:51 -0500 From: Acee Lindem To: RFC Errata System Thread-Topic: [Editorial Errata Reported] RFC2328 (3452) Thread-Index: AQHN8Ti7/dPt6KyfBUewD+AtEIHXLZhHfb4A Date: Sun, 13 Jan 2013 12:04:51 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4709BDC8@eusaamb101.ericsson.se> References: <20130113023928.797A6622E9@rfc-editor.org> In-Reply-To: <20130113023928.797A6622E9@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <9252BB71B2E20842875A61FAFBBD9551@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXSPn+7TRZ8CDF7OZbT40XOD2eLwwVls Fv0bX7BZTJwrY9Fy7x67RdP+r2wW557OYXRg9/i3ehuzx5TfG1k9ds66y+6xZMlPJo8Vm1cy ejS0HWMNYIvisklJzcksSy3St0vgyti0YjtbwVq+iuP929kaGCdzdzFyckgImEhMuLWJGcIW k7hwbz1bFyMXh5DAEUaJA7PvsUI4yxklpnccYgWpYhPQkXj+6B9Yh4iAocTBRW/ZQYqYBX4x SnycfxksISxgLtH0/h4jRJGFxPqONWwQtpHEjJnbmEBsFgFViTXHm8HqeQW8JQ7sgLCFBMwk vh+bDbaME2jOtP7v7CA2I9B530+tAetlFhCXuPVkPhPE2QISS/ach3pBVOLl43+sELayxJIn +1kg6nUkFuz+xAZhW0tsf32SHcLWlli28DXUDYISJ2c+YZnAKD4LyYpZSNpnIWmfhaR9FpL2 BYysqxg5SotTy3LTjQw2MQIj9pgEm+4Oxj0vLQ8xSnOwKInzBrleCBASSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAWN698Ni0pfyOZ6qPuy94l1j34xnfXdPuFQdNl5/ZeXI+A8O1xwmNrO0P 259eOH/jdFV0yOcz/0+83iMokfF29uI3Wrl2E5Tvcjbt62spfbw04+kJd50TsduqtFUnHLhv o3Ns1d99StKqb2wVeJ8GRXdXOPN/XrLSls9X+m7r/u2unxQCRLgOHlZiKc5INNRiLipOBADD YesrpgIAAA== Cc: "" , "" , "" Subject: Re: [OSPF] [Editorial Errata Reported] RFC2328 (3452) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 12:04:54 -0000 All,=20 Since section is 11 is describing the contents of a single routing table en= try, there is only one destination and adding "same" would be redundant. He= nce, I recommend that this errata be rejected.=20 Thanks, Acee=20 On Jan 12, 2013, at 9:39 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC2328, > "OSPF Version 2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3452 >=20 > -------------------------------------- > Type: Editorial > Reported by: David Jet >=20 > Section: 11 >=20 > Original Text > ------------- > Multiple LSAs may reference the destination, however a tie-breaking schem= e always reduces the choice to a single LSA.=20 >=20 > Corrected Text > -------------- > Multiple LSAs may reference the same destination, however a tie-breaking = scheme always reduces the choice to a single LSA.=20 >=20 > Notes > ----- > I think should add the "same" to describe it more clearly. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG From stbryant@cisco.com Mon Jan 14 02:55:20 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAF121F8703 for ; Mon, 14 Jan 2013 02:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.559 X-Spam-Level: X-Spam-Status: No, score=-110.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 woH+ZLZwuQvG for ; Mon, 14 Jan 2013 02:55:19 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8F27F21F8700 for ; Mon, 14 Jan 2013 02:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2148; q=dns/txt; s=iport; t=1358160919; x=1359370519; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ICaVfAXPfsZrJIT1zwWqE0zuyFAcQkdEGqZaWPFG9Fo=; b=Ml6nzowMF2ooO6LsoE2cMYV8qvAM6mjohcSz17Gbk5NK31c3uvTx0w6u egOWwGy6oKOUKq/lQ2Al/NBxu/Qsin8Oql3SfnGJUpq/wTpV/+YIq9hYF 29/lHFdD5ZnzlnO9y8m6YttdU/SeDsLZNtUbIjiZVn9Vqt+vi5XyGn4n8 4=; X-IronPort-AV: E=Sophos;i="4.84,466,1355097600"; d="scan'208";a="79727752" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Jan 2013 10:55:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0EAtI6T031787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 10:55:18 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r0EAtFIh017174; Mon, 14 Jan 2013 10:55:16 GMT Message-ID: <50F3E413.1090406@cisco.com> Date: Mon, 14 Jan 2013 10:55:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Acee Lindem References: <20130113023928.797A6622E9@rfc-editor.org> <94A203EA12AECE4BA92D42DBFFE0AE4709BDC8@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4709BDC8@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "" , "" Subject: Re: [OSPF] [Editorial Errata Reported] RFC2328 (3452) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 10:55:20 -0000 Thank you Acee I will wait a couple of weeks to give the OSPF WG a chance to comment and take silence as agreement with your proposal. Stewart On 13/01/2013 12:04, Acee Lindem wrote: > All, > Since section is 11 is describing the contents of a single routing table entry, there is only one destination and adding "same" would be redundant. Hence, I recommend that this errata be rejected. > Thanks, > Acee > On Jan 12, 2013, at 9:39 PM, RFC Errata System wrote: > >> The following errata report has been submitted for RFC2328, >> "OSPF Version 2". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3452 >> >> -------------------------------------- >> Type: Editorial >> Reported by: David Jet >> >> Section: 11 >> >> Original Text >> ------------- >> Multiple LSAs may reference the destination, however a tie-breaking scheme always reduces the choice to a single LSA. >> >> Corrected Text >> -------------- >> Multiple LSAs may reference the same destination, however a tie-breaking scheme always reduces the choice to a single LSA. >> >> Notes >> ----- >> I think should add the "same" to describe it more clearly. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC2328 (no draft string recorded) >> -------------------------------------- >> Title : OSPF Version 2 >> Publication Date : April 1998 >> Author(s) : J. Moy >> Category : STANDARD >> Source : Open Shortest Path First IGP >> Area : Routing >> Stream : IETF >> Verifying Party : IESG > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From acee.lindem@ericsson.com Mon Jan 14 08:06:17 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09121F8738 for ; Mon, 14 Jan 2013 08:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=-2.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 9ACPDHz0iCEl for ; Mon, 14 Jan 2013 08:06:16 -0800 (PST) Received: from usevmg20.ericsson.net (unknown [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E224121F8859 for ; Mon, 14 Jan 2013 08:06:15 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-c1-50f42cf671f5 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.83.31450.6FC24F05; Mon, 14 Jan 2013 17:06:15 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 11:06:14 -0500 From: Acee Lindem To: David Jet Thread-Topic: [Editorial Errata Reported] RFC2328 (3452) Thread-Index: AQHN8Ti7/dPt6KyfBUewD+AtEIHXLZhHfb4AgAFRXoCAAIRmAA== Date: Mon, 14 Jan 2013 16:06:13 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4709D1EA@eusaamb101.ericsson.se> References: <20130113023928.797A6622E9@rfc-editor.org> <94A203EA12AECE4BA92D42DBFFE0AE4709BDC8@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/signed; boundary="Apple-Mail-2--232235128"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyuXRPlO53nS8BBgtfsFr86LnBbHH44Cw2 i/6NL9gsJs6VsWi5d4/domn/VzaLc0/nMDqwe/xbvY3ZY8rvjaweO2fdZfdYsuQnk8eKzSsZ PRrajrEGsEVx2aSk5mSWpRbp2yVwZTz+Noep4HdZxZn385gbGP9ndTFyckgImEj07b/OBmGL SVy4tx7I5uIQEjjCKPH+3i92kISQwHJGiRv/wWw2AR2J54/+MYPYIgJKEkf272UGaWAW+MMo sfrNGUaQhLCAuUTT+3uMEEUWEus71rBB2E4SD1dsZQWxWQRUJVa09YMN5RXwluhbdAdq835G ic7T18CKOAUCJVqOQBQxAp33/dQaJhCbWUBc4taT+UwQZ4tIPLx4GuoFUYmXj/+xQtjKEkue 7GeBqK+UePxyOtQyQYmTM5+wTGAUnYVk1CwkZbOQlM1i5ACKu0usXSEHUaItsWzha2aIsI7E 5IWMqMIQ9sfzR6Ammkq8PvoRqsZaYsavg2wQtqLElO6H7AsYuVcxcpQWp5blphsZbGIEJoNj Emy6Oxj3vLQ8xCjNwaIkzhvkeiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+O8f2Jvb1j3 s3j6bmDoXPDRcNtB3quzGzIaV9+SXevyqF307uaupPKcq/a1zm/urG2uEU6bPKmJRaAli7nV OIWtZKnz02/OIUvXF7FHN+hYn3X9lXLsRo3BUSem0v2HLm0NDmjt9g0+6tvYK1A67ULnlGdC 5q3cXKbxk1RcWtovmU37/rMsWYmlOCPRUIu5qDgRAFOpQ7/UAgAA Cc: "" , RFC Errata System , "" Subject: Re: [OSPF] [Editorial Errata Reported] RFC2328 (3452) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:06:17 -0000 --Apple-Mail-2--232235128 Content-Type: multipart/alternative; boundary=Apple-Mail-1--232235142 --Apple-Mail-1--232235142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii David, On Jan 14, 2013, at 3:12 AM, David Jet wrote: > so for the sentence "However, two instances of the same LSA may" = should not contain the word "same" either? >=20 > That sentence is in Section 12.4 . >=20 > Please take a think about the smooth syntax style. Section 11 is in the context of a single route table entry which, by = definition, is a single destination which is referred to as "the = destination" throughout this section.=20 >=20 > I still think the word "same" should be added. As I was confused when = I read to that place. There should be no confusion if you read section 11 from the start.=20 Thanks, Acee=20 >=20 > Thank you for your attention and reply. >=20 > :) >=20 > David Jet >=20 >=20 > On 13 January 2013 20:04, Acee Lindem = wrote: > All, > Since section is 11 is describing the contents of a single routing = table entry, there is only one destination and adding "same" would be = redundant. Hence, I recommend that this errata be rejected. > Thanks, > Acee > On Jan 12, 2013, at 9:39 PM, RFC Errata System wrote: >=20 > > > > The following errata report has been submitted for RFC2328, > > "OSPF Version 2". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3452 > > > > -------------------------------------- > > Type: Editorial > > Reported by: David Jet > > > > Section: 11 > > > > Original Text > > ------------- > > Multiple LSAs may reference the destination, however a tie-breaking = scheme always reduces the choice to a single LSA. > > > > Corrected Text > > -------------- > > Multiple LSAs may reference the same destination, however a = tie-breaking scheme always reduces the choice to a single LSA. > > > > Notes > > ----- > > I think should add the "same" to describe it more clearly. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC2328 (no draft string recorded) > > -------------------------------------- > > Title : OSPF Version 2 > > Publication Date : April 1998 > > Author(s) : J. Moy > > Category : STANDARD > > Source : Open Shortest Path First IGP > > Area : Routing > > Stream : IETF > > Verifying Party : IESG >=20 >=20 --Apple-Mail-1--232235142 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
so for the sentence "However, two instances of the =
same LSA may" should not contain the word "same" =
either?

That sentence is in Section 12.4 .

Please take a think about the smooth syntax =
style.

Section 11 is in = the context of a single route table entry which, by definition, is a = single destination which is referred to as "the destination" throughout = this section. 



I still think the word "same" should be added. As I =
was confused when I read to that =
place.

There should be no = confusion if you read section 11 from the = start. 

Thanks,
Acee 



Thank you for your attention and =
reply.

:)

David Jet


On 13 January = 2013 20:04, Acee Lindem <acee.lindem@ericsson.com> wrote:
All,
Since section is 11 is describing the contents of a single routing table = entry, there is only one destination and adding "same" would be = redundant. Hence, I recommend that this errata be rejected.
Thanks,
Acee
On Jan 12, 2013, at 9:39 PM, RFC = Errata System wrote:

>
> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D2328&a= mp;eid=3D3452
>
> --------------------------------------
> Type: Editorial
> Reported by: David Jet <davidjet@gmail.com>
>
> Section: 11
>
> Original Text
> -------------
> Multiple LSAs may reference the destination, however a tie-breaking = scheme always reduces the choice to a single LSA.
>
> Corrected Text
> --------------
> Multiple LSAs may reference the same destination, however a = tie-breaking scheme always reduces the choice to a single LSA.
>
> Notes
> -----
> I think should add the "same" to describe it more clearly.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, = please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party = (IESG)
> can log in to change the status and edit the report, if = necessary.
>
> --------------------------------------
> RFC2328 (no draft string recorded)
> --------------------------------------
> Title               : OSPF = Version 2
> Publication Date    : April 1998
> Author(s)           : J. Moy
> Category            : STANDARD
> Source              : Open = Shortest Path First IGP
> Area                : = Routing
> Stream              : IETF
> Verifying Party     : IESG



= --Apple-Mail-1--232235142-- --Apple-Mail-2--232235128 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDExNDE2MDYxMFowIwYJKoZI hvcNAQkEMRYEFO8vsPvBpFF6TWjF1O7vbGh+spveMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDoiQHjhbX1iCL2cR6bu8Yd8mkCIP2v9ucn3tGqabZMYplk40elNoatNCn9vai5R SWaVkOg1kJuxR3miW3P6zgAIyuq1REs6D0vU96IxdII6ZHhMe6pogL9Xw/0kL2CdxWtPqodAoR3m 1PoEExMOqCJ7UoCyXVzH+SNTckq2SqTWAAAAAAAA --Apple-Mail-2--232235128-- From wwwrun@rfc-editor.org Mon Jan 14 17:34:33 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3461311E80EE; Mon, 14 Jan 2013 17:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 VRy5s2+q-vyn; Mon, 14 Jan 2013 17:34:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 42A0A11E80A6; Mon, 14 Jan 2013 17:34:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C81CCB1E00C; Mon, 14 Jan 2013 17:23:48 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130115012348.C81CCB1E00C@rfc-editor.org> Date: Mon, 14 Jan 2013 17:23:48 -0800 (PST) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 6845 on OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:34:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6845 Title: OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type Author: N. Sheth, L. Wang, J. Zhang Status: Standards Track Stream: IETF Date: January 2013 Mailbox: nsheth@contrailsystems.com, liliw@juniper.net, zzhang@juniper.net Pages: 9 Characters: 17019 Updates: RFC2328, RFC5340 I-D Tag: draft-ietf-ospf-hybrid-bcast-and-p2mp-06.txt URL: http://www.rfc-editor.org/rfc/rfc6845.txt This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF. This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). [STANDARDS-TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Jan 17 11:40:14 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9A721F8941; Thu, 17 Jan 2013 11:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.049 X-Spam-Level: X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 P9qVium9NIya; Thu, 17 Jan 2013 11:40:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B160621F8942; Thu, 17 Jan 2013 11:40:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2AF20B1E012; Thu, 17 Jan 2013 11:29:11 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130117192911.2AF20B1E012@rfc-editor.org> Date: Thu, 17 Jan 2013 11:29:11 -0800 (PST) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 6860 on Hiding Transit-Only Networks in OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:40:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6860 Title: Hiding Transit-Only Networks in OSPF Author: Y. Yang, A. Retana, A. Roy Status: Standards Track Stream: IETF Date: January 2013 Mailbox: yiya@cisco.com, aretana@cisco.com, akr@cisco.com Pages: 13 Characters: 26368 Updates: RFC2328, RFC5340 I-D Tag: draft-ietf-ospf-prefix-hiding-07.txt URL: http://www.rfc-editor.org/rfc/rfc6860.txt A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks. In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2. This document updates RFCs 2328 and 5340. [STANDARDS-TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From akr@cisco.com Fri Jan 18 10:08:34 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FEE21F86F7; Fri, 18 Jan 2013 10:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 eqiDDEzuao7y; Fri, 18 Jan 2013 10:08:31 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9403D21F84E7; Fri, 18 Jan 2013 10:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7791; q=dns/txt; s=iport; t=1358532511; x=1359742111; h=message-id:date:from:mime-version:to:subject; bh=azBQtzShaRaE9/TuVlopGbr1Y4QGo3Nthnl7SD62Fag=; b=dGX7Wc+0X2rLpuRV70OnthsvME0zlhdglTJN/hSBYiMeYNEvPvoRnYnR bRltM3DalIMFB7ZJIvMHvxYgf2EHz9aMT0AeTDFtWkqQzo0QzFaQhKX6o aB6R6bGe2rcrekw07FQTAhX8wxmFic1XT9/QYvYWlRGKWpbpfNAySiSlC 8=; X-Files: ospf-wg-rfc3137bis-shepherd-writeup.txt : 6215 X-IronPort-AV: E=Sophos;i="4.84,494,1355097600"; d="txt'?scan'208,217";a="66042679" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 18 Jan 2013 18:08:31 +0000 Received: from [10.155.32.51] ([10.155.32.51]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0II8VHX029812; Fri, 18 Jan 2013 18:08:31 GMT Message-ID: <50F98F9F.3090008@cisco.com> Date: Fri, 18 Jan 2013 10:08:31 -0800 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "adrian@olddog.co.uk" , Stewart Bryant , "ospf@ietf.org" , ietf-secretariat@ietf.org Content-Type: multipart/mixed; boundary="------------050707040203060701000803" Subject: [OSPF] Request for Publication of "OSPF Stub Router Advertisement" - draft-ietf-ospf-rfc3137bis-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:08:34 -0000 This is a multi-part message in MIME format. --------------050707040203060701000803 Content-Type: multipart/alternative; boundary="------------030905080008090104010303" --------------030905080008090104010303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adrian, Stewart, We are ready to publish draft-ietf-ospf-rfc3137bis-03. Please find the shepherd writeup attached. Regards, -Abhay --------------030905080008090104010303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adrian, Stewart,

We are ready to publish draft-ietf-ospf-rfc3137bis-03. Please find the shepherd writeup attached.

Regards,
-Abhay

--------------030905080008090104010303-- --------------050707040203060701000803 Content-Type: text/plain; charset=UTF-8; name="ospf-wg-rfc3137bis-shepherd-writeup.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ospf-wg-rfc3137bis-shepherd-writeup.txt" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This document updates RFC3137 to include applicability to OSPFv3. Working Group Summary: There were some noteworthy discussions around including an alternate solution in OSPFv3 which achieves some of the same goals as RFC3137. Authors added a section to capture the use of R-bit as a potential alternative solution. R-bit is part of base OSPFv3 (RFC2740). Document Quality: The incremental update to RFC3137 are minimal and the application to OSPFv3 is identical to OSPFv2. Personnel: Abhay Roy is the document shepherd and Stewart Bryant is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The draft is a minimal update of RFC3137. There has been significant review and discussion of this draft on the mailing list. There are no outstanding issues with this draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus from WG with many participating in discussions. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Authors have resolved all nits. One minor one (see below) remains which can be resolved in rfc-editor queue. -- The draft header indicates that this document obsoletes RFC3137, but the abstract doesn't seem to mention this, which it should. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Yes (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There is no IANA Action needed. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There is no IANA Action needed. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable --------------050707040203060701000803-- From acee.lindem@ericsson.com Sun Jan 27 12:50:53 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F4021F8794 for ; Sun, 27 Jan 2013 12:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001] 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 6dLI1NbvvEG9 for ; Sun, 27 Jan 2013 12:50:53 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 57FF421F8816 for ; Sun, 27 Jan 2013 12:50:52 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-81-5105932a5e23 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1A.BB.03705.A2395015; Sun, 27 Jan 2013 21:50:50 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Sun, 27 Jan 2013 15:50:50 -0500 From: Acee Lindem To: sarah boufelja Thread-Topic: Some enquiries about OSPFv3 Auto-Configuration Internet Draft Thread-Index: AQHN/MVnJd4LLteczkalS/Q6N6MngJhd+j2A Date: Sun, 27 Jan 2013 20:50:49 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470B0DAA@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470B0DAAeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPrK7WZNZAg9afuhYPu9ewW7Tcu8fu wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGX83NrNXvBVu+La2ntMDYxHVboYOTkkBEwk Hm77zQ5hi0lcuLeerYuRi0NI4AijRNuq21DOckaJl99fM4JUsQnoSDx/9I8ZxBYR0JXoXncc LM4sICvxbFsTWFxYwEvizO+ZUDXeEvO3/WaBsI0kfrz+ARZnEVCVmHpkOpDNwcELVLP5CViJ kECAxJGXXWAlnAKBEpd/Lgcbzwh03PdTa5ggVolL3HoynwniaAGJJXvOM0PYohIvH/9jhbCV JZY82c8CUZ8vcaf/B5jNKyAocXLmE5YJjKKzkIyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PY Zw48huq1luj+O4URWc0CRo5VjBylxalluelGhpsYgdF2TILNcQfjgk+WhxilOViUxHlDXS8E CAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCsY/Rsb5BKkV79OvJr4LY431er/DtycrLYUhcl Lj/Y0XQh67ev76kwp6LugsXz/TWDtB/MWnVOTLw/j2/j9P2foz5FnVr8xm+HmBvnIWHd1OXp lZIX7108eNPxJ3vQPKskgV0TJNul3vOYzn/z2v7eIRe2fx227hFxL3INp3pPVI2/edXWYoUS S3FGoqEWc1FxIgC/FmD2hAIAAA== Cc: OSPF List Subject: Re: [OSPF] Some enquiries about OSPFv3 Auto-Configuration Internet Draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 20:50:53 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470B0DAAeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sarah (OSPF List copied), See inline. On Jan 27, 2013, at 2:34 PM, sarah boufelja wrote: Dear Sir, I am a engineering student at Telecom Bretagne, a french graduate= school and a research center in communications and computer science. I am = studying in my project routing protocols and I found an Internet-draft that= has been written by you and Mr. Jari Arkko about OSPFv3 auto-configuration= . I am interested in this subject and I have some questions concerning the = draft. I would be really thankful if you enlightened me: 1- My first question concerns the part 5.4 in the draft (Change to received= self-originated LSA processing): it's written that the router, when it det= ects that some instances of its self-originated LSA are purged or reflooded= , it's an indication of a possible router-ID duplication and it must delay = self-originated LSA processing for LSA that have recently been purged or re= flooded for ten seconds and an exponential back-off of 1 to 8 seconds for t= he processing delay. I don't really figure out this specification, what abo= ut the AC -LSA, isn't sufficient to detect and resolve any duplication ID i= ssue? Possibly the AC-LSA isn't the first LSA to be received by the router joinin= g the OSPFv3 routing domain with the same OSPFv3 Router-ID as another route= r in the same domain. Hence, this is to mitigate any flooding wars until th= e OSPFv3 routers realize that a duplicate router-id condition exists. 2- Concerning the IPv6 global addresses, the specifications introduced the = AC-LSA that can be used in the future to carry some additional information = about global IPv6 prefixes, can we envisage for instance to use this LSA to= do a stateless autoconfiguration by giving the router a prefix to construc= t a global unicast address without any human intervention? There is a draft proposing just this in the HOMENET WG. https://datatracker.ietf.org/doc/draft-arkko-homenet-prefix-assignment/ Thank you very much in advance for your help. Thanks, Acee Cordially. --_000_94A203EA12AECE4BA92D42DBFFE0AE470B0DAAeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Sarah (OSPF List copied), 

See inline.

On Jan 27, 2013, at 2:34 PM, sarah boufelja wrote:

Dear Sir, I am a engineering student at Telecom Bretagne, a french gradu= ate school and a research center in communications and computer science. I = am studying in my project routing protocols and I found an Internet-draft t= hat has been written by you and Mr. Jari Arkko about OSPFv3 auto-configuration. I am interested in this su= bject and I have some questions concerning the draft. I would be really tha= nkful if you enlightened me:

1- My first question concerns the part 5.4 in the draft (Change to recei= ved self-originated LSA processing): it's written that the router, when it = detects that some instances of its self-originated LSA are purged or refloo= ded, it's an indication of a possible router-ID duplication and it must delay self-originated LSA processing for= LSA that have recently been purged or reflooded for ten seconds and an exp= onential back-off of 1 to 8 seconds for the processing delay. I don't reall= y figure out this specification, what about the AC -LSA, isn't sufficient to detect and resolve any duplica= tion ID issue?

Possibly the AC-LSA isn't the first LSA to be received by the router j= oining the OSPFv3 routing domain with the same OSPFv3 Router-ID as another = router in the same domain. Hence, this is to mitigate any flooding wars unt= il the OSPFv3 routers realize that a duplicate router-id condition exists. 

2- Concerning the IPv6 global addresses, the specifications introduced t= he AC-LSA that can be used in the future to carry some additional informati= on about global IPv6 prefixes, can we envisage for instance to use this LSA= to do a stateless autoconfiguration by giving the router a prefix to construct  a global unicast address = without any human intervention?

There is a draft proposing just this in the HOMENET WG. 


Thank you very much in advance for your help.

Thanks,
Acee 



Cordially.


--_000_94A203EA12AECE4BA92D42DBFFE0AE470B0DAAeusaamb101ericsso_-- From iesg-secretary@ietf.org Mon Jan 28 15:57:18 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7957821E8030; Mon, 28 Jan 2013 15:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, 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 zJwIudilYOUk; Mon, 28 Jan 2013 15:57:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2E21F84C0; Mon, 28 Jan 2013 15:57:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130128235717.25798.32553.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2013 15:57:17 -0800 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (OSPF Stub Router Advertisement) to Informational RFC X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 23:57:18 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPF Stub Router Advertisement' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc3137bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc3137bis/ballot/ No IPR declarations have been submitted directly on this I-D.