RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Fri, 21 January 2005 14:15 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12822 for <ipcdn-archive@ietf.org>; Fri, 21 Jan 2005 09:15:05 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crzoy-0004OO-N1 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 09:31:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrzKQ-0008LJ-2v; Fri, 21 Jan 2005 08:59:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrzFh-0007GH-7W for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 08:55:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11080 for <ipcdn@ietf.org>; Fri, 21 Jan 2005 08:55:03 -0500 (EST)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrzVY-0003lE-Bn for ipcdn@ietf.org; Fri, 21 Jan 2005 09:11:30 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0LDsve2011772 for <ipcdn@ietf.org>; Fri, 21 Jan 2005 07:55:00 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <ZXP4ZH9K>; Fri, 21 Jan 2005 14:54:56 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550639C932@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Jean-Francois Mule <jf.mule@cablelabs.com>, ipcdn@ietf.org
Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
Date: Fri, 21 Jan 2005 14:54:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 142a000676f5977e1797396caab8b611
Content-Transfer-Encoding: quoted-printable
Cc: enechamkin@broadcom.com
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f
Content-Transfer-Encoding: quoted-printable
Fine by me Bert > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, January 21, 2005 00:31 > To: ipcdn@ietf.org > Cc: Wijnen, Bert (Bert); enechamkin@broadcom.com > Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > > > Just a minor editorial change in our informative text to > explain why the pktcMtaDevErrorOid is of type SnmpAdminString. > > : > On Tuesday, January 11, 2005 at 4:47 PM, I had proposed: > > "Note that the syntax of this object is SnmpAdminString > > rather OBJECT IDENTIFIER because the object value is > > provided by an operator in the MTA configuration file > > in the form of a character string." > > Based on Eugene's comment, the newly proposed text is: > Note that the syntax of this object is SnmpAdminString > rather OBJECT IDENTIFIER because the object value may > not be a valid OID due to human or configuration tool > encoding errors. > > Let us know if this new proposed text is an issue. > Jean-François > > > -----Original Message----- > > From: Jean-Francois Mule > > Sent: Tuesday, January 11, 2005 4:47 PM > > To: Dave Thaler; ipcdn@ietf.org > > Cc: randy_presuhn@mindspring.com; Wijnen, Bert (Bert); > > enechamkin@broadcom.com; C. M. Heard > > Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > > > > > > To close on one additional comment: > > Dave wrote: > > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > > > why are OIDs of type SnmpAdminString rather than an > > > OBJECT IDENTIFIER > > > type/subtype? As is, the management station cannot do > > > simple things > > > like expanding the OID into the defined string tokens > > in the MIB. > > > > We discussed this point during the IETF IPCDN meeting #61, > > see proceedings at: > > <http://www1.ietf.org/proceedings_new/04nov/ipcdn.html#cmr> > > > > The meeting minutes recorded: > > In the WG meeting, we had consensus that since the OID and its > > value is provided in the MTA config file by an operator in the > > form of a character string, it is better to leave the syntax > > as SnmpAdminString rather than OBJECT IDENTIFIER. It was also > > requested that the above explanation be mentioned in the doc. > > > > So, the resolution is: > > - no object syntax change > > - change the description of the pktcMtaDevErrorOid to > > indicate the following: > > "Note that the syntax of this object is SnmpAdminString > > rather OBJECT IDENTIFIER because the object value is > > provided by an operator in the MTA configuration file > > in the form of a character string." > > - after more review of the pktcMtaDevErrorValue object, > > we do not believe the above text should be added to its > > description as this pktcMtaDevErrorValue object may contain > > all kinds of object values in the case where the MTA can > > recognize the OID but cannot interpret the given value. > > > > Proposed text changes: > > pktcMtaDevErrorOid OBJECT-TYPE > > SYNTAX SnmpAdminString > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > " This object contains a human readable representation > > (character string) of the OID corresponding to the > > configuration file parameter that caused the particular > > error. > > For example, if the value of the pktcMtaDevEnabled object > > in the configuration file caused an error, then this > > object instance will contain the human readable string of > > '.1.3.6.1.2.1.XXX.1.1.6.0'. > > ************************************************************ > > * NOTES TO RFC Editor (to be removed prior to publication) * > > * Please replace XXX with the IANA-assigned number under * > > * mib-2. * > > ************************************************************ > > > > If the MTA generated an error because it was not able > > to recognize a particular OID, then this object > > instance would contain an empty value (zero-length > > string). > > For example, if the value of an OID in the configuration > > file was interpreted by the MTA as being .1.2.3.4.5, and > > the MTA was not able to recognize this OID as a valid one, > > this object instance will contain a zero-length string. > > Note that the syntax of this object is SnmpAdminString > > rather OBJECT IDENTIFIER because the object value is > > provided by an operator in the MTA configuration file > > in the form of a character string." > > ::= {pktcMtaDevErrorOidsEntry 2} > > > > Let us know if this change is acceptable or else, feel free > > to propose text improvements or suggestions. > > > > Thanks, > > > > Jean-François > > > > > > > > > -----Original Message----- > > > From: Dave Thaler [mailto:dthaler@windows.microsoft.com] > > > Sent: Thursday, August 05, 2004 12:33 AM > > > To: enechamkin@broadcom.com; Jean-Francois Mule > > > Cc: ipcdn@ietf.org; Wijnen, Bert (Bert); > > > randy_presuhn@mindspring.com; C. M. Heard > > > Subject: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > > > > > > > > > Here's my MIB Doctor review of this document and what I > > > believe MUST/SHOULD/MAY be fixed. > > > > > > MUST fix > > > -------- > > > 1) There is no IANA Considerations section, and this is now > > > required in the > > > new guidelines. The draft needs something like (based on > > > the template > > > in the guidelines): > > > > > > 9. IANA Considerations > > > > > > The MIB module in this document uses the following > > > IANA-assigned > > > OBJECT IDENTIFIER values recorded in the SMI Numbers > > registry: > > > > > > Descriptor OBJECT IDENTIFIER value > > > ---------- ----------------------- > > > pktcMtaMib { mib-2 XXX } > > > > > > Editor's Note (to be removed prior to publication): > > > the IANA is > > > requested to assign a value for "XXX" under the 'mib-2' > > > subtree and to record the assignment in the SMI > > > Numbers registry. > > > When the assignment has been made, the RFC Editor > is asked to > > > replace "XXX" (here and in the MIB module) with > the assigned > > > value and to remove this note. > > > > > > 2) The page header on pages 2-51 says July 2002 > > > > > > 3) MIB Guidelines say > > > If the module was developed by an IETF working group, then the > > > ORGANIZATION clause MUST provide the full name of the > > > working group > > > ^^^^^^^^^ > > > > > > The draft just uses the WG acronym: > > > ORGANIZATION "IETF IPCDN Working Group " > > > > > > 4) The LAST-UPDATED date predates the REVISION date: > > > LAST-UPDATED "200406160000Z" -- June 16, 2004 > > > REVISION "200407160000Z" > > > ^ > > > > > > 5) pktcMtaBasicSmtaCompliance contains > > > MODULE DOCS-CABLE-DEVICE-MIB > > > MANDATORY-GROUPS { > > > docsDevSoftwareGroupV2 > > > } > > > but RFC2669 is not referenced as a normative reference > > > and docsDevSoftwareGroupV2 isn't in there anyway, only > > > docsDevSoftwareGroup. Is this blocked on the progression > > > of another > > > document containing this? Looks like this used to be in > > > draft-ietf-ipcdn-device-mibv2-*.txt which has now expired. > > > > > > 6) SEQUENCE element #4 `pktcMtaDevCmsSolicitedKeyTimeout' > > > does not match > > > > > > order of columnar objects under `pktcMtaDevCmsEntry'. > > > Should swap the following two lines: > > > pktcMtaDevCmsSolicitedKeyTimeout Unsigned32, > > > pktcMtaDevCmsMaxClockSkew Unsigned32, > > > > > > 7) pktcMtaDevProvisioningState has 'passWithWarning' > > (singular) in the > > > enum, but 'passWithWarnings' (plural) twice in the DESCRIPTION. > > > Also has 'failOtherReason' in the enum but > 'failureOtherReason' > > > in the DESCRIPTION. > > > > > > 8) The comment on page 29 refers to > > > draft-ietf-ipcdn-pktc-signaling-02.txt > > > This should be added to the references section of the doc. > > > Also grammar error "Upper case must be use to" > > > ^^^ > > > > > > 9) Typo in DESCRIPTION of pktcMtaDevCmsKerbRealmName: > > > realm table (pktcMtaDevRealmtable)." > > > ^ capitalize > > > > > > 10) The DESCRIPTION of pktcMtaDevRealmTgsGracePeriod has > > > weird indentation, > > > and includes weird characters (as do several other objects). > > > > > > SHOULD fix > > > ---------- > > > 11) pktcMtaDevErrorOidIndex: say what happens after the > > value 1024 is > > > reached > > > > > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > > > why are OIDs of type SnmpAdminString rather than an > > > OBJECT IDENTIFIER > > > type/subtype? As is, the management station cannot do > > > simple things > > > like expanding the OID into the defined string tokens > > in the MIB. > > > > > > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the > > > DESCRIPTION of > > > > > > these objects is worded as if the type is a string > > rather than an > > > InetAddress (the "dotted" IP address, etc). Technically, > > > there's no > > > dots in the value, only in the displayed version of it. > > > > > > 14) pktcMtaDevServerAddressType: what does it mean for this > > > to be read-write > > > but the dependent InetAddress fields to be read-only? > > I.e., what > > > happens to the latter immediately after the former is set? > > > > > > MAY fix > > > ------- > > > 15) Consider defining a TC for kerberos realm names, since > > > this is used by > > > multiple objects (pktcMtaDevProvKerbRealmName, > > > pktcMtaDevRealmName, > > > and pktcMtaDevCmsKerbRealmName) and has special syntax > > > restrictions > > > (1..255 upper case ASCII chars) > > > > > > 16) The current conformance statements require read-write in > > > implementations > > > to be compliant. Is this intended? Since it currently > > > only supports > > > ipv4, it doesn't seem useful to require read-write > access to the > > > InetAddressType objects. > > > > > > 17) pktcMtaDevSwCurrentVers is redundant with sysDescr, so > > > why is this > > > needed? The draft says: > > > The data presented in this object MUST be > > > identical to the software version information contained > > > in the 'sysDescr' MIB object of the MTA. > > > > > > 18) The MIB guidelines suggest using { pktcMtaMib 0 } for the > > > notification prefix. The draft currently requires two > > > definitions: > > > > > > pktcMtaNotificationPrefix OBJECT IDENTIFIER ::= { > pktcMtaMib 2 } > > > pktcMtaNotification OBJECT IDENTIFIER ::= { > > > pktcMtaNotificationPrefix 0 } > > > > > > Is there a good reason for this? (e.g. already deployed > > > implementations?) > > > > > > 19) What is the expected behavior when reading > > > pktcMtaDevRealmName and > > > pktcMtaDevRealmOrgName when the row is first created > > and they are > > > not set? (There's no DEFVAL, and the MIB doesn't say > > > they have to > > > be set in the initial createAndWait set.) > > > > > > 20) draft-ietf-ipcdn-bpiplus-mib-12.txt is referenced, and is now > > > draft-ietf-ipcdn-bpiplus-mib-13.txt > > > > > > 21) The wording in section 8 varies marginally from the template. > > > > > > Template: > > > > Some of the readable objects in this MIB module (i.e., > > > objects with a > > > > MAX-ACCESS other than not-accessible) may be considered > > > sensitive or > > > > > > Actual: > > > > Some of the readable objects in this MIB module may be > > > considered > > > > sensitive or [...] > > > > > > > > > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtami… Wijnen, Bert (Bert)
- [ipcdn] Review of draft-ietf-ipcdn-pktc-mtamib-04… Dave Thaler
- [ipcdn] snmp version-specific behavior in draft-i… Randy Presuhn
- RE: [ipcdn] Review of draft-ietf-ipcdn-pktc-mtami… Jean-Francois Mule
- [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtami… Jean-Francois Mule
- [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtami… Jean-Francois Mule
- [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtami… Eugene Nechamkin
- [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtami… Wijnen, Bert (Bert)
- [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtami… Dave Thaler
- [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtami… Dave Thaler
- RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-m… Jean-Francois Mule
- RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-m… Dave Thaler
- RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-m… Jean-Francois Mule
- RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-m… Jean-Francois Mule
- RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-m… Wijnen, Bert (Bert)