From tnadeau@juniper.net Mon Dec 3 07:23:17 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F4621F8839 for ; Mon, 3 Dec 2012 07:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C-q76ECUkaq for ; Mon, 3 Dec 2012 07:23:16 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8FA21F8826 for ; Mon, 3 Dec 2012 07:23:16 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKULzD44oWKGR62pMO4DGEFRC3TmtqdXYN@postini.com; Mon, 03 Dec 2012 07:23:16 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 3 Dec 2012 07:21:12 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 3 Dec 2012 07:21:12 -0800 Received: from CO9EHSOBE003.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 3 Dec 2012 07:23:45 -0800 Received: from mail113-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE003.bigfish.com (10.236.130.66) with Microsoft SMTP Server id 14.1.225.23; Mon, 3 Dec 2012 15:21:10 +0000 Received: from mail113-co9 (localhost [127.0.0.1]) by mail113-co9-R.bigfish.com (Postfix) with ESMTP id D0B00A8027F for ; Mon, 3 Dec 2012 15:21:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -7 X-BigFish: PS-7(zzbb2dI98dI9371Iec9N1432I1182kzz1de0h1202h1d1ah1d2ahzz8275bhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received: from mail113-co9 (localhost.localdomain [127.0.0.1]) by mail113-co9 (MessageSwitch) id 13545480532100_32287; Mon, 3 Dec 2012 15:20:53 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.240]) by mail113-co9.bigfish.com (Postfix) with ESMTP id F178B74005C; Mon, 3 Dec 2012 15:20:52 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 3 Dec 2012 15:20:44 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.9.140]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0245.002; Mon, 3 Dec 2012 15:20:36 +0000 From: Thomas Nadeau To: Joan Cucchiara , Sam Aldrin Thread-Topic: Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt Thread-Index: AQHNyAEa6m1ijc8yrkKXnAC7LMqc3ZgG77GA Date: Mon, 3 Dec 2012 15:20:36 +0000 Message-ID: In-Reply-To: <006c01cdc801$11c81460$6801a8c0@JoanPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%MINDSPRING.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:23:17 -0000 Recusing myself as a co-author of the document in question, I'd like to just add a few points to the thread below to consider. 1) While the corner case you make Joan is very real, it is also very unlikely. The reason is that in all of the operational networks I've seen where TE is deployed (and especially MPLS-TP/TE), there is a single provisioning system that governs how, when and where tunnels are placed. This would obviate the overlap case you pointed out. 2) So as to not discount the case you point out, would it help to include some sort of TunnelType field indicating explicitly that it is TP? I am thinking of an enum like we have in RFC3813 mplsTunnelRole. This could even be a boolean called mplsTpTunnelIsTP or something. --Tom On 11/21/12 10:58 AM, "Joan Cucchiara" wrote: > >MIB Doctors, > >I would like your guidance. > >This draft proposes to add support of Transport Profile (TP) >for MPLS-TC-STD-MIB [RFC3811], MPLS-LSR-STD-MIB [RFC3813] >and MPLS-TE-STD-MIB [RFC3812] c. 2004. > >Essentially, the mplsTunnelTable from the MPLS-TE-STD-MIB [RFC3812] >could have entries created statically (i.e. manually by an operator) or >dynamically. MPLS-TE Tunnels are uni-directional while MPLS-TE Tunnels >with Transport Profile are bi-direction (modelled as 2 uni-directional >tunnels which are related in the proposed new doc.) > >I think the following 2 DESCRIPTIONs clauses are NOT the same >semantically: > >Original MplsExtendedTunnelId [RFC3811]: > > MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A unique identifier for an MPLS Tunnel. This may > represent an IPv4 address of the ingress or egress > LSR for the tunnel. This value is derived from the > Extended Tunnel Id in RSVP or the Ingress Router ID > for CR-LDP." > REFERENCE > "RSVP-TE: Extensions to RSVP for LSP Tunnels, > [RFC3209]. > > Constraint-Based LSP Setup using LDP, [RFC3212]." > SYNTAX Unsigned32(0..4294967295) > >Here is the index's DESCRIPTION which uses the above TC. >To me, while syntactically equivalent are not >semantically equivalent, so this is >where I could use your guidance, please? > > > mplsTunnelExtNodeConfigLocalId OBJECT-TYPE > SYNTAX MplsExtendedTunnelId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object is used in accommodating the bigger > size Global_Node_ID and/or ICC with lower size LSR > identifier in order to index the mplsTunnelTable. > > The Local Identifier is configured between 0 and 16777215, > as valid IP address range starts from 16777216(01.00.00.00). > This range is chosen to identify the mplsTunnelTable's > Ingress/Egress LSR-id is IP address or Local identifier, > if the configured range is not IP address, operator is > expected to retrieve the complete information > (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. > > This way, existing mplsTunnelTable is reused for > bidirectional tunnel extensions for MPLS based transport > networks. > > This Local Identifier allows the operator to assign > a unique identifier to map Global_Node_ID and/or ICC. > As this Local Identifier is unique within the node and > the same syntax of this object can be used for MPLS TE > tunnel also, it is up to the operator/local management entity >to > choose the non-conflicting value for indexing the MPLS and > MPLS-TP tunnel entries." > ::=3D { mplsTunnelExtNodeConfigEntry 1 } > > >The above "guideline" range of "0" to "16777215" is supposed to be a >clue to operator that this is an MPLS-TE Tunnel WITH Transport Profile, >HOWEVER, there is nothing in the original MIB that disallows operators >from >manually configuring within this range. > >One scenario (even if unlikely): >An MPLS TP with Transport Profile is configured dynamically, >which conflicts with an older legacy NMS which is statically configuring >MPLS TE Tunnel, and they both have chosen one of the same indexes >(remember=20 >that there are >2 MplsExtendedTunnelId values for each tunnel.) So again, while >unlikely,=20 >seems that there is >potential conflict with legacy equipment. > >I would like other MIB Doctor guidance: > >Do you think (as I do) that the DESCRIPTION for >mplsTunnelExtNodeConfigLocalId (above) semantically redefines >the original MplsExtendedTunnelId TC? > >Thank you, > Joan > > From randy_presuhn@mindspring.com Mon Dec 3 10:00:42 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308B121F8934 for ; Mon, 3 Dec 2012 10:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jRu5euBoz43 for ; Mon, 3 Dec 2012 10:00:41 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8973B21F891F for ; Mon, 3 Dec 2012 10:00:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CjvLQ37V1ZCAjt8WgzARBbvu8ygLTpLCsixET0zXEA3Pe4hzh3jZqnIcatdVvT8l; 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 [76.254.51.198] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TfaJq-0003wt-Hl; Mon, 03 Dec 2012 13:00:38 -0500 Message-ID: <005401cdd180$3c9aa800$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Thomas Nadeau" , "Joan Cucchiara" , "Sam Aldrin" References: Date: Mon, 3 Dec 2012 10:01:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97e05b72962d5071a98f9dee277f794e777350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.51.198 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:00:42 -0000 Hi - > From: "Thomas Nadeau" > To: "Joan Cucchiara" ; "Sam Aldrin" > Cc: "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "Kannan Sampath" ; "venkatesan mahalingam" > Sent: Monday, December 03, 2012 7:20 AM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt ... > 2) So as to not discount the case you point out, would it help to include > some sort of TunnelType field indicating explicitly that it is TP? I am > thinking of an enum like we have in RFC3813 mplsTunnelRole. This could > even be a boolean called mplsTpTunnelIsTP or something. As I understand it, the concern is that a management application might attempt to use data of type MplsExtendedTunnelId as though it were an address. Adding other objects won't of itself fix that problem. The best way I can see to mitigate the issue would be to add clarifying text to RFC 3811 in the description of MplsExtendedTunnelId, and possibly to add reminders of that clarification everywhere that textual convention is used. The next best thing might be to include warnings against misuse in any new work using that textual convention. Not having a stake in the controversy, and not being immersed in any of these specifications, I'll just say that to me it seems that adding such a clarification should go onto the editors' "to do" list in case RFC 3811 is ever updated. However, as practical matter the severity of the issue does not seem sufficient of itself to press the case for re-opening that specification. If folks were to decide that this should be documented as an erratum, it would probably end up in the "hold for document update" bin. Randy From tnadeau@juniper.net Mon Dec 3 10:07:29 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A6D21F8848 for ; Mon, 3 Dec 2012 10:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIqmMXAwZkPW for ; Mon, 3 Dec 2012 10:07:28 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBFB21F8839 for ; Mon, 3 Dec 2012 10:07:28 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKULzqYCoK7qDFwQQ9Kfph7zKQc8kSDqz2@postini.com; Mon, 03 Dec 2012 10:07:28 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 3 Dec 2012 10:04:37 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 3 Dec 2012 10:04:37 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 3 Dec 2012 10:12:07 -0800 Received: from mail217-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Mon, 3 Dec 2012 18:04:25 +0000 Received: from mail217-tx2 (localhost [127.0.0.1]) by mail217-tx2-R.bigfish.com (Postfix) with ESMTP id 67237480144 for ; Mon, 3 Dec 2012 18:04:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I1432Izz1de0h1202h1d1ah1d2ahzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received: from mail217-tx2 (localhost.localdomain [127.0.0.1]) by mail217-tx2 (MessageSwitch) id 1354557863862586_26254; Mon, 3 Dec 2012 18:04:23 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.250]) by mail217-tx2.bigfish.com (Postfix) with ESMTP id C58F6940043; Mon, 3 Dec 2012 18:04:23 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 3 Dec 2012 18:04:23 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.9.140]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0245.002; Mon, 3 Dec 2012 18:04:21 +0000 From: Thomas Nadeau To: Randy Presuhn , Joan Cucchiara , Sam Aldrin Thread-Topic: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt Thread-Index: AQHNyAEa6m1ijc8yrkKXnAC7LMqc3ZgG77GAgACAu/X//6z4gA== Date: Mon, 3 Dec 2012 18:04:21 +0000 Message-ID: In-Reply-To: <005401cdd180$3c9aa800$6b01a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <6C2FEAEEC6311A4A8B1BE750CC2FAE89@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%MINDSPRING.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:07:29 -0000 On 12/3/12 1:01 PM, "Randy Presuhn" wrote: >Hi - > >> From: "Thomas Nadeau" >> To: "Joan Cucchiara" ; "Sam Aldrin" >> >> Cc: "Venkatesan Mahalingam" ; "MIB >>Doctors (E-mail)" ; "Kannan Sampath" >; "venkatesan mahalingam" >> Sent: Monday, December 03, 2012 7:20 AM >> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on >>draft-ietf-mpls-te-tp-mib-05.txt >... >> 2) So as to not discount the case you point out, would it help to >>include >> some sort of TunnelType field indicating explicitly that it is TP? I am >> thinking of an enum like we have in RFC3813 mplsTunnelRole. This could >> even be a boolean called mplsTpTunnelIsTP or something. > >As I understand it, the concern is that a management application might >attempt to use data of type MplsExtendedTunnelId as though it were an >address. Adding other objects won't of itself fix that problem. > >The best way I can see to mitigate the issue would be to add clarifying >text to RFC 3811 in the description of MplsExtendedTunnelId, and >possibly to add reminders of that clarification everywhere that textual >convention is used. The next best thing might be to include warnings >against misuse in any new work using that textual convention. > >Not having a stake in the controversy, and not being immersed in any >of these specifications, I'll just say that to me it seems that adding >such >a clarification should go onto the editors' "to do" list in case RFC 3811 >is ever updated. However, as practical matter the severity of the issue >does not seem sufficient of itself to press the case for re-opening that >specification. If folks were to decide that this should be documented >as an erratum, it would probably end up in the "hold for document >update" bin. Could add this as an errata with reference to the new document? --Tom > >Randy > > > From randy_presuhn@mindspring.com Mon Dec 3 10:22:20 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845F221F8931 for ; Mon, 3 Dec 2012 10:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxsLYp931fIh for ; Mon, 3 Dec 2012 10:22:19 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7621F8920 for ; Mon, 3 Dec 2012 10:22:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jnqdczIA5TpLTLhMxZOhkejQauKwLfNp3SAxWTOtJVhjk1/JilgRZ/qDWsMth/8A; 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 [76.254.51.198] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Tfaem-0005pD-Sb; Mon, 03 Dec 2012 13:22:17 -0500 Message-ID: <007d01cdd183$42dccce0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Thomas Nadeau" , "Joan Cucchiara" , "Sam Aldrin" References: Date: Mon, 3 Dec 2012 10:23:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97ec12de17cf52807ce1ca56bf9ff0c9f82350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.51.198 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:22:20 -0000 Hi - > From: "Thomas Nadeau" ... > Sent: Monday, December 03, 2012 10:04 AM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt ... > >Not having a stake in the controversy, and not being immersed in any > >of these specifications, I'll just say that to me it seems that adding such > >a clarification should go onto the editors' "to do" list in case RFC 3811 > >is ever updated. However, as practical matter the severity of the issue > >does not seem sufficient of itself to press the case for re-opening that > >specification. If folks were to decide that this should be documented > >as an erratum, it would probably end up in the "hold for document > >update" bin. > > Could add this as an errata with reference to the new document? To me that sounds overly complicated. The clarification to be added to 3811 would effectively be "don't count on this being an address, or of even being a unique identifier outside the scope of the usage of this textual convention within a particular context in a particular system." Honestly, to me that warning is already carried by the weasel words in the existing description, and that warning is only undermined by the ambiguity about the scope of what being a unique identifier entails where this TC is employed. Randy From bclaise@cisco.com Sat Dec 8 04:43:55 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C65221F87A6; Sat, 8 Dec 2012 04:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.969 X-Spam-Level: X-Spam-Status: No, score=-9.969 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jc4hEVL7Nu0N; Sat, 8 Dec 2012 04:43:54 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEF621F8796; Sat, 8 Dec 2012 04:43:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB8Chrsm013601; Sat, 8 Dec 2012 13:43:53 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB8ChoA4029308; Sat, 8 Dec 2012 13:43:50 +0100 (CET) Message-ID: <50C32A4D.5010001@cisco.com> Date: Sat, 08 Dec 2012 12:53:49 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20121207000510.8242.57380.idtracker@ietfa.amsl.com> In-Reply-To: <20121207000510.8242.57380.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121207000510.8242.57380.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] PRELIMINARY Agenda and Package for the December 13, 2012 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 12:43:55 -0000 Dear all, Please find below the agenda of the December 13th IESG telechat. Please send your questions, comments and concerns before Dec 12 COB. Thanks and Regards, Benoit ============================================================ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-mediactrl-mrb-16 Media Resource Brokering (Proposed Standard) Note: Dale Worley (dworley@avaya.com) is the document shepherd. Token: Robert Sparks 2.1.2 Returning Items o draft-ietf-dhc-dhcpv6-redundancy-consider-03 DHCPv6 Redundancy Deployment Considerations (Best Current Practice) Note: Ted Lemon (ted.lemon@nominum.com) is the document shepherd. Token: Ralph Droms 2.2 Individual Submissions 2.2.1 New Items o draft-leiba-3777upd-eligibility-05 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership (Best Current Practice) Token: Russ Housley 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-tcpm-initcwnd-06 Increasing TCP's Initial Window (Experimental) Note: Yoshifumi Nishida (nishida@sfc.wide.ad.jp) is the Document Shepherd for this document. Token: Wesley Eddy 3.1.2 Returning Items o draft-ietf-ppsp-problem-statement-11 Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP) (Informational) Note: Stefano Previdi (sprevidi@cisco.com) is the document shepherd. Token: Martin Stiemerling 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-kumaki-murai-l3vpn-rsvp-te-07 Support for RSVP-TE in L3VPNs (Experimental) Token: Stewart Bryant o draft-nir-ipsecme-erx-09 An IKEv2 Extension for Supporting ERP (Experimental) Note: Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd Token: Sean Turner 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items o conflict-review-masotta-tftpexts-windowsize-opt-00 IETF conflict review for draft-masotta-tftpexts-windowsize-opt draft-masotta-tftpexts-windowsize-opt-06 TFTP Windowsize Option (ISE: Informational) Token: Pete Resnick 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o IP Security Maintenance and Extensions (ipsecme) 4.2.2 Proposed for Approval NONE From Martin.Stiemerling@neclab.eu Wed Dec 12 02:13:25 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E762A21F88CB for ; Wed, 12 Dec 2012 02:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0nwduGb5MQD for ; Wed, 12 Dec 2012 02:13:23 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B772421F88C8 for ; Wed, 12 Dec 2012 02:13:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 23D921029DE; Wed, 12 Dec 2012 11:13:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Hq4njZkwZCy; Wed, 12 Dec 2012 11:13:23 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 09A481029DC; Wed, 12 Dec 2012 11:12:58 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 11:12:47 +0100 Message-ID: <50C858A9.6080905@neclab.eu> Date: Wed, 12 Dec 2012 11:12:57 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Benoit Claise References: <50758E1C.6070706@neclab.eu> <50759DA6.9020900@cisco.com> In-Reply-To: <50759DA6.9020900@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: Michael MacFaden , "MIB Doctors \(E-mail\)" , "storm-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [MIB-DOCTORS] Request for MIB review of draft-ietf-storm-iscsimib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:13:25 -0000 Benoit, MIB Doctors, Did anybody have time to check the updated iSCSI MIB? I would like to progress the draft to the IESG soon. Thank you in advance, Martin On 10/10/2012 06:09 PM, Benoit Claise wrote: > Hi Mike, > > As far as I know, you did the review of draft-ietf-storm-iscsimib > Can you please have a look to see if this latest version addresses your > points at http://www.macfaden.com/ietf/iscsi-mib-1-reviewed.txt > > Regards, Benoit >> Hi Ron and Benoit, >> >> The MIB doctors did a review of draft-ietf-storm-iscsimib a while back >> and did comment on the text, but also on the MIB module itself. >> (https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib) >> >> The STORM working group has gone through the review and updated the >> draft to address these. >> >> Can you please ask the MIB doctors to review the ISCSI MIB module again? >> >> Thanks in advance, >> >> Martin >> > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From bclaise@cisco.com Tue Dec 18 08:48:33 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD78921F8512; Tue, 18 Dec 2012 08:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.35 X-Spam-Level: X-Spam-Status: No, score=-10.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm9r+X4IJV23; Tue, 18 Dec 2012 08:48:33 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 994BC21F8539; Tue, 18 Dec 2012 08:48:31 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBIGmU7j017739; Tue, 18 Dec 2012 17:48:30 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBIGmT8Y027829; Tue, 18 Dec 2012 17:48:29 +0100 (CET) Message-ID: <50D09E5D.4040603@cisco.com> Date: Tue, 18 Dec 2012 17:48:29 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20121214121653.30833.7485.idtracker@ietfa.amsl.com> In-Reply-To: <20121214121653.30833.7485.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121214121653.30833.7485.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-12-20 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 16:48:33 -0000 Dear all, Please find below the agenda of the December 20th IESG telechat. Please send your questions, comments and concerns before Dec 19 COB. Thanks and Regards, Benoit -------- Original Message -------- INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2012-12-20 IESG Teleconference This agenda was generated at 2012-12-14 04:15:48 PST Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-sipclf-problem-statement-11 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model (Proposed Standard) Note: Peter Musgrave (musgravepj@gmail.com) is the document shepherd. Token: Robert Sparks o draft-ietf-sipclf-format-09 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) (Proposed Standard) Note: Peter Musgrave (musgravepj@gmail.com) is the document shepherd. Token: Robert Sparks o draft-ietf-tcpm-experimental-options-03 Shared Use of Experimental TCP Options (Proposed Standard) Note: Michael Scharf (michael.scharf@alcatel-lucent.com) is the document shepherd. Token: Wesley Eddy o draft-ietf-fecframe-simple-rs-05 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME (Proposed Standard) Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd Token: Martin Stiemerling o draft-ietf-mmusic-sdp-media-capabilities-16 Session Description Protocol (SDP) Media Capabilities Negotiation (Proposed Standard) Note: Miguel Garcia (Miguel.A.Garcia@ericsson.com) is the Document Shepherd. Token: Gonzalo Camarillo o draft-ietf-avt-rtp-evrc-nw-09 RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) (Proposed Standard) Note: Roni Even (roni.even@mail01.huawei.com) is the Document Shepherd. Token: Robert Sparks 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-karp-routing-tcp-analysis-06 Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide (Informational) Note: Joel Halpern (jmh@joelhalpern.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-sidr-usecases-05 Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties (Informational) Note: Alexey Melnikov (alexey.melnikov@isode.com) is the document shepherd. Token: Stewart Bryant 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items o conflict-review-masotta-tftpexts-windowsize-opt-01 IETF conflict review for draft-masotta-tftpexts-windowsize-opt draft-masotta-tftpexts-windowsize-opt-06 TFTP Windowsize Option (ISE: Informational) Token: Pete Resnick 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Sunsetting IPv4 (sunset4) 4.2.2 Proposed for Approval NONE