Re: Last call complete on GMPLS MIBs
"Tom Petch" <nwnetworks@dial.pipex.com> Wed, 10 August 2005 09:44 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2n8n-0003OR-Os for ccamp-archive@megatron.ietf.org; Wed, 10 Aug 2005 05:44:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16674 for <ccamp-archive@ietf.org>; Wed, 10 Aug 2005 05:44:51 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2ngm-0000NJ-Pw for ccamp-archive@ietf.org; Wed, 10 Aug 2005 06:20:07 -0400
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2mz5-000BH2-79 for ccamp-data@psg.com; Wed, 10 Aug 2005 09:34:51 +0000
Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2mz4-000BGg-5g for ccamp@ops.ietf.org; Wed, 10 Aug 2005 09:34:50 +0000
Received: from pc6 (1Cust196.tnt27.lnd4.gbr.da.uu.net [62.188.154.196]) by blaster.systems.pipex.net (Postfix) with SMTP id 92B1FE000224; Wed, 10 Aug 2005 10:34:38 +0100 (BST)
Message-ID: <000f01c59d86$306c2760$0601a8c0@pc6>
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
From: Tom Petch <nwnetworks@dial.pipex.com>
To: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
References: <069201c54cb9$7ec46cb0$1c849ed9@Puppy>
Subject: Re: Last call complete on GMPLS MIBs
Date: Wed, 10 Aug 2005 10:30:45 +0200
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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Adrian I finally got to look at the new versions of the GMPLS MIBs that came out in June and am pleased to see my previous comments in use:-). Some follow up thoughts. In draft-ietf-ccamp-gmpls-te-mib-09, I see that IANAGmplsSwitchingType ::= TEXTUAL-CONVENTION still references "1. Kompella, K., Rekhter, Y. (Editors), Routing Extensions in Support of Generalized Multi-Protocol Label Switching draft-ietf-ccamp-gmpls-routing, work in progress. which I think should be draft-ietf-ccamp-ospf-gmpls-extensions for l2sc (51). The former introduces the concept but does not give a value; the latter assigns the value 51. IANAGmplsLSPEncoding has a reference to D. Papadimitriou (Editor), Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, draft-ietf-ccamp-gmpls-g709, work in progress which I think should make that a normative reference. And, more generally with these references to I-Ds which are normative, should we add a note to tell the RFC editor to replace this with a reference to the RFC when it emerges? That would be business as usual in the References section but might need a little encouragement buried in a MIB module DESCRIPTION. IANAGmplsAdminStatusFlags defines BITS as delInProgress (0), adminDown (1), testing (2), reflect (31) while RFC3471 has reflect as bit 0 and delInProgress as bit 31. Is that correct? (I assume that the intent is to keep them in line and I don't know which way round BITS go; I assumed bit 0 came first and was MSB. If ITU and IETF part company over this, we should be using IETF nomenclature:-) In draft-ietf-ccamp-gmpls-lsr-mib-08.txt, I would like you to give the RFC Editor a little more help in resolving GMPLSTCMIB by explicitly stating that it is the RFC produced from draft-ietf-ccamp-gmpls-tc-mib-07.txt Somewhat bigger issue; I am concerned that no constraint is placed on the allocation by IANA of new values in the IANA MIB module, where the base documents call for more stringent action (although there is some disagreement as to what that is). As it stands, it seems to me that anyone in the world can e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by Expert Review ie the existence of a new name/number mapping is documented in an RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module. We could require the RFC that introduces a new mapping to have an IANA section that updates the MIB module but I fear that most editors would forget to include it, so Expert Review seems best. Finally, I would prefer the IANA MIB modules to be retained in the published RFC with a note that the authoritative source is IANA; this gives us an audit trail of how we got to where we are, or not as the case may be. There has been a case just recently elsewhere where the RFC and IANA are different and it is valuable to see just what it was that was last called and approved by all concerned. As and when the RFC containing the IANA MIB module is reissued, then there would be no need to replicate it. Tom Petch
- Last call complete on GMPLS MIBs Adrian Farrel
- Re: Last call complete on GMPLS MIBs Tom Petch