From web-usrn@ISI.EDU Sun Mar 1 13:34:54 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3EA28C1D8 for ; Sun, 1 Mar 2009 13:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.046 X-Spam-Level: X-Spam-Status: No, score=-17.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY+X-hw+dofc for ; Sun, 1 Mar 2009 13:34:53 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 3A0CA28C1D4 for ; Sun, 1 Mar 2009 13:34:53 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n21LYluo003541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 1 Mar 2009 13:34:48 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n21LYjZ7003535; Sun, 1 Mar 2009 13:34:45 -0800 (PST) Date: Sun, 1 Mar 2009 13:34:45 -0800 (PST) Message-Id: <200903012134.n21LYjZ7003535@boreas.isi.edu> To: Emmanuel.Baccelli@inria.fr, Philippe.Jacquet@inria.fr, dang.nguyen@crc.ca, T.Clausen@computer.org, rcallon@juniper.net, dward@cisco.com, acee@redback.com, akr@cisco.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ospf@ietf.org, ah@TR-Sys.de, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC5449 (1697) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 01 Mar 2009 21:34:54 -0000 The following errata report has been submitted for RFC5449, "OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5449&eid=1697 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: A., 2nd para Original Text ------------- The following terminology will be used in describing the heuristics: D(Y) is the degree of a 1-hop neighbor, router Y (where Y is a member | of N(i), defined as the number of neighbors of router Y, EXCLUDING all the members of N(i) and EXCLUDING the router performing the computation. The proposed heuristic can then be described as follows. Begin with an empty Flooding-MPR set. Then: Corrected Text -------------- The following terminology will be used in describing the heuristics: D(Y) is the degree of a 1-hop neighbor, router Y (where Y is a member | of N(i)), defined as the number of neighbors of router Y, EXCLUDING all the members of N(i) and EXCLUDING the router performing the computation. The proposed heuristic can then be described as follows. Begin with an empty Flooding-MPR set. Then: Notes ----- A missing matching ')' makes the text very ambiguous and confusing. 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. -------------------------------------- RFC5449 (draft-ietf-ospf-manet-mpr-04) -------------------------------------- Title : OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks Publication Date : February 2009 Author(s) : E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen Category : EXPERIMENTAL Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From acee@lindem.com Mon Mar 2 04:40:20 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170993A6AF8 for ; Mon, 2 Mar 2009 04:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+Gl+PJhARzX for ; Mon, 2 Mar 2009 04:40:19 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by core3.amsl.com (Postfix) with ESMTP id 8035E3A6A2B for ; Mon, 2 Mar 2009 04:40:17 -0800 (PST) Received: from [10.0.1.199] (really [66.57.18.13]) by cdptpa-omta01.mail.rr.com with ESMTP id <20090302124042.LZHB8036.cdptpa-omta01.mail.rr.com@[10.0.1.199]>; Mon, 2 Mar 2009 12:40:42 +0000 In-Reply-To: <200903012134.n21LYjZ7003535@boreas.isi.edu> References: <200903012134.n21LYjZ7003535@boreas.isi.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <016975EE-45E6-4281-83F0-65DAFF067ABC@lindem.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Mon, 2 Mar 2009 07:40:34 -0500 To: RFC Errata System X-Mailer: Apple Mail (2.753.1) Cc: ah@TR-Sys.de, dang.nguyen@crc.ca, T.Clausen@computer.org, Emmanuel.Baccelli@inria.fr, ospf@ietf.org, Philippe.Jacquet@inria.fr Subject: Re: [OSPF] [Editorial Errata Reported] RFC5449 (1697) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2009 12:40:20 -0000 RFC Editor, The right parenthesis is obviously missing. However, I'd disagree that the omission makes the text very ambiguous or confusing. Alfred - one thing that would be more useful would be if you reviewed the documents during WG or IETF Last Call rather than immediately after they become RFCs :^) Thanks, Acee On Mar 1, 2009, at 4:34 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5449, > "OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5449&eid=1697 > > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes > > Section: A., 2nd para > > Original Text > ------------- > The following terminology will be used in describing the > heuristics: > D(Y) is the degree of a 1-hop neighbor, router Y (where Y is a > member > | of N(i), defined as the number of neighbors of router Y, EXCLUDING > all the members of N(i) and EXCLUDING the router performing the > computation. The proposed heuristic can then be described as > follows. Begin with an empty Flooding-MPR set. Then: > > > > Corrected Text > -------------- > The following terminology will be used in describing the > heuristics: > D(Y) is the degree of a 1-hop neighbor, router Y (where Y is a > member > | of N(i)), defined as the number of neighbors of router Y, EXCLUDING > all the members of N(i) and EXCLUDING the router performing the > computation. The proposed heuristic can then be described as > follows. Begin with an empty Flooding-MPR set. Then: > > > > Notes > ----- > A missing matching ')' makes the text very ambiguous and confusing. > > 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. > > -------------------------------------- > RFC5449 (draft-ietf-ospf-manet-mpr-04) > -------------------------------------- > Title : OSPF Multipoint Relay (MPR) Extension for Ad > Hoc Networks > Publication Date : February 2009 > Author(s) : E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen > Category : EXPERIMENTAL > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From IBryskin@advaoptical.com Mon Mar 2 07:20:53 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2499F3A6BD8 for ; Mon, 2 Mar 2009 07:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nkuu7ShWHQj for ; Mon, 2 Mar 2009 07:20:52 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 155053A6C05 for ; Mon, 2 Mar 2009 07:20:51 -0800 (PST) Received: from muc-srv-mimesweeper.advaoptical.com (muc-srv-mimesweeper.advaoptical.com [10.200.0.15]) by mail.advaoptical.com (8.14.1/8.14.1) with ESMTP id n22FL6FY004324 for ; Mon, 2 Mar 2009 16:21:06 +0100 Received: from muc-srv-exhub.advaoptical.com (muc-srv-exhub.advaoptical.com) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Mon, 2 Mar 2009 16:21:07 +0100 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 2 Mar 2009 16:21:06 +0100 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Mon, 2 Mar 2009 10:21:03 -0500 From: Igor Bryskin To: David Ward , Acee Lindem Date: Mon, 2 Mar 2009 10:21:01 -0500 Thread-Topic: [OSPF] OSPF Multi-Instance and Transport Instance Thread-Index: AcmZHCreqgQ2Ge/KSXC9/mhVGKRnnACLf5Tg Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC128524C8F1@atl-srv-exgen.atl.advaoptical.com> References: <159A4DF0-A07B-4AB5-9221-AED32B43593B@cisco.com> In-Reply-To: <159A4DF0-A07B-4AB5-9221-AED32B43593B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2009 15:20:53 -0000 I support this effort, because this is very important for advanced Traffic = Engineering architectures.=20 Igor Bryskin -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Dav= id Ward Sent: Friday, February 27, 2009 3:44 PM To: Acee Lindem Cc: OSPF List Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance I support this effort (and hope that OSPF catches up with the =20 innovation and features in IS-IS.) -DWard On Feb 14, 2009, at 3:43 PM, Acee Lindem wrote: > In Minneapolis, there was some interest in making these WG group =20 > documents. Additionally, the AD have sponsored this activity given =20 > that a solution is being actively pursued in the ISIS WG (though =20 > significantly less powerful). > > There was one dissenting comment that one could achieve the same =20 > results with a single instance given sufficient invention (aka, the =20 > "even pigs can fly" argument). I've added text to the transport =20 > instance draft as well as mechanisms and text enabling sparse =20 > topologies that I believe clearly demonstrates the superiority of =20 > this solution. Hence, I like to now ask if there is any further =20 > reason not to make these WG documents? > > Here are the current versions: > > http://www.ietf.org/internet-drafts/draft-acee-ospf-multi-instance-02.txt > http://www.ietf.org/internet-drafts/draft-acee-ospf-transport-instance-02= .txt > > Thanks, > Acee_______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From prvs=3097fee48=acee@redback.com Fri Mar 6 10:34:50 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E7E3A6841 for ; Fri, 6 Mar 2009 10:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkRrl2I7B29C for ; Fri, 6 Mar 2009 10:34:49 -0800 (PST) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id C23D93A6816 for ; Fri, 6 Mar 2009 10:34:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,316,1233561600"; d="scan'208";a="184766" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 06 Mar 2009 10:35:20 -0800 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 831696F9A6C for ; Fri, 6 Mar 2009 10:35:20 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11762-07 for ; Fri, 6 Mar 2009 10:35:20 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 36C006F9A6B for ; Fri, 6 Mar 2009 10:35:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: OSPF List From: Acee Lindem Date: Fri, 6 Mar 2009 13:35:19 -0500 X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] IETF 74 OSPF WG Meeting in San Francisco Call for Agenda X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 06 Mar 2009 18:39:42 -0000 Please contact Abhay or me if you have something to present. Thanks, Abhay & Acee From prvs=3097fee48=acee@redback.com Fri Mar 6 11:29:42 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6673A6C73 for ; Fri, 6 Mar 2009 11:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UW+Lu33mbye for ; Fri, 6 Mar 2009 11:29:41 -0800 (PST) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 5195E3A6A07 for ; Fri, 6 Mar 2009 11:29:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,316,1233561600"; d="scan'208";a="185898" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 06 Mar 2009 11:30:12 -0800 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2074DA39F38; Fri, 6 Mar 2009 11:30:12 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29643-08; Fri, 6 Mar 2009 11:30:11 -0800 (PST) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id AD490A39F36; Fri, 6 Mar 2009 11:30:10 -0800 (PST) In-Reply-To: <32168452-B8EF-46D6-AB48-16078E75B207@cisco.com> References: <107AAAF2-FA04-485F-AD82-091E69E27B64@redback.com> <32168452-B8EF-46D6-AB48-16078E75B207@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95906602-A0E3-4B25-A669-7C9E40E4CE5D@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Fri, 6 Mar 2009 14:30:09 -0500 To: David Ward X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List , Sina Mirtorabi Subject: Re: [OSPF] WG Last Call for Support of address families in OSPFv3 - draft-ietf-ospf-af-alt-07.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 06 Mar 2009 19:29:42 -0000 Hi Dave, We'll provided an updated version of the draft addressing your comments. We need to discuss among the authors. On Feb 25, 2009, at 2:23 PM, David Ward wrote: > Acee and OSPF'ers - > > A few comments: > > 0) It's unclear what happens if the value of the instance_id (which > has semantics of AF/SAF) and the prefix options bits in 2.2.2 don't > match. What happens in this failure case and what should win? > a) in addition, what happens if an instance_id >= 128 is received? > > 1) The draft may want to call out a few more details that are in > 5340 that the instance_id is per link and a few of the rules in 5340. I agree we need to clarify these cases. I wish the original OSPFv3 RFC hadn't included any bits without specification of how they are going to be used. > > 2) It isn't clear if there are or should be rules for leaking > routes between instances. For example: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason- > routing-ospf-07.txt > > requires that leaking and policy is required. Given that, it seems > you have to have some general rules and failure conditions. For > example, leaking between instances of the same AF could be allowed > and they are to be imported as ASE ... I don't think this should be specified other than the obvious rule that the any imported routes should be from the same address family. Note that the above draft is an experimental draft and its utility remains to be proven. > > draft and WG LC> > > 3) Do you want to set aside a small set of instance_ids for non- > routing information at this time? Given you have taken on the work, > and you know it is coming maybe it makes sense now? I'll discuss with other authors. The space is very small (256 code points), so we have be careful we don't restrict this too much. Thanks, Acee > > I have other comments but, this is a start. > > -DWard > > On Feb 25, 2009, at 5:13 AM, Acee Lindem wrote: > >> This starts the Working Group Last Call for the subject document. >> The target status is proposed standard. >> The WG Last Call will start today and end March 12th at 12:00 AM EDT. >> >> Thanks, >> Acee >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > From wwwrun@core3.amsl.com Wed Mar 11 09:25:06 2009 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7472E28C1C7; Wed, 11 Mar 2009 09:25:04 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090311162506.7472E28C1C7@core3.amsl.com> Date: Wed, 11 Mar 2009 09:25:04 -0700 (PDT) Cc: ospf mailing list , ospf chair , Internet Architecture Board , RFC Editor Subject: [OSPF] Document Action: 'MANET Extension of OSPF using CDS Flooding' to Experimental RFC X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 11 Mar 2009 16:25:06 -0000 The IESG has approved the following document: - 'MANET Extension of OSPF using CDS Flooding ' as an Experimental RFC This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are David Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-05.txt Technical Summary OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. Working Group Summary The OSPF WG was unable to reach concensus on a single MANET OSPF approach and agreed to go forward with the three competing approaches as experimental RFCs. Document Quality Passed review and idnits Personnel Dave Ward From Joakim.Tjernlund@transmode.se Wed Mar 11 10:39:00 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480693A69F1 for ; Wed, 11 Mar 2009 10:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQy26Q2qtJuG for ; Wed, 11 Mar 2009 10:38:59 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 640CA3A6925 for ; Wed, 11 Mar 2009 10:38:58 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id B9B114F159 for ; Wed, 11 Mar 2009 18:39:32 +0100 (CET) To: ospf@ietf.org MIME-Version: 1.0 X-KeepSent: 7D9A4B41:2364B9EA-C1257576:006000F6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Wed, 11 Mar 2009 18:39:32 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5|December 05, 2008) at 2009-03-11 18:39:32, Serialize complete at 2009-03-11 18:39:32 Content-Type: text/plain; charset="US-ASCII" Subject: [OSPF] Attached hosts question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 11 Mar 2009 17:39:00 -0000 Last in "12.4.1. Router-LSAs" one can read: After consideration of all the router interfaces, host links are added to the router-LSA by examining the list of attached hosts belonging to Area A. A host route is represented as a Type 3 link (stub network) whose Link ID is the host's IP address, Link Data is the mask of all ones (0xffffffff), and cost the host's configured cost (see Section C.7). C.7 Host route parameters Host routes are advertised in router-LSAs as stub networks with mask 0xffffffff. They indicate either router interfaces to point-to-point networks, looped router interfaces, or IP hosts that are directly connected to the router (e.g., via a SLIP line). For each host directly connected to the router, the following items must be configured: Host IP address The IP address of the host. Cost of link to host The cost of sending a packet to the host, in terms of the link state metric. However, since the host probably has only a single connection to the internet, the actual configured cost in many cases is unimportant (i.e., will have no effect on routing). Area ID The OSPF area to which the host belongs. I read this as one can manually configure a list of attached hosts in the router and these are then announced in the router LSA. What I don't get is if one should do any validation that the configured hosts are reachable or not? The spec doesn't mention this and I am getting the feeling that this should just be a stupid list of hosts that gets announced regardless if they are reachable or not. Jocke From prvs=314889a67=acee@redback.com Wed Mar 11 16:14:00 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A402A28C123 for ; Wed, 11 Mar 2009 16:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLd9FqPCfa4K for ; Wed, 11 Mar 2009 16:13:55 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 2BE753A6950 for ; Wed, 11 Mar 2009 16:13:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,346,1233561600"; d="scan'208";a="261057" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 11 Mar 2009 16:14:31 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E344EAC87E3; Wed, 11 Mar 2009 16:14:31 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25287-10; Wed, 11 Mar 2009 16:14:31 -0700 (PDT) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 2EF58AC87E2; Wed, 11 Mar 2009 16:14:30 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Wed, 11 Mar 2009 19:14:31 -0400 To: Joakim Tjernlund X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org Subject: Re: [OSPF] Attached hosts question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 11 Mar 2009 23:15:38 -0000 Hi Joakim, Even though RFC 2328 doesn't specify it, I wouldn't advertise these hosts unless the corresponding link is up. If we were starting from scratch with the protocol, I'd leave the host configuration out and add a "passive" interface parameter to advertise subnets on which you don't want to actually run OSPF. Thanks, Acee On Mar 11, 2009, at 1:39 PM, Joakim Tjernlund wrote: > Last in "12.4.1. Router-LSAs" one can read: > > After consideration of all the router interfaces, host > links > are added to the router-LSA by examining the list of > attached hosts belonging to Area A. A host route is > represented as a Type 3 link (stub network) whose Link > ID is > the host's IP address, Link Data is the mask of all ones > (0xffffffff), and cost the host's configured cost (see > Section C.7). > > C.7 Host route parameters > > Host routes are advertised in router-LSAs as stub networks > with > mask 0xffffffff. They indicate either router interfaces to > point-to-point networks, looped router interfaces, or IP hosts > that are directly connected to the router (e.g., via a SLIP > line). For each host directly connected to the router, the > following items must be configured: > > > Host IP address > The IP address of the host. > > Cost of link to host > The cost of sending a packet to the host, in terms of the > link state metric. However, since the host probably has > only a single connection to the internet, the actual > configured cost in many cases is unimportant (i.e., will > have no effect on routing). > > Area ID > The OSPF area to which the host belongs. > > > I read this as one can manually configure a list of attached hosts > in the > router and these are then announced in the router LSA. > What I don't get is if one should do any validation that the > configured > hosts are reachable or not? The spec doesn't mention this and I am > getting > the feeling that this should just be a stupid list of hosts that gets > announced > regardless if they are reachable or not. > > Jocke > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From prvs=3159d2830=acee@redback.com Thu Mar 12 02:53:46 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCFB3A6AB7 for ; Thu, 12 Mar 2009 02:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awMK8aOrlC4b for ; Thu, 12 Mar 2009 02:53:45 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 073F83A6AF2 for ; Thu, 12 Mar 2009 02:53:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,349,1233561600"; d="scan'208";a="266797" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 12 Mar 2009 02:54:22 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7FF48C28A69 for ; Thu, 12 Mar 2009 02:54:22 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26404-07 for ; Thu, 12 Mar 2009 02:54:22 -0700 (PDT) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 39A84C28A68 for ; Thu, 12 Mar 2009 02:54:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: <2C8CE9ED-3573-4E37-9FDD-D618E18D7CB4@redback.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: OSPF List From: Acee Lindem Date: Thu, 12 Mar 2009 05:54:21 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [OSPF] WG Last Call - Dynamic Hostname Exchange Mechanism for OSPF - draft-ietf-ospf-dynamic-hostname-02 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 12 Mar 2009 09:54:35 -0000 This starts the Working Group Last Call for the subject document. The target status is proposed standard. The WG Last Call will start today and end March 3rd at 12:00 AM EDT. I've added an additional week due to the upcoming IETF. If anyone needs more time to review the document, let Abhay or myself know. It is a very simple document and the last remaining issue (specification of hostname encoding) has been resolved to my satisfaction. Thanks, Acee From prvs=3159d2830=acee@redback.com Thu Mar 12 02:55:36 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19583A67D7 for ; Thu, 12 Mar 2009 02:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM9KqtV+2zLE for ; Thu, 12 Mar 2009 02:55:31 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id C7AD03A679F for ; Thu, 12 Mar 2009 02:55:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,349,1233561600"; d="scan'208";a="266814" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 12 Mar 2009 02:56:09 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 23744896977 for ; Thu, 12 Mar 2009 02:56:09 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26858-01 for ; Thu, 12 Mar 2009 02:56:09 -0700 (PDT) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id CE9C5896976 for ; Thu, 12 Mar 2009 02:56:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: <1BEEAE11-F1A5-40DD-B4A4-54C6743B18D4@redback.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: OSPF List From: Acee Lindem Date: Thu, 12 Mar 2009 05:56:08 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [OSPF] WG Last Call - Dynamic Hostname Exchange Mechanism for OSPF - draft-ietf-ospf-dynamic-hostname-02 (Corrected) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 12 Mar 2009 09:55:36 -0000 This starts the Working Group Last Call for the subject document. The target status is proposed standard. The WG Last Call will start today and end April 3rd at 12:00 AM EDT. I've added an additional week due to the upcoming IETF. If anyone needs more time to review the document, let Abhay or myself know. It is a very simple document and the last remaining issue (specification of hostname encoding) has been resolved to my satisfaction. Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From Joakim.Tjernlund@transmode.se Thu Mar 12 09:59:30 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA493A6B43 for ; Thu, 12 Mar 2009 09:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwe3U5qUQsOd for ; Thu, 12 Mar 2009 09:59:29 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 3A4873A6BF3 for ; Thu, 12 Mar 2009 09:59:26 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 99DBE31352; Thu, 12 Mar 2009 18:00:01 +0100 (CET) In-Reply-To: References: To: Acee Lindem MIME-Version: 1.0 X-KeepSent: D1E511EB:770B535E-C1257577:005D36C7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Thu, 12 Mar 2009 18:00:01 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5|December 05, 2008) at 2009-03-12 18:00:01, Serialize complete at 2009-03-12 18:00:01 Content-Type: text/plain; charset="US-ASCII" Cc: ospf@ietf.org Subject: Re: [OSPF] Attached hosts question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 12 Mar 2009 16:59:30 -0000 I see, I was planning to use this function to announce a host in every area that the router is attached to. Passive won't let me do that. Perhaps there is a better way? Jocke Acee Lindem wrote on 12/03/2009 00:14:31: > > Hi Joakim, > Even though RFC 2328 doesn't specify it, I wouldn't advertise these > hosts unless the corresponding link is up. If we were starting from > scratch with the protocol, I'd leave the host configuration out and > add a "passive" interface parameter to advertise subnets on which you > don't want to actually run OSPF. > > Thanks, > Acee > On Mar 11, 2009, at 1:39 PM, Joakim Tjernlund wrote: > > > Last in "12.4.1. Router-LSAs" one can read: > > > > After consideration of all the router interfaces, host > > links > > are added to the router-LSA by examining the list of > > attached hosts belonging to Area A. A host route is > > represented as a Type 3 link (stub network) whose Link > > ID is > > the host's IP address, Link Data is the mask of all ones > > (0xffffffff), and cost the host's configured cost (see > > Section C.7). > > > > C.7 Host route parameters > > > > Host routes are advertised in router-LSAs as stub networks > > with > > mask 0xffffffff. They indicate either router interfaces to > > point-to-point networks, looped router interfaces, or IP hosts > > that are directly connected to the router (e.g., via a SLIP > > line). For each host directly connected to the router, the > > following items must be configured: > > > > > > Host IP address > > The IP address of the host. > > > > Cost of link to host > > The cost of sending a packet to the host, in terms of the > > link state metric. However, since the host probably has > > only a single connection to the internet, the actual > > configured cost in many cases is unimportant (i.e., will > > have no effect on routing). > > > > Area ID > > The OSPF area to which the host belongs. > > > > > > I read this as one can manually configure a list of attached hosts > > in the > > router and these are then announced in the router LSA. > > What I don't get is if one should do any validation that the > > configured > > hosts are reachable or not? The spec doesn't mention this and I am > > getting > > the feeling that this should just be a stupid list of hosts that gets > > announced > > regardless if they are reachable or not. > > > > Jocke > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > From prvs=316815f39=acee@redback.com Fri Mar 13 04:50:25 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406BB3A6B18 for ; Fri, 13 Mar 2009 04:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq269+syTw5q for ; Fri, 13 Mar 2009 04:50:18 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 065CF3A6A60 for ; Fri, 13 Mar 2009 04:50:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,356,1233561600"; d="scan'208";a="288010" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 13 Mar 2009 04:50:56 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A9DFC24FA69 for ; Fri, 13 Mar 2009 04:50:56 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10789-01 for ; Fri, 13 Mar 2009 04:50:56 -0700 (PDT) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 58CEF24FA68 for ; Fri, 13 Mar 2009 04:50:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <95906602-A0E3-4B25-A669-7C9E40E4CE5D@redback.com> References: <107AAAF2-FA04-485F-AD82-091E69E27B64@redback.com> <32168452-B8EF-46D6-AB48-16078E75B207@cisco.com> <95906602-A0E3-4B25-A669-7C9E40E4CE5D@redback.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BE84930-AEE1-4FD5-A2DF-C103459BE324@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Fri, 13 Mar 2009 07:50:56 -0400 To: OSPF List X-Mailer: Apple Mail (2.753.1) Subject: Re: [OSPF] WG Last Call for Support of address families in OSPFv3 - draft-ietf-ospf-af-alt-07.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2009 11:51:17 -0000 The WG last call has ended. We issue a new version addressing Dave's comments once we've agreed on the updated text among the document authors. Thanks, Acee On Mar 6, 2009, at 2:30 PM, Acee Lindem wrote: > Hi Dave, > > We'll provided an updated version of the draft addressing your > comments. We need to discuss among the authors. > > On Feb 25, 2009, at 2:23 PM, David Ward wrote: > >> Acee and OSPF'ers - >> >> A few comments: >> >> 0) It's unclear what happens if the value of the instance_id >> (which has semantics of AF/SAF) and the prefix options bits in >> 2.2.2 don't match. What happens in this failure case and what >> should win? >> a) in addition, what happens if an instance_id >= 128 is received? >> >> 1) The draft may want to call out a few more details that are in >> 5340 that the instance_id is per link and a few of the rules in 5340. > > I agree we need to clarify these cases. I wish the original OSPFv3 > RFC hadn't included any bits without specification of how they are > going to be used. > >> >> 2) It isn't clear if there are or should be rules for leaking >> routes between instances. For example: >> >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason- >> routing-ospf-07.txt >> >> requires that leaking and policy is required. Given that, it seems >> you have to have some general rules and failure conditions. For >> example, leaking between instances of the same AF could be allowed >> and they are to be imported as ASE ... > > I don't think this should be specified other than the obvious rule > that the any imported routes should be from the same address > family. Note that the above draft is an experimental draft and its > utility remains to be proven. > > >> >> > draft and WG LC> >> >> 3) Do you want to set aside a small set of instance_ids for non- >> routing information at this time? Given you have taken on the >> work, and you know it is coming maybe it makes sense now? > > I'll discuss with other authors. The space is very small (256 code > points), so we have be careful we don't restrict this too much. > > Thanks, > Acee > > >> >> I have other comments but, this is a start. >> >> -DWard >> >> On Feb 25, 2009, at 5:13 AM, Acee Lindem wrote: >> >>> This starts the Working Group Last Call for the subject document. >>> The target status is proposed standard. >>> The WG Last Call will start today and end March 12th at 12:00 AM >>> EDT. >>> >>> Thanks, >>> Acee >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> > From prvs=316815f39=acee@redback.com Fri Mar 13 05:02:21 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46EA3A69D4 for ; Fri, 13 Mar 2009 05:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqYxbtIz3HvT for ; Fri, 13 Mar 2009 05:02:14 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id E75BC3A6B0C for ; Fri, 13 Mar 2009 05:02:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,356,1233561600"; d="scan'208";a="288133" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 13 Mar 2009 05:02:53 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 94D165C0835; Fri, 13 Mar 2009 05:02:53 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12057-06; Fri, 13 Mar 2009 05:02:53 -0700 (PDT) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id C565F5C0832; Fri, 13 Mar 2009 05:02:52 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Fri, 13 Mar 2009 08:02:53 -0400 To: Joakim Tjernlund X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org Subject: Re: [OSPF] Attached hosts question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2009 12:02:21 -0000 If you advertise a prefix (host or subnet) in one area, it will be advertised as a Summary-LSA in the other attached areas. I don't see a good reason to advertise the same prefix as an intra-area route in multiple areas. Thanks, Acee On Mar 12, 2009, at 1:00 PM, Joakim Tjernlund wrote: > I see, I was planning to use this function to announce a host in every > area that the router is attached to. Passive won't let me do that. > Perhaps > there is a better way? > > Jocke > > Acee Lindem wrote on 12/03/2009 00:14:31: >> >> Hi Joakim, >> Even though RFC 2328 doesn't specify it, I wouldn't advertise these >> hosts unless the corresponding link is up. If we were starting from >> scratch with the protocol, I'd leave the host configuration out and >> add a "passive" interface parameter to advertise subnets on which you >> don't want to actually run OSPF. >> >> Thanks, >> Acee >> On Mar 11, 2009, at 1:39 PM, Joakim Tjernlund wrote: >> >>> Last in "12.4.1. Router-LSAs" one can read: >>> >>> After consideration of all the router interfaces, host >>> links >>> are added to the router-LSA by examining the list of >>> attached hosts belonging to Area A. A host route is >>> represented as a Type 3 link (stub network) whose Link >>> ID is >>> the host's IP address, Link Data is the mask of all ones >>> (0xffffffff), and cost the host's configured cost (see >>> Section C.7). >>> >>> C.7 Host route parameters >>> >>> Host routes are advertised in router-LSAs as stub networks >>> with >>> mask 0xffffffff. They indicate either router interfaces to >>> point-to-point networks, looped router interfaces, or IP >>> hosts >>> that are directly connected to the router (e.g., via a SLIP >>> line). For each host directly connected to the router, the >>> following items must be configured: >>> >>> >>> Host IP address >>> The IP address of the host. >>> >>> Cost of link to host >>> The cost of sending a packet to the host, in terms of >>> the >>> link state metric. However, since the host probably has >>> only a single connection to the internet, the actual >>> configured cost in many cases is unimportant (i.e., will >>> have no effect on routing). >>> >>> Area ID >>> The OSPF area to which the host belongs. >>> >>> >>> I read this as one can manually configure a list of attached hosts >>> in the >>> router and these are then announced in the router LSA. >>> What I don't get is if one should do any validation that the >>> configured >>> hosts are reachable or not? The spec doesn't mention this and I am >>> getting >>> the feeling that this should just be a stupid list of hosts that >>> gets >>> announced >>> regardless if they are reachable or not. >>> >>> Jocke >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> > From dward@cisco.com Fri Mar 13 15:15:32 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31C23A69EB; Fri, 13 Mar 2009 15:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[AWL=-1.601, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, MANGLED_ONLINE=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RboXytXDK1dJ; Fri, 13 Mar 2009 15:15:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 99E9A3A6830; Fri, 13 Mar 2009 15:15:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,360,1233532800"; d="scan'208";a="141629744" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 13 Mar 2009 22:16:09 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2DMG9kU014629; Fri, 13 Mar 2009 15:16:09 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2DMG84L011985; Fri, 13 Mar 2009 22:16:09 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 18:16:08 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 18:16:08 -0400 From: David Ward To: Joan Cucchiara In-Reply-To: <004a01c99243$cd5bcf20$6401a8c0@JoanPC> X-Priority: 3 References: <001c01c99201$289e5ee0$6401a8c0@JoanPC> <004a01c99243$cd5bcf20$6401a8c0@JoanPC> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Mar 2009 17:16:07 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Mar 2009 22:16:08.0639 (UTC) FILETIME=[4F3704F0:01C9A429] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19578; t=1236982569; x=1237846569; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20MIB=20Dr.=20review=20of=20draft-ietf-os pf-ospfv3-mib-13.txt |Sender:=20; bh=7qS1TrkuThzVIc7Jwes+URy3betYOCPyNJayD5HfZ4g=; b=YtWZLiGhA/iTjcyvfgF5QRX4/C4p5DBNzekzPuWzWyhMLMtJmXKBuZuFiJ gkLI7NO0OlzjWsNqJX7gm68WfNTv2Hiz2rDnllJHOal4EGsrgJBOGhJj0Iie yhllRULzlb; Authentication-Results: sj-dkim-4; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Vishwas Manral , "MIB Doctors \(E-mail\)" , ospf@ietf.org Subject: Re: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2009 22:15:32 -0000 Just an ICMP-8 that it would be good to get this wrapped up and into WG and then IETF LC before and during IETF74 so we can have a bit of facetoface review if necessary. -DWard On Feb 18, 2009, at 9:40 PM, Joan Cucchiara wrote: > > Dan, > > Think we are down to one or two questions! > > Thanks, > -Joan > > >> >> ----- Original Message ----- From: "Daniel Joyal" >> To: "Joan Cucchiara" >> Cc: "Vishwas Manral" ; "Acee Lindem" > > >> Sent: Tuesday, February 17, 2009 5:18 PM >> Subject: RE: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt >> >> >> Hi Joan, >> >> Thanks for your patience in doing the review twice! >> See comments and questions in-line. >> >> Cheers, >> -Dan >> >>> -----Original Message----- >>> From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] >>> Sent: Wednesday, February 11, 2009 12:47 AM >>> To: ospf@ietf.org >>> Cc: Dan Romascanu; Abhay Roy; David Ward; Ronald Bonica; >>> Joyal, Daniel (BL60:SF23); Vishwas Manral; Acee Lindem >>> Subject: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt >>> >>> >>> Dan J. and Vishwas, >>> >>> First, I do apologize for being late with this review, thank >>> you for your patience. >>> >>> A great deal of work went into this >>> latest revision! Thanks for that! >>> >>> The MIB compilers' outputs are given, >>> followed by output from >>> IDNITS (http://tools.ietf.org/tools/idnits/) >>> followed by comments. >>> >>> Most all comments are from prior review. Please note, where >>> agreement was reached, the comments have been deleted. >>> >>> Thanks, >>> Joan >>> >>> >>> >>> smicngPRO output >>> ----------------- >>> >>> W: f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical to >>> access specified for "ospfv3StubRouterSupport" >>> W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value identical to >>> access specified for "ospfv3IfState" >>> >> >> I don't have access to smicngPRO. Is it complaining that >> MIN-ACCESS is equal to MAX-ACCESS for these objects? > > Yes. Please remove the following lines in the conformance > section, then these warnings will be resolved: > > OBJECT ospfv3StubRouterSupport > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > > OBJECT ospfv3IfState > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > >> >>> >>> smlint >>> ----------- >>> Line Severity Problem >>> 3096 5 warning: `InetAddress' should be used instead of >>> `InetAddressIPv6' >>> >> >> The message is intended to warn that the IP address is >> specific to a particular address family in cases where >> the MIB should support multiple address families. >> But the OSPFv3 MIB only supports the IPv6 address family. >> The OSPFv3 MIB is not compatible with OSPFv2 implementations. >> In this case, can the warning be ignored? > > Yes. > > >> >>> >>> IDNITS >>> ------ >>> idnits 2.11.01 >>> >>> tmp/draft-ietf-ospf-ospfv3-mib-13.txt: >>> >>> Checking boilerplate required by RFC 5378 and the IETF Trust (see >>> http://trustee.ietf.org/license-info): >>> >>> -------------------------------------------------------------- >>> -------------- >>> >>> ** It looks like you're using RFC 3978 boilerplate. You >>> should update this >>> to the boilerplate described in the IETF Trust License >>> Policy document >>> (see http://trustee.ietf.org/license-info), which is >>> required from >>> December 16, 2008. Version 1.34 of xml2rfc can be used >>> to produce >>> documents with boilerplate according to the mentioned >>> Trust License >>> Policy document. >>> >>> -- Found old boilerplate from RFC 3978 Section 5.1 on line 16. >>> >>> The obsolete RFC 3978 Section 5.1 text: >>> "By submitting this Internet-Draft, each author >>> represents that any >>> applicable patent or other IPR claims of which he or >>> she is aware >>> have been or will be disclosed, and any of which he or >>> she becomes >>> aware will be disclosed, in accordance with Section 6 >>> of BCP 79." >>> >>> -- Found old boilerplate from RFC 3978 Section 5.5 updated >>> by RFC 4748 on >>> line 4482. >>> >>> The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text: >>> "This document and the information contained herein are >>> provided on an >>> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >>> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET >>> SOCIETY, THE >>> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL >>> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO >>> ANY >>> WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL >>> NOT INFRINGE >>> ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY >>> OR FITNESS >>> FOR A PARTICULAR PURPOSE." >>> >>> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>> 1 on line 4493. >>> >>> The obsolete RFC 3979 Section 5 paragraph 1 text: >>> "The IETF takes no position regarding the validity or >>> scope of any >>> Intellectual Property Rights or other rights that might >>> be claimed >>> to pertain to the implementation or use of the >>> technology described >>> in this document or the extent to which any license under such >>> rights might or might not be available; nor does it >>> represent that >>> it has made any independent effort to identify any such rights. >>> Information on the procedures with respect to rights in RFC >>> documents can be found in BCP 78 and BCP 79." >>> >>> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>> 2 on line 4500. >>> >>> The obsolete RFC 3979 Section 5 paragraph 2 text: >>> "Copies of IPR disclosures made to the IETF Secretariat and any >>> assurances of licenses to be made available, or the result of >>> an >>> attempt made to obtain a general license or permission >>> for the use >>> of such proprietary rights by implementers or users of this >>> specification can be obtained from the IETF on-line IPR >>> repository >>> at http://www.ietf.org/ipr." >>> >>> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>> 3 on line 4506. >>> >>> The obsolete RFC 3979 Section 5 paragraph 3 text: >>> "The IETF invites any interested party to bring to its >>> attention any >>> copyrights, patents or patent applications, or other >>> proprietary >>> rights that may cover technology that may be required >>> to implement >>> this standard. Please address the information to the IETF at >>> ietf-ipr@ietf.org." >>> >>> >>> Checking nits according to >>> http://www.ietf.org/ietf/1id-guidelines.txt: >>> >>> -------------------------------------------------------------- >>> -------------- >>> >>> No issues found here. >>> >>> Checking nits according to http://www.ietf.org/ID-Checklist.html: >>> >>> -------------------------------------------------------------- >>> -------------- >>> >>> No issues found here. >>> >>> Miscellaneous warnings: >>> >>> -------------------------------------------------------------- >>> -------------- >>> >>> == The copyright year in the IETF Trust Copyright Line does >>> not match the >>> current year >>> >>> >>> Checking references for intended status: Proposed Standard >>> >>> -------------------------------------------------------------- >>> -------------- >>> >>> (See RFCs 3967 and 4897 for information about using >>> normative references >>> to lower-maturity documents in RFCs) >>> >>> No issues found here. >>> >>> Summary: 1 error (**), 1 warning (==), 5 comments (--). >>> >>> >>> ------------- >>> >> >> The boilerplate requirements changed after the last revision >> was posted. I will update the boilerplate such that no >> ID_NIT issues are raised. > > Thanks! > >> >>> > >>> > >>> > General Comments >>> > ----------------- >>> > >>> > 1) Need to have a read-only conformance. >>> >>> (NEW) NIT: would change the name from >>> ospfv3Compliance to ospfv3FullCompliance. >> >> Will change. >> >>> >>> >>> > >>> > 5) The MIB did not extract using mstrip (MIB tool). >>> > If possible, could this be fixed? >>> >>> This is a NIT, but still had trouble with mstrip tool. >> >> Does the tool take the standard ascii text file as input? >> I'll try to find a user guide for the tool to see what it >> is expecting regarding file formatting. >> > > I mention this as an FYI. > You do not need fix this for MIB DR review. As I recall, > the RFC Editor has fixed this kind of formatting issue in the past. > > >>> >>> >>> >>> 6) NEW: Use of InetAddressType and InetAddress In several >>> places in the MIB, the DESCRIPTION states something like >>> "only IPv6 global address type expected" and then InetAddress >>> (SIZE (16)) is given. >>> >>> First, I have to ask if this is truly the intention or would >>> having {unknown(0), ipv6(2) } and (SIZE (0|16)) be more >>> appropriate. >> >> How would an implementation behave for an unknown(0) address type? > > For this MIB, unknown(0) could be a placeholder as Rows were being > created, until the > real values became available (e.g. depends on how rows were created, > or > how an agent fills in the info from a cfg file during restarts). > > This would not be appropriate for InetAddressType that was part of > the Index. > > In this MIB, it might be appropriate for ospfv3VirtNbrAddressType > until the > actual value was available (e.g. for implementations that don't have > all the > information available at once during agent start/restart). > > To state my question another way, would adding Unknown and SIZE(0) > as options > be helpful (or provide more flexibility) for implementations? If > the answer is no, then > don't add it, if the answer is yes, then would seem appropriate to > add it. I'm not suggesting > that this be added, only asking the question. > > >> >>> >>> >>> Second, you restrict InetAddress at the object, but the >>> InetAddressType as part of the conformance. Could you please >>> choose one place or the other? >>> >>> I tend to prefer these restrictions be in the conformance >>> section because it is slightly less painful to revise the >>> conformance section, than to revise objects (but this is >>> just my opinion). >>> At any rate, would ask that you be consistent so restrict >>> both InetAddressType and InetAddress either in the object's >>> SYNTAX or add to the Conformance Section. >> >> OK. I'll restrict in conformance section. > > Thanks. > >> >>> >>> >>> >>> >>> >>> > >>> > >>> > Comments in Order of the document >>> > ---------------------------------- >>> > >>> >>> >>> (NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC to be >>> consistent with the names of the other TCs. >>> >> >> Will change. >> >>> >>> >>> > >>> > *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this >>> table may >>> > have a DEFVAL clause of zero (this is mentioned in the DESCRIPTION >>> > clauses). >>> > >>> >>> Not Done. Even though these are read-only objects, the >>> DEFVAL helps Agent developers so would add this, unless there >>> is a reason not to. >>> >> >> Will add DEFVAL. >> >>> > *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown) >>> > >>> > Please indicate what true(1) means in the DESCRIPTION >>> > >>> >>> Not Done. >> >> Will add. >> >>> >>> >>> >>> >>> > >>> > *) ospfv3HostTable >>> > >>> > Need to have a storageType object added to this table. >>> > >>> >>> Sorry, I was not correct when I said that a storageType was >>> needed. The MIB Guidelines specifies to either add a >>> storageType object OR add a description to the Entry (as you >>> have done in other >>> Tables.) To quote from rfc4181: >>> >>> - "There either MUST be one columnar object with a >>> SYNTAX value of >>> StorageType [RFC2579] and a MAX-ACCESS value of read-create, >>> or >>> else the row object (table entry) DESCRIPTION clause >>> MUST specify >>> what happens to dynamically-created rows after an >>> agent restart." >>> >>> >>> >>> In any case, the description in the StorageType object >>> conflicts with the Table's description. >>> >>> Also, if the agent is able to create/delete rows then this >>> needs to be documented...(from rfc4181): >>> >>> -"If the agent itself may also create and/or delete >>> rows, then the >>> conditions under which this can occur MUST be clearly >>> documented >>> in the row object DESCRIPTION clause." >>> >>> >>> Please clarify. >>> >> >> Does your comment apply to this table only? Can I remove the >> StorageType object and add to Description clause as was done >> with other tables? > > Yes. > >> Are the Description clauses for other >> like tables acceptible for this table? >> > > Yes. > >>> >>> > >>> > >>> > >>> > >>> > *) ospfv3HostEntry and ospfv3HostStorageType >>> > >>> >>> Same comment as above. >>> >> >> Same questions as above. >> >>> >>> >>> > >>> > *)ospfv3IfTable >>> > >>> >>> NIT: REFERENCE clause "parameters parameters", please change >>> to "parameters" >>> >> >> Will change. >> >>> >>> >>> >>> *) ospfv3IfAdminStat >>> Please rename to ospfv3IfAdminStatus >>> >> >> Will change. > > Should also have asked about ospfv3AdminStat (the scalar) > also. Could you rename this to ospfv3AdminStatus? > > Also, if the ospfv3IfAdminStatus is enabled, but the > ospfv3AdminStatus (scalar) > is disabled, then does this mean that all the interfaces behave as > if they are disabled? > > In other words, does the scalar (ospfv3AdminStatus) takes precedence > over the > individual interface's ospfv3IfAdminStatus value? > > If so, could you please add a mention of this to the description of > ospfv3IfAdminStatus and > also ospfv3IfState? > > >> >>> >>> >>> *) Why is there no ospfv3IfOperStatus object? >>> Typically, the AdminStatus if for setting and the OperStatus >>> is used to read if the status changes. I think both would be >>> appropriate here. >>> Please comment. >>> >> >> The object ospfv3IfState gives the operational state of the >> OSPF interface. > > Okay, please add a Reference for this. > > As mentioned above in the discussion of ospfv3IfAdminStatus, please > expand the > description clause to mention how the adminStatuses effect this > object. > >> >>> >>> >>> > >>> > >>> > *) ospfv3NbrTable and ospfv3CfgNbrTable >>> > >>> > What is the relationship between these 2 tables? >>> > The indexing is different between the 2 tables and so I'm >>> wondering >>> > what the relationship is between them. >>> > >>> >>> So to restate my question, there is an ospfv3CfgNbrEntry >>> which is a single neighbor that has been configured and there >>> is an ospfv3NbrEntry which contains info about a single >>> neighbor, so does the ospfv3CfgNbrEntry also have an >>> associated ospfv3NbrEntry? >> >> Yes it does. Configured neighbors are used when running OSPF >> on NBMA subnets (OSPF nbma and point-to-multipoint link types). >> The configured neighbors table just gives OSPF information >> for sending hellos to potential neighbors. Once a hello is >> received from a neighbor in the configured neighbor table, >> an entry for that neighbor is created in the neighbor table >> and adjacency state is maintained there. Neighbors on multi-access >> or point-to-point subnets can use multicast addressing, so >> only neighbor table entries are created. >> >>> >>> If so, can some explanation be given on how to look up a >>> related entry in the ospfv3NbrEntry table once the >>> ospfv3CfgNbrEntry is populated? >> >> OK. I will better describe the relationship between >> the tables. > > Thanks for the clarification. If you can include in these table > DESCRIPTIONs > what you explained above, that would be great. > >> >>> >>> If there is no relationship between these two tables then >>> please state that in the DESCRIPTION clauses for the tables. >>> >>> >>> >>> *) ospfv3NbrRtrId >>> >>> NIT: says "32-bit integer" and should be "32-bit unsigned integer" >> >> Will change. >> >>> >>> >>> > >>> > >>> > >>> > Notifications >>> > ------------ >>> > >>> > In general the accessible-for-notify objects should probably be >>> > changed into read-only objects. Additionally, a timestamp >>> should be >>> > associated with some of these. There is an assumption made >>> that it is >>> > better to send out notifications rather than poll, but I'd >>> rather give >>> > the operator the choice on that. >>> > >>> > >>> >>> Please comment. >> >> I've seen accessible-for-notify used in other MIBs, but I defer >> to your expert judgement on this. Which objects to you think >> need a timestamp? >> > > Dan, Sorry I made a mistake here. > I think I didn't quite understand how these accessible-for-notify > objects were > used in several notifications, but now I see, so timestamps don't make > sense, neither does changing these objects to read-only. > > Please leave them as accessible-for-notify BUT please also modify > the DESCRIPTION > clause which is confusing. Since these are not read-only, please > remove the phrase > which begins "When the last value...." > > >>> >>> *) ospfv3PacketSrc >>> >>> Same sort of issue as discussed in the General Comment >>> Section above. This one especially mentions returning 0, but it >>> is an >>> InetAddressIPv6 which has OCTET STRING (SIZE (16)) so please >>> clarify what is expected by the agent. >> >> I believe the text about the zero value is derived from the OSPFv2 >> MIB >> comment by a MIB reviewer. >> >> ospfPacketSrc OBJECT-TYPE >> SYNTAX IpAddress >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IP address of an inbound packet that cannot >> be identified by a neighbor instance. When >> the last value of a trap using this object is >> needed, but no traps of that type have been sent, >> this value pertaining to this object should >> be returned as 0.0.0.0." >> ::= { ospfTrapControl 4 } >> >> I thought the same description would apply to OSPFv3, but instead >> returning a value of an octet string of all zeros. Does >> this make sense? > > Since the object has a STATUS of accessible-for-notify > the above suggestion of modifying the DESCRIPTION clause to remove > the "When the last value...." will resolve the issue. > > If this was a read-only object then either the "all zeros" > or using InetAddress SIZE(0 | 16) so that a zero-length octet string > would be returned if a > read was done of this address but there was not yet a valid value > for it. > > > -Joan > > >> >>> >>> >>> > >>> > Compliance Statements >>> > ------------------------- >>> > >>> >>> *) NIT: ospfv3Compliance should be renamed to ospfv3FullCompliance >> >> Will change. >> >>> >>> >>> >>> > From jsmith4112003@yahoo.co.uk Sun Mar 15 18:02:39 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25FF3A6B88 for ; Sun, 15 Mar 2009 18:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxkgzAsAwB-C for ; Sun, 15 Mar 2009 18:02:39 -0700 (PDT) Received: from web27205.mail.ukl.yahoo.com (web27205.mail.ukl.yahoo.com [217.146.182.95]) by core3.amsl.com (Postfix) with SMTP id CE7F23A6B6A for ; Sun, 15 Mar 2009 18:02:38 -0700 (PDT) Received: (qmail 24779 invoked by uid 60001); 16 Mar 2009 01:03:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1237165399; bh=ZwAa1FrS0ON1bZb5B6S5P9bCReWCvc0dbkm4LRR+3ik=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=u3STptZNC1NDxT2xZzVGRCEcP199FA8XD/KV62fhLYwmnnDhjUlDmF/5Pui5AfgqequKJnyhzjdSj3Er+RsfKWoa8qDcZ2Td0ABvgk9a47fsSHpuztdynalVcpmqRHmLM7RbCGVXz/0kLChiHM/zm5oXV3zySv17fFkjALXPH38= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BeHQQfhdmgC6q7RkW6UZF3toxrf3wl2/ghVdRkgssdt0xW8rJr1JNgTihBJFJJXHJK1utE6Scsb+9YYBcNh16IBntxHgGWEbhrHROiLL2+mHdPgwYCUmc4oG6zz9/8I367UujuWn0t8kWOjXI7ZVgRDZaWZ5y/Nd84hO6K6bQto=; Message-ID: <414371.22999.qm@web27205.mail.ukl.yahoo.com> X-YMail-OSG: dw62K9AVM1mtRR4HS7_09BaY6S9Atnz9c0wCAXaMf_u_tjgxXzYSyRB4JWUyMkzX3gwAxcSmhzi4ZWqjwklqBSEYuGB8GRXTkdiiV_GHcqOHSenJCeRAVDbTPFzbJ35j1h.dXWVuj6JbL3iX3VTzDEaX503Pzkjf0awlnjXqaMXmw9fnI3Vk20QguX68VQ-- Received: from [122.167.240.23] by web27205.mail.ukl.yahoo.com via HTTP; Mon, 16 Mar 2009 01:03:19 GMT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 Date: Mon, 16 Mar 2009 01:03:19 +0000 (GMT) From: John Smith To: OSPF List MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [OSPF] OSPF HMAC-SHA Cryptographic Authentication X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 01:02:40 -0000 Hi OSPFers,=0A=0AI was reading draft-ietf-ospf-hmac-sha-03.txt and i think = its good and very readable.However, a small nit with the draft: All referen= ces to other draft sections are off by 1 - thus a reference to section 3 an= d 5 in section 5.1 should be 4 and 6 really. :-)=0A=0AIts been around for a= long time now and i have never seen any opposition/changes. Is there a rea= son why its not close to WG LC yet?=0A=0AJohn=0A=0AP.S.=0A=0AIt seems as Da= ve reflected some time back, that OSPF is lagging far behind IS-IS and RIP = as these WGs=0A(i know there is none for RIP) have already come out with RF= Cs=0Aextending ISIS/RIP for HMAC-SHA support, while OSPF is still strugglin= g on.=0A=0A=0A From prvs=319f3e2b4=acee@redback.com Mon Mar 16 07:02:57 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0588E3A6BE9 for ; Mon, 16 Mar 2009 07:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neq1xMGn94Aw for ; Mon, 16 Mar 2009 07:02:53 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id A4AE73A63EC for ; Mon, 16 Mar 2009 07:02:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,373,1233561600"; d="scan'208,217";a="317720" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 16 Mar 2009 07:03:35 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BD33B5E269B for ; Mon, 16 Mar 2009 07:03:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20615-03 for ; Mon, 16 Mar 2009 07:03:35 -0700 (PDT) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 562255E269A for ; Mon, 16 Mar 2009 07:03:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) To: OSPF List Message-Id: <11A61AB5-E5F6-47D0-9442-2EB854B9C3E4@redback.com> Content-Type: multipart/alternative; boundary=Apple-Mail-38--940509729 From: Acee Lindem Date: Mon, 16 Mar 2009 10:03:31 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [OSPF] FW: [MIB-DOCTORS] MIB Dr. review ofdraft-ietf-ospf-ospfv3-mib-13.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 14:05:20 -0000 --Apple-Mail-38--940509729 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed From: "Romascanu, Dan (Dan)" Date: March 16, 2009 9:54:51 AM EDT To: "David Ward" , "Joan Cucchiara" Cc: "Vishwas Manral" , "MIB Doctors (E-mail)" , "Dan Joyal" , , "Acee Lindem" , "Abhay Roy" Subject: RE: [MIB-DOCTORS] MIB Dr. review ofdraft-ietf-ospf-ospfv3- mib-13.txt My understanding is that the ball is in the editor's court. Am I wrong? Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org > [mailto:mib-doctors-bounces@ietf.org] On Behalf Of David Ward > Sent: Saturday, March 14, 2009 12:16 AM > To: Joan Cucchiara > Cc: Vishwas Manral; MIB Doctors (E-mail); Dan Joyal; > ospf@ietf.org; David Ward; Acee Lindem; Abhay Roy > Subject: Re: [MIB-DOCTORS] MIB Dr. review > ofdraft-ietf-ospf-ospfv3-mib-13.txt > > Just an ICMP-8 that it would be good to get this wrapped up > and into WG and then IETF LC before and during IETF74 so we > can have a bit of facetoface review if necessary. > > -DWard > > On Feb 18, 2009, at 9:40 PM, Joan Cucchiara wrote: > >> >> Dan, >> >> Think we are down to one or two questions! >> >> Thanks, >> -Joan >> >> >>> >>> ----- Original Message ----- From: "Daniel Joyal" > >>> To: "Joan Cucchiara" >>> Cc: "Vishwas Manral" ; "Acee Lindem" >>> >>> >>> Sent: Tuesday, February 17, 2009 5:18 PM >>> Subject: RE: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt >>> >>> >>> Hi Joan, >>> >>> Thanks for your patience in doing the review twice! >>> See comments and questions in-line. >>> >>> Cheers, >>> -Dan >>> >>>> -----Original Message----- >>>> From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] >>>> Sent: Wednesday, February 11, 2009 12:47 AM >>>> To: ospf@ietf.org >>>> Cc: Dan Romascanu; Abhay Roy; David Ward; Ronald Bonica; Joyal, >>>> Daniel (BL60:SF23); Vishwas Manral; Acee Lindem >>>> Subject: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt >>>> >>>> >>>> Dan J. and Vishwas, >>>> >>>> First, I do apologize for being late with this review, > thank you for >>>> your patience. >>>> >>>> A great deal of work went into this >>>> latest revision! Thanks for that! >>>> >>>> The MIB compilers' outputs are given, followed by output > from IDNITS >>>> (http://tools.ietf.org/tools/idnits/) >>>> followed by comments. >>>> >>>> Most all comments are from prior review. Please note, where >>>> agreement was reached, the comments have been deleted. >>>> >>>> Thanks, >>>> Joan >>>> >>>> >>>> >>>> smicngPRO output >>>> ----------------- >>>> >>>> W: f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical > to access >>>> specified for "ospfv3StubRouterSupport" >>>> W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value identical > to access >>>> specified for "ospfv3IfState" >>>> >>> >>> I don't have access to smicngPRO. Is it complaining that > MIN-ACCESS >>> is equal to MAX-ACCESS for these objects? >> >> Yes. Please remove the following lines in the conformance section, >> then these warnings will be resolved: >> >> OBJECT ospfv3StubRouterSupport >> MIN-ACCESS read-only >> DESCRIPTION >> "Write access is not required." >> >> >> OBJECT ospfv3IfState >> MIN-ACCESS read-only >> DESCRIPTION >> "Write access is not required." >> >> >>> >>>> >>>> smlint >>>> ----------- >>>> Line Severity Problem >>>> 3096 5 warning: `InetAddress' should be used instead of >>>> `InetAddressIPv6' >>>> >>> >>> The message is intended to warn that the IP address is > specific to a >>> particular address family in cases where the MIB should support >>> multiple address families. >>> But the OSPFv3 MIB only supports the IPv6 address family. >>> The OSPFv3 MIB is not compatible with OSPFv2 implementations. >>> In this case, can the warning be ignored? >> >> Yes. >> >> >>> >>>> >>>> IDNITS >>>> ------ >>>> idnits 2.11.01 >>>> >>>> tmp/draft-ietf-ospf-ospfv3-mib-13.txt: >>>> >>>> Checking boilerplate required by RFC 5378 and the IETF Trust (see >>>> http://trustee.ietf.org/license-info): >>>> >>>> -------------------------------------------------------------- >>>> -------------- >>>> >>>> ** It looks like you're using RFC 3978 boilerplate. You should >>>> update this >>>> to the boilerplate described in the IETF Trust License Policy >>>> document >>>> (see http://trustee.ietf.org/license-info), which is required >>>> from >>>> December 16, 2008. Version 1.34 of xml2rfc can be used to >>>> produce >>>> documents with boilerplate according to the mentioned Trust >>>> License >>>> Policy document. >>>> >>>> -- Found old boilerplate from RFC 3978 Section 5.1 on line 16. >>>> >>>> The obsolete RFC 3978 Section 5.1 text: >>>> "By submitting this Internet-Draft, each author > represents that >>>> any >>>> applicable patent or other IPR claims of which he or she is >>>> aware >>>> have been or will be disclosed, and any of which he or she >>>> becomes >>>> aware will be disclosed, in accordance with Section 6 of BCP >>>> 79." >>>> >>>> -- Found old boilerplate from RFC 3978 Section 5.5 > updated by RFC >>>> 4748 on >>>> line 4482. >>>> >>>> The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text: >>>> "This document and the information contained herein > are provided >>>> on an >>>> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >>>> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET > SOCIETY, >>>> THE >>>> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE > DISCLAIM ALL >>>> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO >>>> ANY >>>> WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT >>>> INFRINGE >>>> ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR >>>> FITNESS >>>> FOR A PARTICULAR PURPOSE." >>>> >>>> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>>> 1 on line 4493. >>>> >>>> The obsolete RFC 3979 Section 5 paragraph 1 text: >>>> "The IETF takes no position regarding the validity or > scope of >>>> any >>>> Intellectual Property Rights or other rights that might be >>>> claimed >>>> to pertain to the implementation or use of the technology >>>> described >>>> in this document or the extent to which any license > under such >>>> rights might or might not be available; nor does it > represent >>>> that >>>> it has made any independent effort to identify any > such rights. >>>> Information on the procedures with respect to rights in RFC >>>> documents can be found in BCP 78 and BCP 79." >>>> >>>> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>>> 2 on line 4500. >>>> >>>> The obsolete RFC 3979 Section 5 paragraph 2 text: >>>> "Copies of IPR disclosures made to the IETF > Secretariat and any >>>> assurances of licenses to be made available, or the > result of >>>> an >>>> attempt made to obtain a general license or > permission for the >>>> use >>>> of such proprietary rights by implementers or users of this >>>> specification can be obtained from the IETF on-line IPR >>>> repository >>>> at http://www.ietf.org/ipr." >>>> >>>> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>>> 3 on line 4506. >>>> >>>> The obsolete RFC 3979 Section 5 paragraph 3 text: >>>> "The IETF invites any interested party to bring to > its attention >>>> any >>>> copyrights, patents or patent applications, or other >>>> proprietary >>>> rights that may cover technology that may be required to >>>> implement >>>> this standard. Please address the information to the IETF at >>>> ietf-ipr@ietf.org." >>>> >>>> >>>> Checking nits according to >>>> http://www.ietf.org/ietf/1id-guidelines.txt: >>>> >>>> -------------------------------------------------------------- >>>> -------------- >>>> >>>> No issues found here. >>>> >>>> Checking nits according to http://www.ietf.org/ID-Checklist.html: >>>> >>>> -------------------------------------------------------------- >>>> -------------- >>>> >>>> No issues found here. >>>> >>>> Miscellaneous warnings: >>>> >>>> -------------------------------------------------------------- >>>> -------------- >>>> >>>> == The copyright year in the IETF Trust Copyright Line does not >>>> match the >>>> current year >>>> >>>> >>>> Checking references for intended status: Proposed Standard >>>> >>>> -------------------------------------------------------------- >>>> -------------- >>>> >>>> (See RFCs 3967 and 4897 for information about using normative >>>> references >>>> to lower-maturity documents in RFCs) >>>> >>>> No issues found here. >>>> >>>> Summary: 1 error (**), 1 warning (==), 5 comments (--). >>>> >>>> >>>> ------------- >>>> >>> >>> The boilerplate requirements changed after the last revision was >>> posted. I will update the boilerplate such that no ID_NIT > issues are >>> raised. >> >> Thanks! >> >>> >>>>> >>>>> >>>>> General Comments >>>>> ----------------- >>>>> >>>>> 1) Need to have a read-only conformance. >>>> >>>> (NEW) NIT: would change the name from ospfv3Compliance to >>>> ospfv3FullCompliance. >>> >>> Will change. >>> >>>> >>>> >>>>> >>>>> 5) The MIB did not extract using mstrip (MIB tool). >>>>> If possible, could this be fixed? >>>> >>>> This is a NIT, but still had trouble with mstrip tool. >>> >>> Does the tool take the standard ascii text file as input? >>> I'll try to find a user guide for the tool to see what it is >>> expecting regarding file formatting. >>> >> >> I mention this as an FYI. >> You do not need fix this for MIB DR review. As I recall, the RFC >> Editor has fixed this kind of formatting issue in the past. >> >> >>>> >>>> >>>> >>>> 6) NEW: Use of InetAddressType and InetAddress In several > places in >>>> the MIB, the DESCRIPTION states something like "only IPv6 global >>>> address type expected" and then InetAddress (SIZE (16)) is given. >>>> >>>> First, I have to ask if this is truly the intention or > would having >>>> {unknown(0), ipv6(2) } and (SIZE (0|16)) be more appropriate. >>> >>> How would an implementation behave for an unknown(0) address type? >> >> For this MIB, unknown(0) could be a placeholder as Rows were being >> created, until the real values became available (e.g. > depends on how >> rows were created, or how an agent fills in the info from a > cfg file >> during restarts). >> >> This would not be appropriate for InetAddressType that was > part of the >> Index. >> >> In this MIB, it might be appropriate for ospfv3VirtNbrAddressType >> until the actual value was available (e.g. for implementations that >> don't have all the information available at once during agent >> start/restart). >> >> To state my question another way, would adding Unknown > and SIZE(0) >> as options be helpful (or provide more flexibility) for >> implementations? If the answer is no, then don't add it, if the >> answer is yes, then would seem appropriate to add it. I'm not >> suggesting that this be added, only asking the question. >> >> >>> >>>> >>>> >>>> Second, you restrict InetAddress at the object, but the >>>> InetAddressType as part of the conformance. Could you > please choose >>>> one place or the other? >>>> >>>> I tend to prefer these restrictions be in the conformance section >>>> because it is slightly less painful to revise the conformance >>>> section, than to revise objects (but this is just my opinion). >>>> At any rate, would ask that you be consistent so restrict both >>>> InetAddressType and InetAddress either in the object's > SYNTAX or add >>>> to the Conformance Section. >>> >>> OK. I'll restrict in conformance section. >> >> Thanks. >> >>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> Comments in Order of the document >>>>> ---------------------------------- >>>>> >>>> >>>> >>>> (NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC to be >>>> consistent with the names of the other TCs. >>>> >>> >>> Will change. >>> >>>> >>>> >>>>> >>>>> *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this >>>> table may >>>>> have a DEFVAL clause of zero (this is mentioned in the > DESCRIPTION >>>>> clauses). >>>>> >>>> >>>> Not Done. Even though these are read-only objects, the > DEFVAL helps >>>> Agent developers so would add this, unless there is a > reason not to. >>>> >>> >>> Will add DEFVAL. >>> >>>>> *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown) >>>>> >>>>> Please indicate what true(1) means in the DESCRIPTION >>>>> >>>> >>>> Not Done. >>> >>> Will add. >>> >>>> >>>> >>>> >>>> >>>>> >>>>> *) ospfv3HostTable >>>>> >>>>> Need to have a storageType object added to this table. >>>>> >>>> >>>> Sorry, I was not correct when I said that a storageType was >>>> needed. The MIB Guidelines specifies to either add a >>>> storageType object OR add a description to the Entry (as you >>>> have done in other >>>> Tables.) To quote from rfc4181: >>>> >>>> - "There either MUST be one columnar object with a >>>> SYNTAX value of >>>> StorageType [RFC2579] and a MAX-ACCESS value of > read-create, >>>> or >>>> else the row object (table entry) DESCRIPTION clause >>>> MUST specify >>>> what happens to dynamically-created rows after an >>>> agent restart." >>>> >>>> >>>> >>>> In any case, the description in the StorageType object >>>> conflicts with the Table's description. >>>> >>>> Also, if the agent is able to create/delete rows then this >>>> needs to be documented...(from rfc4181): >>>> >>>> -"If the agent itself may also create and/or delete >>>> rows, then the >>>> conditions under which this can occur MUST be clearly >>>> documented >>>> in the row object DESCRIPTION clause." >>>> >>>> >>>> Please clarify. >>>> >>> >>> Does your comment apply to this table only? Can I remove the >>> StorageType object and add to Description clause as was done >>> with other tables? >> >> Yes. >> >>> Are the Description clauses for other >>> like tables acceptible for this table? >>> >> >> Yes. >> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> *) ospfv3HostEntry and ospfv3HostStorageType >>>>> >>>> >>>> Same comment as above. >>>> >>> >>> Same questions as above. >>> >>>> >>>> >>>>> >>>>> *)ospfv3IfTable >>>>> >>>> >>>> NIT: REFERENCE clause "parameters parameters", please change >>>> to "parameters" >>>> >>> >>> Will change. >>> >>>> >>>> >>>> >>>> *) ospfv3IfAdminStat >>>> Please rename to ospfv3IfAdminStatus >>>> >>> >>> Will change. >> >> Should also have asked about ospfv3AdminStat (the scalar) >> also. Could you rename this to ospfv3AdminStatus? >> >> Also, if the ospfv3IfAdminStatus is enabled, but the >> ospfv3AdminStatus (scalar) >> is disabled, then does this mean that all the interfaces behave as >> if they are disabled? >> >> In other words, does the scalar (ospfv3AdminStatus) takes > precedence >> over the >> individual interface's ospfv3IfAdminStatus value? >> >> If so, could you please add a mention of this to the > description of >> ospfv3IfAdminStatus and >> also ospfv3IfState? >> >> >>> >>>> >>>> >>>> *) Why is there no ospfv3IfOperStatus object? >>>> Typically, the AdminStatus if for setting and the OperStatus >>>> is used to read if the status changes. I think both would be >>>> appropriate here. >>>> Please comment. >>>> >>> >>> The object ospfv3IfState gives the operational state of the >>> OSPF interface. >> >> Okay, please add a Reference for this. >> >> As mentioned above in the discussion of > ospfv3IfAdminStatus, please >> expand the >> description clause to mention how the adminStatuses effect this >> object. >> >>> >>>> >>>> >>>>> >>>>> >>>>> *) ospfv3NbrTable and ospfv3CfgNbrTable >>>>> >>>>> What is the relationship between these 2 tables? >>>>> The indexing is different between the 2 tables and so I'm >>>> wondering >>>>> what the relationship is between them. >>>>> >>>> >>>> So to restate my question, there is an ospfv3CfgNbrEntry >>>> which is a single neighbor that has been configured and there >>>> is an ospfv3NbrEntry which contains info about a single >>>> neighbor, so does the ospfv3CfgNbrEntry also have an >>>> associated ospfv3NbrEntry? >>> >>> Yes it does. Configured neighbors are used when running OSPF >>> on NBMA subnets (OSPF nbma and point-to-multipoint link types). >>> The configured neighbors table just gives OSPF information >>> for sending hellos to potential neighbors. Once a hello is >>> received from a neighbor in the configured neighbor table, >>> an entry for that neighbor is created in the neighbor table >>> and adjacency state is maintained there. Neighbors on multi-access >>> or point-to-point subnets can use multicast addressing, so >>> only neighbor table entries are created. >>> >>>> >>>> If so, can some explanation be given on how to look up a >>>> related entry in the ospfv3NbrEntry table once the >>>> ospfv3CfgNbrEntry is populated? >>> >>> OK. I will better describe the relationship between >>> the tables. >> >> Thanks for the clarification. If you can include in these table >> DESCRIPTIONs >> what you explained above, that would be great. >> >>> >>>> >>>> If there is no relationship between these two tables then >>>> please state that in the DESCRIPTION clauses for the tables. >>>> >>>> >>>> >>>> *) ospfv3NbrRtrId >>>> >>>> NIT: says "32-bit integer" and should be "32-bit > unsigned integer" >>> >>> Will change. >>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> Notifications >>>>> ------------ >>>>> >>>>> In general the accessible-for-notify objects should probably be >>>>> changed into read-only objects. Additionally, a timestamp >>>> should be >>>>> associated with some of these. There is an assumption made >>>> that it is >>>>> better to send out notifications rather than poll, but I'd >>>> rather give >>>>> the operator the choice on that. >>>>> >>>>> >>>> >>>> Please comment. >>> >>> I've seen accessible-for-notify used in other MIBs, but I defer >>> to your expert judgement on this. Which objects to you think >>> need a timestamp? >>> >> >> Dan, Sorry I made a mistake here. >> I think I didn't quite understand how these accessible-for-notify >> objects were >> used in several notifications, but now I see, so timestamps > don't make >> sense, neither does changing these objects to read-only. >> >> Please leave them as accessible-for-notify BUT please also modify >> the DESCRIPTION >> clause which is confusing. Since these are not read-only, please >> remove the phrase >> which begins "When the last value...." >> >> >>>> >>>> *) ospfv3PacketSrc >>>> >>>> Same sort of issue as discussed in the General Comment >>>> Section above. This one especially mentions returning 0, but it >>>> is an >>>> InetAddressIPv6 which has OCTET STRING (SIZE (16)) so please >>>> clarify what is expected by the agent. >>> >>> I believe the text about the zero value is derived from > the OSPFv2 >>> MIB >>> comment by a MIB reviewer. >>> >>> ospfPacketSrc OBJECT-TYPE >>> SYNTAX IpAddress >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The IP address of an inbound packet that cannot >>> be identified by a neighbor instance. When >>> the last value of a trap using this object is >>> needed, but no traps of that type have been sent, >>> this value pertaining to this object should >>> be returned as 0.0.0.0." >>> ::= { ospfTrapControl 4 } >>> >>> I thought the same description would apply to OSPFv3, but instead >>> returning a value of an octet string of all zeros. Does >>> this make sense? >> >> Since the object has a STATUS of accessible-for-notify >> the above suggestion of modifying the DESCRIPTION clause to remove >> the "When the last value...." will resolve the issue. >> >> If this was a read-only object then either the "all zeros" >> or using InetAddress SIZE(0 | 16) so that a zero-length > octet string >> would be returned if a >> read was done of this address but there was not yet a valid value >> for it. >> >> >> -Joan >> >> >>> >>>> >>>> >>>>> >>>>> Compliance Statements >>>>> ------------------------- >>>>> >>>> >>>> *) NIT: ospfv3Compliance should be renamed to ospfv3FullCompliance >>> >>> Will change. >>> >>>> >>>> >>>> >>>> >> > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > > --Apple-Mail-38--940509729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
From: "Romascanu, Dan (Dan)" = <dromasca@avaya.com>
Date: March 16, 2009 9:54:51 AM = EDT
To: "David Ward" <dward@cisco.com>, "Joan Cucchiara" = <jcucchiara@mindspring.com>
Cc: "Vishwas Manral" <vishwas@ipinfusion.com>, "MIB = Doctors (E-mail)" <mib-doctors@ietf.org>, "Dan = Joyal" <djoyal@nortel.com>, = <ospf@ietf.org>, "Acee Lindem" = <acee@redback.com>, "Abhay = Roy" <akr@cisco.com>
Subject: RE: [MIB-DOCTORS] MIB Dr. review = ofdraft-ietf-ospf-ospfv3-mib-13.txt


My = understanding is that the ball is in the editor's court. Am I = wrong?=A0



-----Original = Message-----
Sent: = Saturday, March 14, 2009 12:16 AM
To: Joan = Cucchiara
Cc: Vishwas Manral; MIB Doctors = (E-mail); Dan Joyal;=A0
ospf@ietf.org; David Ward; Acee = Lindem; Abhay Roy
Subject: Re: [MIB-DOCTORS] MIB = Dr. review=A0
ofdraft-ietf-ospf-ospfv3-mib-13.txt

Just an = ICMP-8=A0 that it would be = good to get this wrapped up=A0
and into = WG and then IETF LC before and during IETF74 so we=A0
can have = a bit of facetoface review if necessary.


On Feb 18, 2009, at 9:40 PM, Joan Cucchiara = wrote:

=
Dan,

Think we = are down to one or two questions!

=A0Thanks,
=A0=A0 = -Joan



----- Original Message ----- From: "Daniel = Joyal"=A0
=
=
To: "Joan Cucchiara" <jcucchiara@mindspring.com>
Cc: "Vishwas Manral" <vishwas@ipinfusion.com>; = "Acee Lindem"=A0

=
Sent: Tuesday, February 17, 2009 = 5:18 PM
Subject: RE: MIB Dr. review of = draft-ietf-ospf-ospfv3-mib-13.txt


Hi Joan,

Thanks for your patience in = doing the review twice!
See comments = and questions in-line.
Cheers,
-Dan

From: Joan = Cucchiara [mailto:jcucchiara@mindspring.com= ]
Sent: Wednesday, February 11, = 2009 12:47 AM
Cc: Dan Romascanu; Abhay Roy; David Ward; Ronald = Bonica; Joyal,=A0
Daniel (BL60:SF23); Vishwas Manral; Acee = Lindem
Subject: MIB Dr. review of = draft-ietf-ospf-ospfv3-mib-13.txt


Dan J. and Vishwas,

First, I do = apologize for being late with this review,=A0
=
thank you = for=A0
your patience.

A great deal of work went into = this
latest revision!=A0 Thanks for that!

The MIB = compilers' outputs are given, followed by output=A0
=
from = IDNITS=A0
followed by comments.

Most all = comments are from prior review. Please note, where=A0

=A0Joan



smicngPRO output
-----------------

W: = f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical=A0
=
to = access=A0
specified for "ospfv3StubRouterSupport"
W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value = identical=A0
=
to = access=A0
specified for "ospfv3IfState"


I don't = have access to smicngPRO. Is it complaining that=A0
=
MIN-ACCESS=A0
is equal to = MAX-ACCESS for these objects?

Yes.=A0 Please remove the following = lines in the conformance section,=A0
then = these warnings will be resolved:

OBJECT = ospfv3StubRouterSupport
=A0 =A0 =A0 =A0 MIN-ACCESS = read-only
=A0 =A0 =A0 =A0 = DESCRIPTION
=A0=A0 =A0 =A0 =A0 =A0 =A0 "Write = access is not required."


OBJECT ospfv3IfState
=A0 =A0 =A0 =A0 MIN-ACCESS = read-only
=A0 =A0 =A0 =A0 = DESCRIPTION
=A0=A0 =A0 =A0 =A0 =A0 =A0 "Write = access is not required."


=

smlint
-----------
Line=A0 Severity =A0 Problem
3096 5 warning: `InetAddress' should be used instead = of=A0
`InetAddressIPv6'


The message = is intended to warn that the IP address is=A0
=
specific to a=A0
particular = address family in cases where the MIB should support=A0
multiple = address families.
But the OSPFv3 MIB only supports = the IPv6 address family.
The OSPFv3 = MIB is not compatible with OSPFv2 implementations.
In this case, can the warning be ignored?
=

Yes.


=

IDNITS
------
idnits = 2.11.01

tmp/draft-ietf-ospf-ospfv3-mib-13.txt:

=A0Checking boilerplate required = by RFC 5378 and the IETF Trust (see

--------------

=A0** It looks like you're using = RFC 3978 boilerplate.=A0 = You should=A0
update this
=A0 =A0 to the boilerplate = described in the IETF Trust License Policy=A0
=A0 =A0 (see http://trustee.ietf.org/lice= nse-info), which is required=A0
=A0 =A0 December 16, 2008.=A0 Version 1.34 of xml2rfc can = be used to=A0
produce
=A0 =A0 documents with = boilerplate according to the mentioned Trust=A0
=A0 =A0 Policy = document.

=A0-- = Found old boilerplate from RFC 3978 Section 5.1 on line 16.

=A0 =A0 The obsolete RFC 3978 = Section 5.1 text:
=A0 =A0 "By submitting this = Internet-Draft, each author=A0
=
represents = that=A0
any
=A0=A0 =A0 applicable patent or = other IPR claims of which he or she is=A0
=A0=A0 =A0 have been or will be = disclosed, and any of which he or she=A0
=A0=A0 =A0 aware will be = disclosed, in accordance with Section 6 of BCP=A0

=A0-- = Found old boilerplate from RFC 3978 Section 5.5=A0
=
updated by = RFC=A0
4748 on
=A0 =A0 line 4482.

=A0 =A0 The obsolete RFC 3978 = Section 5.5 updated by RFC 4748 text:
=A0 =A0 "This document and the = information contained herein=A0
=
are = provided=A0
=
on an
=A0=A0 =A0 = "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION = HE/SHE
=A0=A0 =A0 REPRESENTS OR IS = SPONSORED BY (IF ANY), THE INTERNET=A0
=
SOCIETY,=A0
THE
=A0=A0 =A0 IETF TRUST AND THE = INTERNET ENGINEERING TASK FORCE=A0
=
DISCLAIM = ALL
=A0=A0 =A0 WARRANTIES, EXPRESS OR = IMPLIED, INCLUDING BUT NOT LIMITED TO=A0
=A0=A0 =A0 WARRANTY THAT THE USE = OF THE INFORMATION HEREIN WILL NOT=A0
=A0=A0 =A0 ANY RIGHTS OR ANY = IMPLIED WARRANTIES OF MERCHANTABILITY OR=A0
=A0=A0 =A0 FOR A PARTICULAR = PURPOSE."

=A0-- = Found old boilerplate from RFC 3979 Section 5 paragraph
1 on line 4493.

=A0 =A0 The obsolete RFC 3979 = Section 5 paragraph 1 text:
=A0 =A0 "The IETF takes no = position regarding the validity or=A0
=
scope of=A0
any
=A0=A0 =A0 Intellectual Property = Rights or other rights that might be=A0
=A0=A0 =A0 to pertain to the = implementation or use of the technology=A0
=A0=A0 =A0 in this document or = the extent to which any license=A0
=
under = such
=A0=A0 =A0 rights might or might = not be available; nor does it=A0
=
=A0
=
that
=A0=A0 =A0 = it has made any independent effort to identify any=A0
=
such = rights.
=A0=A0 =A0 Information on the = procedures with respect to rights in RFC
=A0=A0 =A0 documents can be found = in BCP 78 and BCP 79."
=A0-- Found old boilerplate from = RFC 3979 Section 5 paragraph
2 on line = 4500.

=A0 =A0 = The obsolete RFC 3979 Section 5 paragraph 2 text:
=A0 =A0 = "Copies of IPR disclosures made to the IETF=A0
=
Secretariat = and any
=A0=A0 =A0 assurances of licenses = to be made available, or the=A0
=
result = of=A0
an
=A0=A0 =A0 attempt made to obtain = a general license or=A0
=
permission = for the=A0
=
use
=A0=A0 =A0 of such proprietary = rights by implementers or users of this
=A0=A0 =A0 specification can be = obtained from the IETF on-line IPR=A0
=A0=A0 =A0 at http://www.ietf.org/ipr."

=A0-- Found old boilerplate from = RFC 3979 Section 5 paragraph
3 on line = 4506.

=A0 =A0 = The obsolete RFC 3979 Section 5 paragraph 3 text:
=A0 =A0 = "The IETF invites any interested party to bring to=A0
=
its = attention=A0
=
any
=A0=A0 =A0 copyrights, patents or = patent applications, or other=A0
=A0=A0 =A0 rights that may cover = technology that may be required to=A0
=A0=A0 =A0 this standard.=A0 Please address the = information to the IETF at
=A0=A0 =A0 ietf-ipr@ietf.org."


=A0Checking nits according = to

--------------

=A0 =A0 No issues found = here.

=A0Checki= ng nits according to http://www.ietf.org/ID-Chec= klist.html:

--------------

=A0 =A0 No issues found = here.

=A0Miscellaneous = warnings:

--------------

=A0=3D=3D The copyright year in = the IETF Trust Copyright Line does not=A0
match = the
=A0 =A0 current year


=A0Checking references for = intended status: Proposed Standard

--------------

=A0 =A0 (See RFCs 3967 and 4897 = for information about using normative=A0
=A0 =A0 to lower-maturity = documents in RFCs)
=A0 =A0 No issues found = here.

=A0 =A0 = Summary: 1 error (**), 1 warning (=3D=3D), 5 comments = (--).



=

The boilerplate requirements changed after the last = revision was=A0
posted. I will update the boilerplate such that no = ID_NIT=A0
=
issues are=A0
raised.
=

Thanks!




General = Comments
-----------------

1) Need = to have a read-only conformance.

=A0 NIT: would = change the name from ospfv3Compliance to=A0

Will = change.

=

=
5) The MIB did not extract using = mstrip (MIB tool).
If possible, could this be = fixed?
This is a NIT, but still had = trouble with mstrip tool.

Does the tool = take the standard ascii text file as input?
I'll = try to find a user guide for the tool to see what it is=A0


I mention = this as an FYI.
You do not need fix this for MIB = DR review.=A0 As I recall, = the RFC=A0
Editor has fixed this kind of formatting issue in = the past.





6) NEW: = Use of InetAddressType and InetAddress In several=A0
=
places = in=A0
the MIB, the DESCRIPTION states something like "only = IPv6 global=A0
address type expected" and then InetAddress (SIZE = (16)) is given.

First, I have to ask if this is truly the intention = or=A0
=
would = having=A0
{unknown(0), ipv6(2) }=A0 and (SIZE (0|16)) be more = appropriate.

How would an implementation = behave for an unknown(0) address type?

For this = MIB, unknown(0) could be a placeholder as Rows were being=A0
created, = until the real values became available (e.g.=A0
depends on how=A0
rows were created, or how an = agent fills in the info from a=A0
cfg file=A0
during restarts).

This = would not be appropriate for InetAddressType that was=A0
part of the=A0
Index.

In this = MIB, it might be appropriate for ospfv3VirtNbrAddressType=A0
until = the actual value was available (e.g. for implementations that=A0
don't = have all the information available at once during agent=A0

To state my question another way, would=A0 adding=A0 Unknown=A0
and SIZE(0)=A0
as options be helpful (or = provide more flexibility) for=A0
=A0 If = the answer is no, then don't add it, if the=A0
answer = is yes, then would seem appropriate to add it. I'm not=A0





Second, = you restrict InetAddress at the object, but the=A0
=A0
=
please = choose=A0
one place or the other?

I tend to = prefer these restrictions be in the conformance section=A0
because = it is slightly less painful to revise the conformance=A0
section, = than to revise objects=A0 = (but this is just my opinion).
At any = rate, would ask that you be consistent so restrict both=A0
=A0
=
SYNTAX or = add=A0
to the Conformance Section.

OK. I'll = restrict in conformance section.


=







Comments in Order of the = document



(NEW): Ospfv3LsidTC should be renamed to = Ospfv3LsIdTC to be=A0
consistent with the names of the other = TCs.

=

Will change.




*) = ospfv3AreaBdrRtrCount and other Gauge32 objects in this
=
table may
have a DEFVAL clause of zero = (this is mentioned in the=A0
=
DESCRIPTION=A0

=

Not Done.=A0 = Even though these are read-only objects, the=A0
=
DEFVAL = helps=A0
Agent developers so would add this, unless there is = a=A0
=
reason not = to.

=

Will add DEFVAL.

*) ospfv3AreaLsdbTypeKnown (and = also ospfv3LinkLsdbTypeKnown)

Please indicate what true(1) = means in the DESCRIPTION


Not Done.
=

Will add.






*) ospfv3HostTable

Need to have = a storageType object added to this table.


Sorry, I was = not correct when I said that a storageType was
needed.=A0 = The MIB Guidelines specifies to either add a
storageType object OR add a description to the=A0 Entry (as you
have done in other
=A0 To quote from = rfc4181:

=A0 =A0 = - "There either MUST be one columnar object with a
SYNTAX value of
=A0 =A0 =A0 StorageType [RFC2579] = and a MAX-ACCESS value of=A0
=
read-create, = =A0
or
=A0 =A0 =A0 else the row object = (table entry) DESCRIPTION clause
MUST = specify
=A0 =A0 =A0 what happens to = dynamically-created rows after an
agent = restart."



In any case, = the description in the StorageType object

Also, if the = agent is able to create/delete rows then this
needs to be documented...(from rfc4181):

=A0 =A0 -"If the agent itself may = also create and/or delete
rows, then = the
=A0 =A0 =A0 conditions under = which this can occur MUST be clearly
=A0 =A0 =A0 in the row object = DESCRIPTION clause."

Please clarify.


Does your comment apply to this = table only? Can I remove the
StorageType = object and add to Description clause as was done
with other tables?


=
Are the Description clauses = for other
like tables acceptible for this = table?

=

Yes.


=



*) = ospfv3HostEntry and ospfv3HostStorageType


Same comment = as above.

=

Same questions as above.




*)ospfv3IfTable


NIT:=A0 REFERENCE clause "parameters = parameters", please change
to = "parameters"

=

Will change.




*) ospfv3IfAdminStat
Please = rename to ospfv3IfAdminStatus


Will change.
=

Should also have asked about ospfv3AdminStat (the = scalar)
also.=A0 Could you rename this to = ospfv3AdminStatus?
Also, if the ospfv3IfAdminStatus = is enabled, but the =A0
is disabled, = then does this mean that all the interfaces behave as =A0
if they = are=A0 disabled?

In other = words, does the scalar (ospfv3AdminStatus) takes=A0
precedence =A0
over the
individual interface's ospfv3IfAdminStatus = value?

If so, could you please add a mention of this to = the=A0
=
description of =A0
ospfv3IfAdminStatus = and
also ospfv3IfState?





*) Why = is there no ospfv3IfOperStatus object?
is used to read if the status changes.=A0 I think both would = be
appropriate here.
Please = comment.

=

The object ospfv3IfState gives the operational state = of the
OSPF interface.
=

Okay, please add a Reference for this.

As = mentioned above in the discussion of=A0
ospfv3IfAdminStatus, please =A0
expand the
description clause to mention how the adminStatuses = effect this =A0
object.






*) = ospfv3NbrTable and ospfv3CfgNbrTable

What is the relationship between = these 2 tables?
The indexing is different = between the 2 tables and so I'm =A0
wondering
what the relationship is between them.


So to = restate my question, there is an ospfv3CfgNbrEntry
which is a single neighbor that has been configured = and there
is an ospfv3NbrEntry which = contains info about a single
neighbor, so = does the ospfv3CfgNbrEntry also have an

Yes it does. = Configured neighbors are used when running OSPF
on NBMA subnets (OSPF nbma and point-to-multipoint = link types).
The configured neighbors table = just gives OSPF information
for sending = hellos to potential neighbors. Once a hello is
received from a neighbor in the configured neighbor = table,
an entry for that neighbor is = created in the neighbor table
and adjacency = state is maintained there. Neighbors on multi-access
or point-to-point subnets can use multicast = addressing, so
only neighbor table entries are = created.

=
If so, can some explanation be = given on how to look up a
related entry = in the ospfv3NbrEntry table once the

OK. I = will better describe the relationship between
the tables.

Thanks = for the clarification.=A0 = If you can include=A0 = in these table =A0
what you explained above, that = would be great.

=

If there is no relationship = between these two tables then
please state = that in the DESCRIPTION clauses for the tables.



*) ospfv3NbrRtrId

=A0 says "32-bit = integer" and should be "32-bit=A0
=
unsigned = integer"

Will = change.

=

=


------------

In = general the accessible-for-notify objects should probably be
changed into read-only objects.=A0 Additionally, a = timestamp
should = be
associated = with some of these.=A0 = There is an assumption made
that it is
better to send out notifications rather than poll, = but I'd
rather give
=
the operator the choice on = that.



Please = comment.
I've seen accessible-for-notify = used in other MIBs, but I defer
to your = expert judgement on this. Which objects to you think
need a timestamp?


Dan, Sorry I = made a mistake here.
I think I didn't quite = understand how these accessible-for-notify =A0
objects = were
used in several notifications, = but now I see, so timestamps=A0
don't make
sense, neither does changing these objects to = read-only.

Please leave them as accessible-for-notify BUT = please also modify =A0
the = DESCRIPTION
clause which is confusing.=A0 Since these are not = read-only, please =A0
remove the phrase
which = begins "When the last value...."


=

*) = ospfv3PacketSrc

Same sort of issue as discussed in the General = Comment
Section above.=A0 This one especially mentions = returning 0, but it =A0
is = an
InetAddressIPv6 which has OCTET STRING (SIZE = (16)) so please
clarify what is expected by the = agent.
I believe the text about the = zero value is derived from=A0
=
the OSPFv2 =A0
MIB
comment by a MIB reviewer.

=A0=A0 ospfPacketSrc = OBJECT-TYPE
=A0 =A0 =A0 =A0 SYNTAX =A0 =A0 =A0 IpAddress
=A0 =A0 =A0 =A0 = MAX-ACCESS =A0 = read-only
=A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0 current
=A0 =A0 =A0 =A0 = DESCRIPTION
=A0=A0 =A0 =A0 =A0 =A0 "The IP = address of an inbound packet that cannot
=A0=A0 =A0 =A0 =A0 =A0 be = identified by a neighbor instance.=A0= When
=A0=A0 =A0 =A0 =A0 =A0 the last = value of a trap using this object is
=A0=A0 =A0 =A0 =A0 =A0 needed, = but no traps of that type have been sent,
=A0=A0 =A0 =A0 =A0 =A0 this value = pertaining to this object should
=A0=A0 =A0 =A0 =A0 =A0 be = returned as 0.0.0.0."
=A0 =A0 =A0 =A0 ::=3D { = ospfTrapControl 4 }
I thought the same description = would apply to OSPFv3, but instead
returning a = value of an octet string of all zeros. Does
this = make sense?

Since the object has a STATUS of = accessible-for-notify
the above suggestion=A0 of modifying the DESCRIPTION = clause to remove
the "When the last = value...."=A0 will resolve = the issue.

If this was a read-only object then either the "all = zeros"
or using InetAddress SIZE(0 | = 16) so that a zero-length=A0
octet string =A0
would be returned if a
read was done of this address but there was not yet = a valid value =A0
for it.


=A0-Joan






Compliance Statements


*) NIT: ospfv3Compliance should = be renamed to ospfv3FullCompliance

Will = change.

=





MIB-DOCTORS mailing list



= = --Apple-Mail-38--940509729-- From vishwas.ietf@gmail.com Mon Mar 16 20:13:59 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE453A67F1 for ; Mon, 16 Mar 2009 20:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGIx3Nfs9631 for ; Mon, 16 Mar 2009 20:13:58 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 842EC3A6452 for ; Mon, 16 Mar 2009 20:13:58 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so3114373rvb.49 for ; Mon, 16 Mar 2009 20:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CvxrbpzESnbBsdOt5rQE1CnUY7x7agqPNwAMVCe0upY=; b=vhrvWioAHhuugaHybxwGwmhfMzf0W/pMOE4UjOECIQciLS8aHoGQQ7ylRPrJ5tIUxd Zq4ZsapjcZ88JIVGe25hNSgZF7qz+TnOIol+w08pzCd5qL9T8oTb9rjOCZW3TDVpzJcA BVqDWM6N/0eHz8hmIckweB/gLXImwNsMxLZNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oe/5C8ntpN9g332Zp/qQwU9d1MeM7zGstHpE6f5yWUpw5RZuQcIROmufeInbBJKJAJ Zakeg9ZCL9KJSoavQuOhpLWHw+9OV7tK6yXWlIoYOvSQnpYT+OQcf3u6ZrdHZrvcUbRt x8b1gGynExwyCmKBBIC29EB/CiAkCYQRHFoMU= MIME-Version: 1.0 Received: by 10.142.230.11 with SMTP id c11mr2517723wfh.246.1237259681222; Mon, 16 Mar 2009 20:14:41 -0700 (PDT) In-Reply-To: <414371.22999.qm@web27205.mail.ukl.yahoo.com> References: <414371.22999.qm@web27205.mail.ukl.yahoo.com> Date: Mon, 16 Mar 2009 20:14:41 -0700 Message-ID: <77ead0ec0903162014t14c50c31k24a26113c90778f9@mail.gmail.com> From: Vishwas Manral To: John Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OSPF List Subject: Re: [OSPF] OSPF HMAC-SHA Cryptographic Authentication X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2009 03:13:59 -0000 Hi John, Thanks for pointing this out. We will work on it. Thanks, Vishwas On Sun, Mar 15, 2009 at 6:03 PM, John Smith wro= te: > > Hi OSPFers, > > I was reading draft-ietf-ospf-hmac-sha-03.txt and i think its good and ve= ry readable.However, a small nit with the draft: All references to other dr= aft sections are off by 1 - thus a reference to section 3 and 5 in section = 5.1 should be 4 and 6 really. :-) > > Its been around for a long time now and i have never seen any opposition/= changes. Is there a reason why its not close to WG LC yet? > > John > > P.S. > > It seems as Dave reflected some time back, that OSPF is lagging far behin= d IS-IS and RIP as these WGs > (i know there is none for RIP) have already come out with RFCs > extending ISIS/RIP for HMAC-SHA support, while OSPF is still struggling o= n. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From jcucchiara@mindspring.com Tue Mar 17 17:49:09 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB343A6822; Tue, 17 Mar 2009 17:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZrZSK56rhQ1; Tue, 17 Mar 2009 17:49:07 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 25B6F3A681D; Tue, 17 Mar 2009 17:49:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LyIGCXGABFbTf5hoPwNfjlC76G5+Jhge3rpBiP7dAMxbB4eQzEnYO0qjInGbkESg; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.112.219] (helo=JoanPC) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ljjyd-0008F4-LG; Tue, 17 Mar 2009 20:49:49 -0400 Message-ID: <005d01c9a76b$cde891c0$6401a8c0@JoanPC> From: "Joan Cucchiara" To: "Romascanu, Dan \(Dan\)" , "David Ward" References: <001c01c99201$289e5ee0$6401a8c0@JoanPC><004a01c99243$cd5bcf20$6401a8c0@JoanPC> Date: Tue, 17 Mar 2009 20:49:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265418bcca449ebe0053264db5ce1c694957510ab3ad090af031350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.112.219 Cc: Vishwas Manral , "MIB Doctors \(E-mail\)" , ospf@ietf.org Subject: Re: [OSPF] [MIB-DOCTORS] MIB Dr. review ofdraft-ietf-ospf-ospfv3-mib-13.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 18 Mar 2009 00:49:09 -0000 Dan, The editor's emailed me an updated mib yesterday with a compiler related question which I'm working on now and should have an answer for them in the next day or two. Thanks, -Joan ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "David Ward" ; "Joan Cucchiara" Cc: "Vishwas Manral" ; "MIB Doctors (E-mail)" ; "Dan Joyal" ; ; "Acee Lindem" ; "Abhay Roy" Sent: Monday, March 16, 2009 8:54 AM Subject: RE: [MIB-DOCTORS] MIB Dr. review ofdraft-ietf-ospf-ospfv3-mib-13.txt My understanding is that the ball is in the editor's court. Am I wrong? Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org > [mailto:mib-doctors-bounces@ietf.org] On Behalf Of David Ward > Sent: Saturday, March 14, 2009 12:16 AM > To: Joan Cucchiara > Cc: Vishwas Manral; MIB Doctors (E-mail); Dan Joyal; > ospf@ietf.org; David Ward; Acee Lindem; Abhay Roy > Subject: Re: [MIB-DOCTORS] MIB Dr. review > ofdraft-ietf-ospf-ospfv3-mib-13.txt > > Just an ICMP-8 that it would be good to get this wrapped up > and into WG and then IETF LC before and during IETF74 so we > can have a bit of facetoface review if necessary. > > -DWard > > On Feb 18, 2009, at 9:40 PM, Joan Cucchiara wrote: > > > > > Dan, > > > > Think we are down to one or two questions! > > > > Thanks, > > -Joan > > > > > >> > >> ----- Original Message ----- From: "Daniel Joyal" > > >> To: "Joan Cucchiara" > >> Cc: "Vishwas Manral" ; "Acee Lindem" > >> >> > > >> Sent: Tuesday, February 17, 2009 5:18 PM > >> Subject: RE: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt > >> > >> > >> Hi Joan, > >> > >> Thanks for your patience in doing the review twice! > >> See comments and questions in-line. > >> > >> Cheers, > >> -Dan > >> > >>> -----Original Message----- > >>> From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > >>> Sent: Wednesday, February 11, 2009 12:47 AM > >>> To: ospf@ietf.org > >>> Cc: Dan Romascanu; Abhay Roy; David Ward; Ronald Bonica; Joyal, > >>> Daniel (BL60:SF23); Vishwas Manral; Acee Lindem > >>> Subject: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt > >>> > >>> > >>> Dan J. and Vishwas, > >>> > >>> First, I do apologize for being late with this review, > thank you for > >>> your patience. > >>> > >>> A great deal of work went into this > >>> latest revision! Thanks for that! > >>> > >>> The MIB compilers' outputs are given, followed by output > from IDNITS > >>> (http://tools.ietf.org/tools/idnits/) > >>> followed by comments. > >>> > >>> Most all comments are from prior review. Please note, where > >>> agreement was reached, the comments have been deleted. > >>> > >>> Thanks, > >>> Joan > >>> > >>> > >>> > >>> smicngPRO output > >>> ----------------- > >>> > >>> W: f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical > to access > >>> specified for "ospfv3StubRouterSupport" > >>> W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value identical > to access > >>> specified for "ospfv3IfState" > >>> > >> > >> I don't have access to smicngPRO. Is it complaining that > MIN-ACCESS > >> is equal to MAX-ACCESS for these objects? > > > > Yes. Please remove the following lines in the conformance section, > > then these warnings will be resolved: > > > > OBJECT ospfv3StubRouterSupport > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > > > > > > OBJECT ospfv3IfState > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > > > > > >> > >>> > >>> smlint > >>> ----------- > >>> Line Severity Problem > >>> 3096 5 warning: `InetAddress' should be used instead of > >>> `InetAddressIPv6' > >>> > >> > >> The message is intended to warn that the IP address is > specific to a > >> particular address family in cases where the MIB should support > >> multiple address families. > >> But the OSPFv3 MIB only supports the IPv6 address family. > >> The OSPFv3 MIB is not compatible with OSPFv2 implementations. > >> In this case, can the warning be ignored? > > > > Yes. > > > > > >> > >>> > >>> IDNITS > >>> ------ > >>> idnits 2.11.01 > >>> > >>> tmp/draft-ietf-ospf-ospfv3-mib-13.txt: > >>> > >>> Checking boilerplate required by RFC 5378 and the IETF Trust (see > >>> http://trustee.ietf.org/license-info): > >>> > >>> -------------------------------------------------------------- > >>> -------------- > >>> > >>> ** It looks like you're using RFC 3978 boilerplate. You should > >>> update this > >>> to the boilerplate described in the IETF Trust License Policy > >>> document > >>> (see http://trustee.ietf.org/license-info), which is required > >>> from > >>> December 16, 2008. Version 1.34 of xml2rfc can be used to > >>> produce > >>> documents with boilerplate according to the mentioned Trust > >>> License > >>> Policy document. > >>> > >>> -- Found old boilerplate from RFC 3978 Section 5.1 on line 16. > >>> > >>> The obsolete RFC 3978 Section 5.1 text: > >>> "By submitting this Internet-Draft, each author > represents that > >>> any > >>> applicable patent or other IPR claims of which he or she is > >>> aware > >>> have been or will be disclosed, and any of which he or she > >>> becomes > >>> aware will be disclosed, in accordance with Section 6 of BCP > >>> 79." > >>> > >>> -- Found old boilerplate from RFC 3978 Section 5.5 > updated by RFC > >>> 4748 on > >>> line 4482. > >>> > >>> The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text: > >>> "This document and the information contained herein > are provided > >>> on an > >>> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > >>> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET > SOCIETY, > >>> THE > >>> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE > DISCLAIM ALL > >>> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO > >>> ANY > >>> WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT > >>> INFRINGE > >>> ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR > >>> FITNESS > >>> FOR A PARTICULAR PURPOSE." > >>> > >>> -- Found old boilerplate from RFC 3979 Section 5 paragraph > >>> 1 on line 4493. > >>> > >>> The obsolete RFC 3979 Section 5 paragraph 1 text: > >>> "The IETF takes no position regarding the validity or > scope of > >>> any > >>> Intellectual Property Rights or other rights that might be > >>> claimed > >>> to pertain to the implementation or use of the technology > >>> described > >>> in this document or the extent to which any license > under such > >>> rights might or might not be available; nor does it > represent > >>> that > >>> it has made any independent effort to identify any > such rights. > >>> Information on the procedures with respect to rights in RFC > >>> documents can be found in BCP 78 and BCP 79." > >>> > >>> -- Found old boilerplate from RFC 3979 Section 5 paragraph > >>> 2 on line 4500. > >>> > >>> The obsolete RFC 3979 Section 5 paragraph 2 text: > >>> "Copies of IPR disclosures made to the IETF > Secretariat and any > >>> assurances of licenses to be made available, or the > result of > >>> an > >>> attempt made to obtain a general license or > permission for the > >>> use > >>> of such proprietary rights by implementers or users of this > >>> specification can be obtained from the IETF on-line IPR > >>> repository > >>> at http://www.ietf.org/ipr." > >>> > >>> -- Found old boilerplate from RFC 3979 Section 5 paragraph > >>> 3 on line 4506. > >>> > >>> The obsolete RFC 3979 Section 5 paragraph 3 text: > >>> "The IETF invites any interested party to bring to > its attention > >>> any > >>> copyrights, patents or patent applications, or other > >>> proprietary > >>> rights that may cover technology that may be required to > >>> implement > >>> this standard. Please address the information to the IETF at > >>> ietf-ipr@ietf.org." > >>> > >>> > >>> Checking nits according to > >>> http://www.ietf.org/ietf/1id-guidelines.txt: > >>> > >>> -------------------------------------------------------------- > >>> -------------- > >>> > >>> No issues found here. > >>> > >>> Checking nits according to http://www.ietf.org/ID-Checklist.html: > >>> > >>> -------------------------------------------------------------- > >>> -------------- > >>> > >>> No issues found here. > >>> > >>> Miscellaneous warnings: > >>> > >>> -------------------------------------------------------------- > >>> -------------- > >>> > >>> == The copyright year in the IETF Trust Copyright Line does not > >>> match the > >>> current year > >>> > >>> > >>> Checking references for intended status: Proposed Standard > >>> > >>> -------------------------------------------------------------- > >>> -------------- > >>> > >>> (See RFCs 3967 and 4897 for information about using normative > >>> references > >>> to lower-maturity documents in RFCs) > >>> > >>> No issues found here. > >>> > >>> Summary: 1 error (**), 1 warning (==), 5 comments (--). > >>> > >>> > >>> ------------- > >>> > >> > >> The boilerplate requirements changed after the last revision was > >> posted. I will update the boilerplate such that no ID_NIT > issues are > >> raised. > > > > Thanks! > > > >> > >>> > > >>> > > >>> > General Comments > >>> > ----------------- > >>> > > >>> > 1) Need to have a read-only conformance. > >>> > >>> (NEW) NIT: would change the name from ospfv3Compliance to > >>> ospfv3FullCompliance. > >> > >> Will change. > >> > >>> > >>> > >>> > > >>> > 5) The MIB did not extract using mstrip (MIB tool). > >>> > If possible, could this be fixed? > >>> > >>> This is a NIT, but still had trouble with mstrip tool. > >> > >> Does the tool take the standard ascii text file as input? > >> I'll try to find a user guide for the tool to see what it is > >> expecting regarding file formatting. > >> > > > > I mention this as an FYI. > > You do not need fix this for MIB DR review. As I recall, the RFC > > Editor has fixed this kind of formatting issue in the past. > > > > > >>> > >>> > >>> > >>> 6) NEW: Use of InetAddressType and InetAddress In several > places in > >>> the MIB, the DESCRIPTION states something like "only IPv6 global > >>> address type expected" and then InetAddress (SIZE (16)) is given. > >>> > >>> First, I have to ask if this is truly the intention or > would having > >>> {unknown(0), ipv6(2) } and (SIZE (0|16)) be more appropriate. > >> > >> How would an implementation behave for an unknown(0) address type? > > > > For this MIB, unknown(0) could be a placeholder as Rows were being > > created, until the real values became available (e.g. > depends on how > > rows were created, or how an agent fills in the info from a > cfg file > > during restarts). > > > > This would not be appropriate for InetAddressType that was > part of the > > Index. > > > > In this MIB, it might be appropriate for ospfv3VirtNbrAddressType > > until the actual value was available (e.g. for implementations that > > don't have all the information available at once during agent > > start/restart). > > > > To state my question another way, would adding Unknown > and SIZE(0) > > as options be helpful (or provide more flexibility) for > > implementations? If the answer is no, then don't add it, if the > > answer is yes, then would seem appropriate to add it. I'm not > > suggesting that this be added, only asking the question. > > > > > >> > >>> > >>> > >>> Second, you restrict InetAddress at the object, but the > >>> InetAddressType as part of the conformance. Could you > please choose > >>> one place or the other? > >>> > >>> I tend to prefer these restrictions be in the conformance section > >>> because it is slightly less painful to revise the conformance > >>> section, than to revise objects (but this is just my opinion). > >>> At any rate, would ask that you be consistent so restrict both > >>> InetAddressType and InetAddress either in the object's > SYNTAX or add > >>> to the Conformance Section. > >> > >> OK. I'll restrict in conformance section. > > > > Thanks. > > > >> > >>> > >>> > >>> > >>> > >>> > >>> > > >>> > > >>> > Comments in Order of the document > >>> > ---------------------------------- > >>> > > >>> > >>> > >>> (NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC to be > >>> consistent with the names of the other TCs. > >>> > >> > >> Will change. > >> > >>> > >>> > >>> > > >>> > *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this > >>> table may > >>> > have a DEFVAL clause of zero (this is mentioned in the > DESCRIPTION > >>> > clauses). > >>> > > >>> > >>> Not Done. Even though these are read-only objects, the > DEFVAL helps > >>> Agent developers so would add this, unless there is a > reason not to. > >>> > >> > >> Will add DEFVAL. > >> > >>> > *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown) > >>> > > >>> > Please indicate what true(1) means in the DESCRIPTION > >>> > > >>> > >>> Not Done. > >> > >> Will add. > >> > >>> > >>> > >>> > >>> > >>> > > >>> > *) ospfv3HostTable > >>> > > >>> > Need to have a storageType object added to this table. > >>> > > >>> > >>> Sorry, I was not correct when I said that a storageType was > >>> needed. The MIB Guidelines specifies to either add a > >>> storageType object OR add a description to the Entry (as you > >>> have done in other > >>> Tables.) To quote from rfc4181: > >>> > >>> - "There either MUST be one columnar object with a > >>> SYNTAX value of > >>> StorageType [RFC2579] and a MAX-ACCESS value of > read-create, > >>> or > >>> else the row object (table entry) DESCRIPTION clause > >>> MUST specify > >>> what happens to dynamically-created rows after an > >>> agent restart." > >>> > >>> > >>> > >>> In any case, the description in the StorageType object > >>> conflicts with the Table's description. > >>> > >>> Also, if the agent is able to create/delete rows then this > >>> needs to be documented...(from rfc4181): > >>> > >>> -"If the agent itself may also create and/or delete > >>> rows, then the > >>> conditions under which this can occur MUST be clearly > >>> documented > >>> in the row object DESCRIPTION clause." > >>> > >>> > >>> Please clarify. > >>> > >> > >> Does your comment apply to this table only? Can I remove the > >> StorageType object and add to Description clause as was done > >> with other tables? > > > > Yes. > > > >> Are the Description clauses for other > >> like tables acceptible for this table? > >> > > > > Yes. > > > >>> > >>> > > >>> > > >>> > > >>> > > >>> > *) ospfv3HostEntry and ospfv3HostStorageType > >>> > > >>> > >>> Same comment as above. > >>> > >> > >> Same questions as above. > >> > >>> > >>> > >>> > > >>> > *)ospfv3IfTable > >>> > > >>> > >>> NIT: REFERENCE clause "parameters parameters", please change > >>> to "parameters" > >>> > >> > >> Will change. > >> > >>> > >>> > >>> > >>> *) ospfv3IfAdminStat > >>> Please rename to ospfv3IfAdminStatus > >>> > >> > >> Will change. > > > > Should also have asked about ospfv3AdminStat (the scalar) > > also. Could you rename this to ospfv3AdminStatus? > > > > Also, if the ospfv3IfAdminStatus is enabled, but the > > ospfv3AdminStatus (scalar) > > is disabled, then does this mean that all the interfaces behave as > > if they are disabled? > > > > In other words, does the scalar (ospfv3AdminStatus) takes > precedence > > over the > > individual interface's ospfv3IfAdminStatus value? > > > > If so, could you please add a mention of this to the > description of > > ospfv3IfAdminStatus and > > also ospfv3IfState? > > > > > >> > >>> > >>> > >>> *) Why is there no ospfv3IfOperStatus object? > >>> Typically, the AdminStatus if for setting and the OperStatus > >>> is used to read if the status changes. I think both would be > >>> appropriate here. > >>> Please comment. > >>> > >> > >> The object ospfv3IfState gives the operational state of the > >> OSPF interface. > > > > Okay, please add a Reference for this. > > > > As mentioned above in the discussion of > ospfv3IfAdminStatus, please > > expand the > > description clause to mention how the adminStatuses effect this > > object. > > > >> > >>> > >>> > >>> > > >>> > > >>> > *) ospfv3NbrTable and ospfv3CfgNbrTable > >>> > > >>> > What is the relationship between these 2 tables? > >>> > The indexing is different between the 2 tables and so I'm > >>> wondering > >>> > what the relationship is between them. > >>> > > >>> > >>> So to restate my question, there is an ospfv3CfgNbrEntry > >>> which is a single neighbor that has been configured and there > >>> is an ospfv3NbrEntry which contains info about a single > >>> neighbor, so does the ospfv3CfgNbrEntry also have an > >>> associated ospfv3NbrEntry? > >> > >> Yes it does. Configured neighbors are used when running OSPF > >> on NBMA subnets (OSPF nbma and point-to-multipoint link types). > >> The configured neighbors table just gives OSPF information > >> for sending hellos to potential neighbors. Once a hello is > >> received from a neighbor in the configured neighbor table, > >> an entry for that neighbor is created in the neighbor table > >> and adjacency state is maintained there. Neighbors on multi-access > >> or point-to-point subnets can use multicast addressing, so > >> only neighbor table entries are created. > >> > >>> > >>> If so, can some explanation be given on how to look up a > >>> related entry in the ospfv3NbrEntry table once the > >>> ospfv3CfgNbrEntry is populated? > >> > >> OK. I will better describe the relationship between > >> the tables. > > > > Thanks for the clarification. If you can include in these table > > DESCRIPTIONs > > what you explained above, that would be great. > > > >> > >>> > >>> If there is no relationship between these two tables then > >>> please state that in the DESCRIPTION clauses for the tables. > >>> > >>> > >>> > >>> *) ospfv3NbrRtrId > >>> > >>> NIT: says "32-bit integer" and should be "32-bit > unsigned integer" > >> > >> Will change. > >> > >>> > >>> > >>> > > >>> > > >>> > > >>> > Notifications > >>> > ------------ > >>> > > >>> > In general the accessible-for-notify objects should probably be > >>> > changed into read-only objects. Additionally, a timestamp > >>> should be > >>> > associated with some of these. There is an assumption made > >>> that it is > >>> > better to send out notifications rather than poll, but I'd > >>> rather give > >>> > the operator the choice on that. > >>> > > >>> > > >>> > >>> Please comment. > >> > >> I've seen accessible-for-notify used in other MIBs, but I defer > >> to your expert judgement on this. Which objects to you think > >> need a timestamp? > >> > > > > Dan, Sorry I made a mistake here. > > I think I didn't quite understand how these accessible-for-notify > > objects were > > used in several notifications, but now I see, so timestamps > don't make > > sense, neither does changing these objects to read-only. > > > > Please leave them as accessible-for-notify BUT please also modify > > the DESCRIPTION > > clause which is confusing. Since these are not read-only, please > > remove the phrase > > which begins "When the last value...." > > > > > >>> > >>> *) ospfv3PacketSrc > >>> > >>> Same sort of issue as discussed in the General Comment > >>> Section above. This one especially mentions returning 0, but it > >>> is an > >>> InetAddressIPv6 which has OCTET STRING (SIZE (16)) so please > >>> clarify what is expected by the agent. > >> > >> I believe the text about the zero value is derived from > the OSPFv2 > >> MIB > >> comment by a MIB reviewer. > >> > >> ospfPacketSrc OBJECT-TYPE > >> SYNTAX IpAddress > >> MAX-ACCESS read-only > >> STATUS current > >> DESCRIPTION > >> "The IP address of an inbound packet that cannot > >> be identified by a neighbor instance. When > >> the last value of a trap using this object is > >> needed, but no traps of that type have been sent, > >> this value pertaining to this object should > >> be returned as 0.0.0.0." > >> ::= { ospfTrapControl 4 } > >> > >> I thought the same description would apply to OSPFv3, but instead > >> returning a value of an octet string of all zeros. Does > >> this make sense? > > > > Since the object has a STATUS of accessible-for-notify > > the above suggestion of modifying the DESCRIPTION clause to remove > > the "When the last value...." will resolve the issue. > > > > If this was a read-only object then either the "all zeros" > > or using InetAddress SIZE(0 | 16) so that a zero-length > octet string > > would be returned if a > > read was done of this address but there was not yet a valid value > > for it. > > > > > > -Joan > > > > > >> > >>> > >>> > >>> > > >>> > Compliance Statements > >>> > ------------------------- > >>> > > >>> > >>> *) NIT: ospfv3Compliance should be renamed to ospfv3FullCompliance > >> > >> Will change. > >> > >>> > >>> > >>> > >>> > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From manav@alcatel-lucent.com Wed Mar 18 22:07:28 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715943A68AA for ; Wed, 18 Mar 2009 22:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJjg1ouIlBhf for ; Wed, 18 Mar 2009 22:07:27 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 68ABA3A6877 for ; Wed, 18 Mar 2009 22:07:27 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2J58AJn024641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Mar 2009 06:08:10 +0100 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 19 Mar 2009 06:08:10 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 19 Mar 2009 10:37:49 +0530 From: "Bhatia, Manav (Manav)" To: John Smith Date: Thu, 19 Mar 2009 10:37:45 +0530 Thread-Topic: [OSPF] OSPF HMAC-SHA Cryptographic Authentication Thread-Index: Acml0wUW3ZYy6sCKQ/C3Mp4As00ZcgCewQdg Message-ID: <7C362EEF9C7896468B36C9B79200D8357AF6DE47@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <414371.22999.qm@web27205.mail.ukl.yahoo.com> In-Reply-To: <414371.22999.qm@web27205.mail.ukl.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF HMAC-SHA Cryptographic Authentication X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 19 Mar 2009 05:07:28 -0000 Hi John, >=20 > I was reading draft-ietf-ospf-hmac-sha-03.txt and i think its=20 > good and very readable.However, a small nit with the draft:=20 > All references to other draft sections are off by 1 - thus a=20 > reference to section 3 and 5 in section 5.1 should be 4 and 6=20 > really. :-) Thanks. Will fix it. >=20 > Its been around for a long time now and i have never seen any=20 > opposition/changes. Is there a reason why its not close to WG LC yet? There are some folks who believe that we should align our crypto-mathematic= s with how its done in IS-IS and RIP (https://www.ietf.org/proceedings/08no= v/slides/ospf-5.pdf). However, the other argument is that though it did mak= e a trifle bit of sense in doing it for IS-IS and RIP, it makes none, none = at all, for OSPF.=20 It is only this that's stalling the document from moving ahead which is oth= erwise ready for WG LC. Cheers, Manav >=20 > John >=20 > P.S. >=20 > It seems as Dave reflected some time back, that OSPF is=20 > lagging far behind IS-IS and RIP as these WGs > (i know there is none for RIP) have already come out with RFCs > extending ISIS/RIP for HMAC-SHA support, while OSPF is still=20 > struggling on.= From tony.li@tony.li Mon Mar 23 16:51:53 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FF13A69DC for ; Mon, 23 Mar 2009 16:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwnIVSfXMzuh for ; Mon, 23 Mar 2009 16:51:52 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 7DE4328C1F9 for ; Mon, 23 Mar 2009 16:51:52 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA09.westchester.pa.mail.comcast.net with comcast id WZsk1b0080bG4ec59nsjjx; Mon, 23 Mar 2009 23:52:43 +0000 Received: from [127.0.0.1] ([130.129.65.195]) by OMTA03.westchester.pa.mail.comcast.net with comcast id WnrS1b0044ClyMu3Pnre5M; Mon, 23 Mar 2009 23:51:47 +0000 Message-ID: <49C7F70A.8090205@tony.li> Date: Mon, 23 Mar 2009 13:54:34 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <414371.22999.qm@web27205.mail.ukl.yahoo.com> <7C362EEF9C7896468B36C9B79200D8357AF6DE47@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8357AF6DE47@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF HMAC-SHA Cryptographic Authentication X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 23:51:53 -0000 Bhatia, Manav (Manav) wrote: > There are some folks who believe that we should align our crypto-mathematics with how its done in IS-IS and RIP (https://www.ietf.org/proceedings/08nov/slides/ospf-5.pdf). However, the other argument is that though it did make a > trifle bit of sense in doing it for IS-IS and RIP, it makes none, none at all, for OSPF. Except that it makes the end customer happy. It doesn't hurt anything technically, so there are those that feel that this is worthwhile. Tony From manav@alcatel-lucent.com Mon Mar 23 18:05:51 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C091C3A6A43 for ; Mon, 23 Mar 2009 18:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1HIRstcizmn for ; Mon, 23 Mar 2009 18:05:51 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id C0E5A3A67D9 for ; Mon, 23 Mar 2009 18:05:50 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2O16d4Y023187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 02:06:39 +0100 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 02:06:38 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 24 Mar 2009 06:36:37 +0530 From: "Bhatia, Manav (Manav)" To: Tony Li Date: Tue, 24 Mar 2009 06:36:34 +0530 Thread-Topic: [OSPF] OSPF HMAC-SHA Cryptographic Authentication Thread-Index: AcmsEnmyNhpRZdmLShOoZ8JSbwL6QgABu+1g Message-ID: <7C362EEF9C7896468B36C9B79200D835BAB4ABF0@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <414371.22999.qm@web27205.mail.ukl.yahoo.com> <7C362EEF9C7896468B36C9B79200D8357AF6DE47@INBANSXCHMBSA1.in.alcatel-lucent.com> <49C7F70A.8090205@tony.li> In-Reply-To: <49C7F70A.8090205@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF HMAC-SHA Cryptographic Authentication X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2009 01:05:51 -0000 > > There are some folks who believe that we should align our=20 > crypto-mathematics with how its done in IS-IS and RIP=20 > (https://www.ietf.org/proceedings/08nov/slides/ospf-5.pdf).=20 > However, the other argument is that though it did make a=20 > > trifle bit of sense in doing it for IS-IS and RIP, it makes none,=20 > none at all, for OSPF. >=20 > Except that it makes the end customer happy. It doesn't hurt=20 > anything=20 > technically, so there are those that feel that this is worthwhile. The end customer is happy because he is under the impression that the new c= onstruct improves the strength of the crypto hash, which we all know is inc= orrect (especially in case of OSPF). He may feel cheated and may not be so happy, when he learns that there was = no value add. Manav= From tony.li@tony.li Mon Mar 23 18:27:07 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D36228C27F for ; Mon, 23 Mar 2009 18:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5jW-XI-aOyl for ; Mon, 23 Mar 2009 18:27:06 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 6AE5E28C1E2 for ; Mon, 23 Mar 2009 18:27:06 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id Wbn91b0020x6nqcA5pTxJz; Tue, 24 Mar 2009 01:27:57 +0000 Received: from [127.0.0.1] ([130.129.83.225]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id WpTf1b00B4rhcAi8YpTpoa; Tue, 24 Mar 2009 01:27:55 +0000 Message-ID: <49C836F0.7060108@tony.li> Date: Mon, 23 Mar 2009 18:27:12 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <414371.22999.qm@web27205.mail.ukl.yahoo.com> <7C362EEF9C7896468B36C9B79200D8357AF6DE47@INBANSXCHMBSA1.in.alcatel-lucent.com> <49C7F70A.8090205@tony.li> <7C362EEF9C7896468B36C9B79200D835BAB4ABF0@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D835BAB4ABF0@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF HMAC-SHA Cryptographic Authentication X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2009 01:27:07 -0000 Bhatia, Manav (Manav) wrote: > He may feel cheated and may not be so happy, when he learns that there was no value add. The customer has already heard your argument and rejected it. Tony From prvs=3338ed217=acee@redback.com Mon Mar 30 08:22:41 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65FC928C11D for ; Mon, 30 Mar 2009 08:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA7Ro-+4RToW for ; Mon, 30 Mar 2009 08:22:40 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id B77A028C11A for ; Mon, 30 Mar 2009 08:22:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,446,1233561600"; d="scan'208";a="582353" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 30 Mar 2009 08:23:38 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 140D797453D for ; Mon, 30 Mar 2009 08:23:39 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23243-05 for ; Mon, 30 Mar 2009 08:23:38 -0700 (PDT) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id B1A3097453C for ; Mon, 30 Mar 2009 08:23:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <1BEEAE11-F1A5-40DD-B4A4-54C6743B18D4@redback.com> References: <1BEEAE11-F1A5-40DD-B4A4-54C6743B18D4@redback.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <030361BA-3A10-4B76-B31C-4518507EFDCA@redback.com> Cc: OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Mon, 30 Mar 2009 11:23:38 -0400 X-Mailer: Apple Mail (2.753.1) Subject: Re: [OSPF] WG Last Call - Dynamic Hostname Exchange Mechanism for OSPF - draft-ietf-ospf-dynamic-hostname-02 (Corrected) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2009 15:23:03 -0000 The WG last call has ended. The authors are adding a statement with respect to multiple OSPF instances and it will go to the routing ADs. Thanks, Acee On Mar 12, 2009, at 5:56 AM, Acee Lindem wrote: > This starts the Working Group Last Call for the subject document. > The target status is proposed standard. > The WG Last Call will start today and end April 3rd at 12:00 AM > EDT. I've added an additional week due to the upcoming IETF. If > anyone needs more time to review the document, let Abhay or myself > know. It is a very simple document and the last remaining issue > (specification of hostname encoding) has been resolved to my > satisfaction. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From prvs=3338ed217=acee@redback.com Mon Mar 30 11:28:38 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBFF3A6D50 for ; Mon, 30 Mar 2009 11:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN4nHywLuUYd for ; Mon, 30 Mar 2009 11:28:37 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 51AA63A6D5B for ; Mon, 30 Mar 2009 11:28:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,447,1233561600"; d="scan'208";a="587372" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 30 Mar 2009 11:29:36 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C1301F0492 for ; Mon, 30 Mar 2009 11:29:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25666-05 for ; Mon, 30 Mar 2009 11:29:35 -0700 (PDT) Received: from [IPv6???1] (unknown [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 66BBEF048F for ; Mon, 30 Mar 2009 11:29:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <030361BA-3A10-4B76-B31C-4518507EFDCA@redback.com> References: <1BEEAE11-F1A5-40DD-B4A4-54C6743B18D4@redback.com> <030361BA-3A10-4B76-B31C-4518507EFDCA@redback.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5CED94C0-FB61-47FC-B4F7-8F04921D9DF5@redback.com> Cc: OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Mon, 30 Mar 2009 14:29:34 -0400 X-Mailer: Apple Mail (2.753.1) Subject: Re: [OSPF] WG Last Call - Dynamic Hostname Exchange Mechanism for OSPF - draft-ietf-ospf-dynamic-hostname-02 (Corrected) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2009 18:28:38 -0000 I take that back - you still have until Friday to comment. Thanks, Acee On Mar 30, 2009, at 11:23 AM, Acee Lindem wrote: > The WG last call has ended. The authors are adding a statement with > respect to multiple OSPF instances and it will go to the routing ADs. > > > Thanks, > Acee > On Mar 12, 2009, at 5:56 AM, Acee Lindem wrote: > >> This starts the Working Group Last Call for the subject document. >> The target status is proposed standard. >> The WG Last Call will start today and end April 3rd at 12:00 AM >> EDT. I've added an additional week due to the upcoming IETF. If >> anyone needs more time to review the document, let Abhay or myself >> know. It is a very simple document and the last remaining issue >> (specification of hostname encoding) has been resolved to my >> satisfaction. >> >> Thanks, >> Acee >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf