Wijnen, Bert (Bert | 2 Sep 14:39 2003
Picon

AD Review: draft-ietf-ipcdn-subscriber-mib-12.txt

Too late for Last Call I suspect, but this is what I still find
with SMICng, strict checking:
  E: f(ipcdnsub.mi2), (415,15) Item "diffServMIBDataPathGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (416,15) Item "diffServMIBClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (417,15) Item "diffServMIBClfrElementGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (418,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (419,15) Item "diffServMIBActionGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (420,15) Item "diffServMIBAlgDropGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (421,15) Item "diffServMIBCounterGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (424,11) Item "diffServDataPathStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (430,11) Item "diffServClfrStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (437,11) Item "diffServClfrElementStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (443,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed
  E: f(ipcdnsub.mi2), (449,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (455,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (461,11) Item "diffServAlgDropStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (467,11) Item "diffServDataPathStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (473,11) Item "diffServClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (479,11) Item "diffServClfrElementStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (485,11) Item "diffServMultiFieldClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (492,11) Item "diffServActionStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (498,11) Item "diffServCountActStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (504,11) Item "diffServAlgDropStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (510,11) Item "diffServAlgDropType" should be IMPORTed

The draft-ietf-ops-mib-review-guidelines-02.txt document says about this,
sect 4.4. pages 10 and 11):
   ... snip ...
   otherwise would be.  External symbols referenced by compliance
   statements and capabilities statements MAY therefore be listed in the
(Continue reading)

Wilson Sawyer | 3 Sep 03:30 2003
Picon
Picon

Re: AD Review: draft-ietf-ipcdn-subscriber-mib-12.txt

Bert - thank you for the review. Responses interspersed.
WG members: I need help with:
     (1) ipv4z addresses (see discussion about scoped link-local addresses)
     (2) StorageType (nonVolatile as minimum requirement, or ?)
Rich & Jean-Francois: need help with RFC2669/2670 status

Thanks
Wilson

"Wijnen, Bert (Bert)" wrote:

> Too late for Last Call I suspect, but this is what I still find
> with SMICng, strict checking:
>   E: f(ipcdnsub.mi2), (415,15) Item "diffServMIBDataPathGroup" should be IMPORTed
>   E: f(ipcdnsub.mi2), (416,15) Item "diffServMIBClfrGroup" should be IMPORTed
>   E: f(ipcdnsub.mi2), (417,15) Item "diffServMIBClfrElementGroup" should be IMPORTed
>   E: f(ipcdnsub.mi2), (418,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed
>   E: f(ipcdnsub.mi2), (419,15) Item "diffServMIBActionGroup" should be IMPORTed
>   E: f(ipcdnsub.mi2), (420,15) Item "diffServMIBAlgDropGroup" should be IMPORTed
>   E: f(ipcdnsub.mi2), (421,15) Item "diffServMIBCounterGroup" should be IMPORTed
>   E: f(ipcdnsub.mi2), (424,11) Item "diffServDataPathStatus" should be IMPORTed
>   E: f(ipcdnsub.mi2), (430,11) Item "diffServClfrStatus" should be IMPORTed
>   E: f(ipcdnsub.mi2), (437,11) Item "diffServClfrElementStatus" should be IMPORTed
>   E: f(ipcdnsub.mi2), (443,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed
>   E: f(ipcdnsub.mi2), (449,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed
>   E: f(ipcdnsub.mi2), (455,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed
>   E: f(ipcdnsub.mi2), (461,11) Item "diffServAlgDropStatus" should be IMPORTed
>   E: f(ipcdnsub.mi2), (467,11) Item "diffServDataPathStorage" should be IMPORTed
>   E: f(ipcdnsub.mi2), (473,11) Item "diffServClfrStorage" should be IMPORTed
>   E: f(ipcdnsub.mi2), (479,11) Item "diffServClfrElementStorage" should be IMPORTed
(Continue reading)

Wijnen, Bert (Bert | 3 Sep 18:01 2003
Picon

RE: AD Review: draft-ietf-ipcdn-subscriber-mib-12.txt

Inline for those pieces that warrant another comment/answer from me

Thanks,
Bert 

> -----Original Message-----
> From: Wilson Sawyer [mailto:sawyerwd <at> comcast.net]
> Sent: woensdag 3 september 2003 3:31
> To: Wijnen, Bert (Bert)
> Cc: 'Woundy, Richard'; IPCDN WG (E-mail); jf.mule <at> cablelabs.com
> Subject: Re: [ipcdn] AD Review: draft-ietf-ipcdn-subscriber-mib-12.txt
> 
> 
> Bert - thank you for the review. Responses interspersed.
> WG members: I need help with:
>      (1) ipv4z addresses (see discussion about scoped link-local addresses)
>      (2) StorageType (nonVolatile as minimum requirement, or ?)

So realize that what you have currently defined is:
   - implementations MUST support nonVolatile
   - implementations are free to NOT support any of the other
     storageTypes.
   - when an operator uses the system, he can only rely on nonVolatile
     being supported, and all the otehr storageTypes may or may not
     be present. So basically the compliance statement tells them
     they can ONLy assume nonVolatile.
So... in principle you could vene remove the StorageType object/column
and put in the xxxEntry DESCRIPTION clasue:
   "all entries in this table MUST be saved in stable storage so that
    they will survive a restart/reboot."
(Continue reading)

Jean-Francois Mule | 5 Sep 17:27 2003

fyi - Important Meeting Dates for IETF 58

Thursday September 6
 - Working Group and BOF scheduling begins === Consider this a call for
discussion items

Week of September 8 
 - Registration begins

Monday October 20, 09:00 ET
 - Internet Draft Cut-off for initial document (-00)
   submission at 09:00 ET 

Monday October 27, 09:00 ET 
 - Internet Draft final submission cut-off at 09:00 ET

November 9-14 
 - 58th IETF Meeting in Minneapolis, MN, USA
Kevin Luehrs | 5 Sep 18:03 2003

RE: Ping capability in draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt

Randy;

I apologize for the delay in responding. We will take a look at the
disman-remops-mib draft and compare it to the
ipcdn-cable-gateway-tools-mib i-d. The existing issued CableHome 1.0 and
CableHome 1.1 specifications both refer to the CableHome CTP MIB, which
is the foundation for the ipcdn-cable-gateway-tools-mib, and it will be
non-trivial to change the specifications to refer instead to the
disman-remops-mib. But we agree that there are advantages to unifying
common functionality within the IETF. I will set up a meeting to discuss
this issue with ipcdn-cable-gateway mib authors.

Regards,

	Kevin

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Luehrs
Project Director, CableHome Engineering
CableLabs
400 Centennial Parkway
Louisville, CO 80027
303 661 9100
fax 303 661 9199
k.luehrs <at> cablelabs.com

-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com] 
Sent: Sunday, August 17, 2003 2:04 PM
To: Eduardo Cardona; Kevin Luehrs; donald.mah <at> linksys.com; Doug Jones at
(Continue reading)

Jean-Francois Mule | 6 Sep 01:09 2003

RE: MIB doctor review of: draft-ietf-ipcdn-pktc-mtamib-01.txt (Part 1)

Mike and Bert,
 
Find below the first response to all the comments we received to date
on the pcdn MTA MIB draft 01.
 
It addresses Bert's comments as well as Mike's comments (#1 thru #10).
We will send our responses to technical comments #11 next week. In the
meantime, if you have any reaction on how we've addressed these so far,
let Eugene or myself know.
 
Thanks,
Eugene and Jean-Francois.
--- Comments from Bert Wijnen received on 7/22/03 On Tue, 22 Jul 2003, Wijnen, Bert (Bert) wrote: > > 1. PacketCable/IPCablecom MTA MIB > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-01.txt > > > > > Bad chars at 2053 > Bad chars at 2056 > -: 2 lines containing non-US-ASCII characters Fixed; replaced ô with double quotes for reference [EN 300 659-1]. > W: f(ipcdnPktcMta.mi2), (1347,4) NOTIFICATION-GROUP > "pktcMtaNotificationGroup" is not used in a > MODULE-COMPLIANCE in current module Fixed; added pktcMtaNotificationGroup in pktcMtaBasicCompliance. > You IMPORT from IF-MIB (RFC2863) and SNMP-FRAMEWORK-MIB (RFC3411) > and SNMPv2-MIB (RFC3418). So those must be listed as normative > references Added those 3 RFCs as normative references. Also deleted old informative snmp RFCs. --- Comments from Mike received on ipcdn list on 7/23/03 > BTW, in addition to Bert's comments below I notice that > both draft-ietf-ipcdn-pktc-mtamib-01.txt and > draft-ietf-ipcdn-pktc-signaling-01.txt have a > second copy of the standard Intellectual Property stuff > mixed into the Full Copyright statement. Fixed. --- Comments from Mike received on ipcdn list on 8/11/03 > -----Original Message----- > From: C. M. Heard [mailto:heard <at> pobox.com] > Sent: Monday, August 11, 2003 10:29 AM > To: Ipcdn (E-mail) > Cc: Eugene Nechamkin; Jean-Francois Mule; Bert Wijnen > Subject: MIB doctor review of: > draft-ietf-ipcdn-pktc-mtamib-01.txt (Part 1) ...snip... > 1.) I-D Boilerplate -- please remove the citation [RFC2026] > in the first paragraph of the "Status of this Memo" section. > See http://www.ietf.org/ID-nits.html Section 1.1, 8th bullet. ok, done in draft-02. Mike, note that ID-nits does not prohibits the reference at all: it simply says: # Do not add a numbered reference in the ID boilerplate to RFC 2026 # (makes it harder for the RFC editor to process the document when # they strip off the ID boilerplate) So as long as the reference is in the form [RFC2026], I think it is ok. Anyway, we removed it for this draft per your recommendation. > 2.) Abstract -- OK > > 3.) MIB Boilerplate -- OK > > 4.) IPR Notices -- (a) the minimum required notices are > present, but are not verbatim copies of 10.4(A) and 10.4(B) > of RFC 2026, and the editing process has introduced at least > one (and possibly three) minor errors or stylistic anomalies > that need to be corrected: > > s/described in document/described in this document/ > > s/implementers or users/implementors or users/ > > s/that may cover technology that/which may cover technology that/ ok, done in draft-02 > (b) no claims are noted (10.4(D) of RFC 2026 is absent), and > this appears to be OK since the following search of the IPR > statements on the IETF web site did not turn up anything: ...snip... No action required from co-authors. > 5.) References -- in addition to the non-ASCII characters in > one of the references (detailed in #10(a) below), there are > the following substantive issues to address: > (a) Bert Wijnen already pointed out that: > > You IMPORT from IF-MIB (RFC2863) and SNMP-FRAMEWORK-MIB > (RFC3411) and > > SNMPv2-MIB (RFC3418). So those must be listed as normative > > references. ok, done in draft-02. > (b) The normative reference [RFC3289] should be removed. It > is not cited anywhere in the text, nor does the > PKTC-IETF-MTA-MIB import anything from DIFFSERV-DSCP-TC or > DIFFSERV-MIB. ok, done in draft-02. > (c) The informative reference [RFC2026] should be removed. > It is cited only in the I-D boilerplate, which will be > stripped off prior to publication as an RFC and is not > allowed to have a citation (see #2 above). ok, see comment above; done in draft-02. > (d) The following PacketCable references need to be updated > to point to the latest versions of the documents: > > Current reference Latest version > > PKT-SP-MIB-MTA-I06-030415 PKT-SP-MIB-MTA-I07-030728 > PKT-SP-PROV-I06-030415 PKT-SP-PROV-I07-030728 > PKT-SP-SEC-I08-030415 PKT-SP-SEC-I09-030728 ok, done in draft-02. > When you make these updates, please be sure to get the > spelling of the document number right. In the current draft > I see that all occurrences of [PKT-SP-PROV-IO6-030415] have > the letter "O" in "IO6" instead of the numeral "0". This is > also true for the citation of [PKT-SP-MIB-MTA-IO6-030415] at > the beginning of Section 3. ok, done in draft-02. > You may also want to consider including the URLs where these > documents can be found (in addition to including the title > and document number): > > http://www.packetcable.com/downloads/specs/PKT-SP-MIB-MTA-I07- > 030728.pdf > http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I07-030728.pdf > http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I09-030728.pdf The PacketCable specs are revised 3 times a year so this link will become obsolete soon. Therefore, we would rather not include the specific URLs, but just http://www.packetcable.com/specifications/ > (e) I could find no citations for the following informative > references: added citation text and informative references to the ETSI and ITU-T MTA MIB publications: [ETSI TS 101 909-8] ETSI TS 101 909-8: "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 8: Media Terminal Adaptor (MTA) Management Information Base (MIB)". [ITU-T-J168] IPCablecom media terminal adapter (MTA) MIB requirements, J.168, ITU-T, March, 2001. Note that the intent of this ID is to become an IETF RFC that will obsolete the 3 separate MIB definitions. > [ETSI TS 101 909-4], removed. > [ETSI TS 101 909-9], removed. > [EN 300 001], kept, added citation text in section 3. > and [EN 300 659-1]. kept, added citation text in section 3. > They should either be > cited or removed. kep > (f) Although [RFC3291] is indeed the correct reference for > the InetAddress/InetAddressType definitions, there is a > possibility that it will be replaced by > draft-ietf-ops-rfc3291bis-01.txt or a successor by the time > this document is published. To allow for this possibility I > recommend adding an RFC Editor note such as the following: > > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * * > * 1.) If <draft-ietf-ops-rfc3291bis-01.txt> (or its * > * successor) is to be published as an RFC concurrently * > * with this document, please update normative reference * > * [RFC3291] to point to that RFC, instead of RFC 3291. * > * * > ************************************************************ > ok, per Mike's subsequent email to co-authors, we have added the following text after the reference [RFC3291]: ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * The I-D <draft-ietf-ops-rfc3291bis-01.txt> (or a * * successor) is expected to eventually replace RFC 3291. * * If that draft (or a successor) is published as an RFC * * prior to or concurrently with this document, then the * * normative reference [RFC3291] should be updated to * * point to the replacement RFC, and the reference tag * * [RFC3291] should be updated to match. * * * ************************************************************ > (you may want to consider collecting all RFC Editor > notes together and putting them at the end, as was > done in <draft-ietf-atommib-rfc2493bis-01.txt> and > <draft-ietf-atommib-rfc2558bis-01.txt> ... but be sure not to > eliminate the required embedded notes in the MIB module if > you do that) ok, good idea but not actually done in draft02. > 6.) Security Considerations Section -- the MIB security > template has been followed, but the presentation is not as > clear as I would like and there appear to be some some > missing and misplaced entries in the lists of writeable > objects. To address the latter the following changes are suggested: > > FROM: > ! - All writable objects in the pktcMtaDevServer and > ! pktcMtaDevRealmTable groups share the potential, if SET > maliciously, ! to prevent an MTA from provisioning properly, > hence there are ! considered very sensitive for service > delivery, in particular: > pktcMtaDevProvisioningTimer, > pktcMtaDevServerAddressType, > pktcMtaDevServerDns1, > pktcMtaDevServerDns2 - these two objects, if SET maliciously, > will prevent the MTA from being authenticated and > consequently from ! getting the telephony services. > pktcMtaDevSnmpEntity, > pktcMtaDevProvConfigHash, > pktcMtaDevProvConfigKey, > pktcMtaDevProvSolicitedKeyTimeout, > pktcMtaDevRealmName, > pktcMtaDevRealmOrgName, > ! pktcMtaDevRealmStatus - this object, if SET maliciously, would > ! cause the whole row of the table to be deleted which will > deny the ! prevent the MTA from getting the telephony services. > TO: > ! - All writable objects in the pktcMtaDevServer group and > some in ! the pktcMtaDevRealmTable share the potential, if > SET maliciously, ! to prevent an MTA from provisioning > properly. Hence they are ! considered very sensitive for > service delivery. In particular: > pktcMtaDevProvisioningTimer, > pktcMtaDevServerAddressType, > pktcMtaDevServerDns1, > pktcMtaDevServerDns2 - these two objects, if SET maliciously, > will prevent the MTA from being authenticated and > consequently from ! getting telephony services. > + pktcMtaDevTimeServer, > + pktcMtaDevConfigFile, > pktcMtaDevSnmpEntity, > pktcMtaDevProvConfigHash, > pktcMtaDevProvConfigKey, > pktcMtaDevProvSolicitedKeyTimeout, > pktcMtaDevRealmName, > pktcMtaDevRealmOrgName, > + pktcMtaDevRealmUnsolicitedKeyMaxTimeout, > + pktcMtaDevRealmUnsolicitedKeyNomTimeout, > + pktcMtaDevRealmUnsolicitedKeyMaxRetries, > ! pktcMtaDevRealmStatus - this object, if SET maliciously, could > ! cause the whole row of the table to be deleted which may > prevent ! MTA from getting telephony services. Ok, done in draft-02. > FROM: > - All writable objects in the pktcMtaDevCmsTable table share the > potentional, if SET maliciously, to disrupt the telephony > service by > altering which Call Management Server the MTA must send signaling > registration to, in particular: > pktcMtaDevCmsFqdn, > pktcMtaDevCmsKerbRealmName, > pktcMtaDevCmsMaxClockSkew, > pktcMtaDevCmsSolicitedKeyTimeout, > pktcMtaDevCmsUnsolicitedKeyMaxTimeout, > pktcMtaDevCmsUnsolicitedKeyNomTimeout, > ! pktcMtaDevRealmUnsolicitedKeyMaxRetries - this object, > if set to > ! a zero value '0', may prevent an MTA from retry its attempt to > establish a security association with the CMS, > pktcMtaDevCmsStatus. > TO: > - All writable objects in the pktcMtaDevCmsTable table share the > potentional, if SET maliciously, to disrupt the telephony > service by > altering which Call Management Server the MTA must send signaling > registration to, in particular: > pktcMtaDevCmsFqdn, > pktcMtaDevCmsKerbRealmName, > pktcMtaDevCmsMaxClockSkew, > pktcMtaDevCmsSolicitedKeyTimeout, > pktcMtaDevCmsUnsolicitedKeyMaxTimeout, > pktcMtaDevCmsUnsolicitedKeyNomTimeout, > ! pktcMtaDevCmsUnsolicitedKeyMaxRetries - this object, if set to > ! a zero value '0', may prevent an MTA from retrying its attempt to > establish a security association with the CMS, > pktcMtaDevCmsStatus. ok, done in draft-02. > FROM: > - The following objects, if SET maliciously will not have an > immediate effect on service but they may impact the service > performace and may cause avalanche attacks on provisioning servers > including Kerberos KDC servers on massive device reboots: > pktcMtaDevResetKrbTickets - if set to true, will cause > an MTA to > request a new Kerberos ticket at reboot. > pktcMtaDevRealmPkinitGracePeriod - if set to short > periods, will > cause MTA to renew its tickets more frequently, > pktcMtaDevRealmTgsGracePeriod (same as above). > - pktcMtaDevRealmUnsolicitedKeyMaxTimeout, > - pktcMtaDevRealmUnsolicitedKeyNomTimeout. > TO: > - The following objects, if SET maliciously will not have an > immediate effect on service but they may impact the service > performace and may cause avalanche attacks on provisioning servers > including Kerberos KDC servers on massive device reboots: > pktcMtaDevResetKrbTickets - if set to true, will cause > an MTA to > request a new Kerberos ticket at reboot. > pktcMtaDevRealmPkinitGracePeriod - if set to short > periods, will > cause MTA to renew its tickets more frequently, > pktcMtaDevRealmTgsGracePeriod (same as above), > > (changed lines indicated by '!' in left margin, added lines > by '+', deleted lines by '-'). ok, done in draft-02. > Note that suggested addition/regrouping of objects in the > lists above assumes that > > pktcMtaDevRealmUnsolicitedKeyMaxTimeout > pktcMtaDevRealmUnsolicitedKeyNomTimeout > pktcMtaDevRealmUnsolicitedKeyMaxRetries > > are for communication with a Key Distribution Center (KDC) > and so can affect the provisioning process whilst > > pktcMtaDevCmsUnsolicitedKeyNomTimeout > pktcMtaDevCmsUnsolicitedKeyMaxTimeout > pktcMtaDevCmsUnsolicitedKeyMaxRetries > > are used for communication with a Call Management server > (CMS) and so can affect telephony services but not > provisioning (that, at least, is what I concluded from > Section 3.4 and from the object DESCRIPTION clauses). correct. > Even with the above fixes the Security Considerations section > would not be a model of clarity. The problem is that the > presentation style doesn't make it perfectly clear exactly > what vulnerabilities are associated with each object. Here > is an example of a possibly better style for the first section above: > > - All writable objects in the pktcMtaDevServer group and some in > the pktcMtaDevRealmTable share the potential, if SET maliciously, > to prevent an MTA from provisioning properly. Hence they are > considered very sensitive for service delivery. The objects in > question are: > > pktcMtaDevProvisioningTimer > pktcMtaDevServerAddressType > pktcMtaDevServerDns1 > pktcMtaDevServerDns2 > pktcMtaDevTimeServer > pktcMtaDevConfigFile > pktcMtaDevSnmpEntity > pktcMtaDevProvConfigHash > pktcMtaDevProvConfigKey > pktcMtaDevProvSolicitedKeyTimeout > pktcMtaDevRealmName > pktcMtaDevRealmOrgName > pktcMtaDevRealmUnsolicitedKeyMaxTimeout > pktcMtaDevRealmUnsolicitedKeyNomTimeout > pktcMtaDevRealmUnsolicitedKeyMaxRetries > pktcMtaDevRealmStatus > > Certain of the above objects have additional specific > vulnerabilites. > pktcMtaDevServerDns1 and pktcMtaDevServerDns2, if SET maliciously, > could prevent the MTA from being authenticated and > consequently from > getting telephony services. pktcMtaDevRealmStatus, if SET > maliciously, could cause the whole row of the table to be deleted > which may prevent MTA from getting telephony services. ok, done in draft-02. > > The authors may wish to consider reworking the style of the > entire section to something along these lines. ok, see attempt we made to improve the section in draft-02. In addition, we deleted 2 security consideration paragraphs on 2 readable objects: pktcMtaDevEndPntCount and pktcMtaDevHttpAccess. After more reviews, we do not believe those objects actually pose real threats given that the endpoint naming convention is in the spec and easy to figure out and that pktcMtaDevHttpAccess text was not really relevant. > It would also > be good to make consistent statements about retry objects, > RowStatus objects, and so on in the different lists. > > Finally, this section includes only the standard "deployment > of SNMP versions prior to SNMPv3 is NOT RECOMMENDED." It has > been my understanding that versions of SNMP prior to SNMPv3 > are not permitted for DOCSIS devices. If that's true, then > the last paragraph should say that instead of the standard stuff. For MTAs, anything other than SNMPv3 is not recommended in our current specs - at least that is true today for PacketCable. The issue we're facing is some service providers still have SNMPv2. So we decided it is sufficient to leave this section as-is per the recommendation of http://www.ops.ietf.org/mib-security.html and take the 2 last paragraphs of mib-security.html as-is. > 7.) IANA Considerations Section -- OK (none present and none > required). > > 8.) Copyright notices -- the Full Copyright statement has a > second copy of the standard Intellectual Property notices in > front of it. That shouldn't be there and needs to be removed. ok, done in draft-02. > 9.) MIB compilation -- Bert already pointed out the following > warning message from SMICng: > > W: f(ipcdnPktcMta.mi2), (1347,4) NOTIFICATION-GROUP > "pktcMtaNotificationGroup" is not used in a > MODULE-COMPLIANCE in current module ok, done in draft-02, included pktcMtaNotificationGroup into MANDATORY-GROUPS. > > The smilint e-mail robot says the same thing: > > This command (smilint 0.4.2-pre1, as of Wed Jul 23 17:37:01 > 2003) has been processed to get the following results: > smilint -m -s -l 6 -i namelength-32 PKTC-IETF-MTA-MIB > > PKTC-IETF-MTA-MIB:1340: [5] {group-unref} warning: current > group `pktcMtaNotificationGroup' is not referenced in this module > > Although this is not a violation of the SMIv2 rules, we > recommend in the MIB review guidelines that a GROUP clause be > present for each optional group so that it is obvious that it > was not an inadvertent omission; see > <draft-ietf-ops-mib-review-guidelines-01.txt>, > Sec. 4.8, last bullet on p. 23. In this case it appears that > this group was indeed inadvertently omitted from the > MANDATORY-GROUPS clause; see #11(w) below for details. Fixed. > > 10.) Other issues, e.g., stuff in > http://www.ietf.org/ID-nits.html that is not covered above: > > (a) Bert Wijnen noted 2 lines containing non-US-ASCII characters: > > > Bad chars at 2053 > > > Bad chars at 2056 > > > -: 2 lines containing non-US-ASCII characters Fixed. > > The fix that I recommend is to change the text starting at line 2053 > from: > [EN 300 659-1] EN 300 659-1: ôPublic Switched Telephone Network > (PSTN); Subscriber line protocol over the > local loop > for display (and related) services; Part 1: On hook > data transmissionö. > to: > [EN 300 659-1] EN 300 659-1: "Public Switched Telephone Network > (PSTN); Subscriber line protocol over the > local loop > for display (and related) services; Part 1: On hook > data transmission". > assuming, of course, that this reference is retained. ok, ref deleted. > (b) There are a few lines that go over 72 characters, > however, that goes away if the trailing blanks are removed. > It would be nice to fix that in the next version of the > draft, but it's not essential, since the trailing blanks are > stripped by the RFC Editor do that as a side-effect of > "nroff'ing" the document. ok, no action taken. > > (c) Please make the following change globally: s/RFC-3495/RFC > 3495/ Note that the MIB module and the reference [RFC3495] > are affected. ok, done in draft-02. > > (d) Section 2.2: s/over the DOCSIS/over a DOCSIS/ ok, done in draft-02. > > (e) Section 2.3: s/the cable or hybrid system/a cable or > hybrid system/ (multiple occurrences); s/the CM part/the CM part,/ ok, done in draft-02. > > (f) Section 2.8: Consider appending the following sentence: > > Commonly used DHCP options are defined in [RFC2132]. ok, done in draft-02. > > (g) Section 2.10: s/algorithm/device/ comment rejected by co-authors, not changed. > > (h) Section 2.11: s/system of the back office/a system of > back office/ ok, done in draft-02. > > (i) Section 3.1, 5th paragraph: s/First two groups/The first > two groups/ ok, done in draft-02. > > (j) Section 3.1, 6th paragraph: s/Third group/The third group/ ok, done in draft-02. > > (k) Section 3.2, 1st paragraph: suggest to revise as follows: ok, done in draft-02. > > This group contains management information describing the > parameters of the MTA device itself. It also contains some > objects to control the MTA state. Some highlights are as follows: > > (l) Section 3.3, 1st paragraph: suggest to revise as follows: > > This group contains management information describing the > back office servers and the parameters assigned to the > communication timeouts. It also contains some objects > controlling the initial MTA interaction with the Provisioning Server. ok, done in draft-02. > > (m) Section 3.4, 1st paragraph: suggest to revise as follows: > > This group contains management information describing the > security-related characteristics of the MTA. It also > contains two tables describing logical dependencies and > parameters necessary to establish security associations > between the MTA and other components of the back office. > Some higliights are: ok, done in draft-02. > > (n) Section 3.5: add blank lines between consecutive > paragraphs, and also before and after each bullet item in the > bullet list. Please rewrite the 2nd paragraph so that it is > clear what it means. In the 1st sentence of the 2nd paragraph > after the bullet list s/defined by the number of > parameters/defined by a number of parameters/ Please use the > definite and indefinite articles when customary (e.g., > s/Realm Table is indexed/The Realm Table is indexed/ and > s/contains conceptual column/contains a conceptual column). > This whole section is hard to read and needs major editorial rework. ok, done in draft-02. > end. 
Randy Presuhn | 6 Sep 02:56 2003
Picon

Re: RE: [ipcdn] Ping capability in draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt

Hi Kevin -

Thanks for the update.  I understand the complications that can arise when
an externally developed specification comes into the IETF.  Regardless
of whether the ipcdn WG decides to use the disman work, we'd still
appreciate any feedback on it that you might have.

Randy Presuhn,
disman WG chair

----- Original Message ----- 
From: "Kevin Luehrs" <k.luehrs <at> cablelabs.com>
To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>; "Eduardo Cardona" <e.cardona <at> cablelabs.com>;
<donald.mah <at> linksys.com>; "Doug
Jones at YAS" <doug <at> yas.com>
Cc: "Disman (E-mail)" <disman <at> ietf.org>; <ipcdn <at> ietf.org>
Sent: Friday, September 05, 2003 9:03 AM
Subject: [Disman] RE: [ipcdn] Ping capability in draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt

Randy;

I apologize for the delay in responding. We will take a look at the
disman-remops-mib draft and compare it to the
ipcdn-cable-gateway-tools-mib i-d. The existing issued CableHome 1.0 and
CableHome 1.1 specifications both refer to the CableHome CTP MIB, which
is the foundation for the ipcdn-cable-gateway-tools-mib, and it will be
non-trivial to change the specifications to refer instead to the
disman-remops-mib. But we agree that there are advantages to unifying
common functionality within the IETF. I will set up a meeting to discuss
this issue with ipcdn-cable-gateway mib authors.

Regards,

Kevin

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Luehrs
Project Director, CableHome Engineering
CableLabs
400 Centennial Parkway
Louisville, CO 80027
303 661 9100
fax 303 661 9199
k.luehrs <at> cablelabs.com

-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com]
Sent: Sunday, August 17, 2003 2:04 PM
To: Eduardo Cardona; Kevin Luehrs; donald.mah <at> linksys.com; Doug Jones at
YAS
Cc: Disman (E-mail); ipcdn <at> ietf.org
Subject: [ipcdn] Ping capability in
draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt

Hi -

Glancing through draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt,
I'm left wondering why it didn't just reference RFC 2925 for the
ping capability.  Since an update to RFC 2925 is in the works
(draft-ietf-disman-remops-mib-v2-00.txt), are there any specific
changes that we might make that would make the duplication
unnecessary?

Randy Presuhn (disman WG chair)

> From: <Internet-Drafts <at> ietf.org>
> To: <IETF-Announce:>
> Cc: <ipcdn <at> ietf.org>
> Sent: Wednesday, June 25, 2003 7:54 AM
> Subject: I-D ACTION:draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt
>

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the IP over Cable Data Network Working
Group of the IETF.
>
> Title : Cable Gateway Tools Management Information Base for
>                           CableHome compliant Residential Gateways
> Author(s) : E. Cardona et al.
> Filename : draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt
> Pages : 20
> Date : 2003-6-24
>
> This memo defines a portion of the Management Information Base (MIB)
> for use with network management protocols in the Internet community.
> In particular, it defines a basic set of managed objects for SNMP-
> based management of CableHome compliant WAN Gateway Devices and home
> routers.  Specifically, this MIB defines managed objects for both a
> connection speed tool and an ICMP 'ping' tool between the Gateway and
> devices on the LAN.
> This memo specifies a MIB module in a manner that is compliant to the
> SNMP SMIv2 [5][6][7].  The set of objects is consistent with the SNMP
> framework and existing SNMP standards.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-tools
-mib-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv <at> ietf.org.
> In the body type:
> "FILE
/internet-drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

C. M. Heard | 6 Sep 23:39 2003
Picon

RE: MIB doctor review of: draft-ietf-ipcdn-pktc-mtamib-01.txt (Part 1)

On Fri, 5 Sep 2003, Jean-Francois Mule wrote:
> Find below the first response to all the comments we received to date 
> on the pcdn MTA MIB draft 01. 
>  
> It addresses Bert's comments as well as Mike's comments (#1 thru #10).
> We will send our responses to technical comments #11 next week. In the
> meantime, if you have any reaction on how we've addressed these so far,
> let Eugene or myself know.
...
> > 1.) I-D Boilerplate -- please remove the citation [RFC2026]
> > in the first paragraph of the "Status of this Memo" section. 
> > See http://www.ietf.org/ID-nits.html Section 1.1, 8th bullet.
> ok, done in draft-02.
> Mike, note that ID-nits does not prohibits the reference at all: it
> simply says:
> # Do not add a numbered reference in the ID boilerplate to RFC 2026
> # (makes it harder for the RFC editor to process the document when
> # they strip off the ID boilerplate)
> So as long as the reference is in the form [RFC2026], I think it is
> ok. Anyway, we removed it for this draft per your recommendation.

You may be right.  This point is not entirely clear.  I had assumed
that the problem would not be so much from having a numbered
citation such as [1] vs. [RFC2026] but from having a dangling
reference (renumbering of references, and consequent difficulty for
the RFC Editor, only happens if one insists on removing RFC 2026
from the References section if it's not actually cited).  Bert, I
think you still have some requests to put to the IETF Secretariat
w.r.t ID-nits;  please consider having this point clarified when/if
you get around to doing that.

> > (d) The following PacketCable references need to be updated 
> > to point to the latest versions of the documents:
> > 
> > Current reference           Latest version
> > 
> > PKT-SP-MIB-MTA-I06-030415   PKT-SP-MIB-MTA-I07-030728
> > PKT-SP-PROV-I06-030415      PKT-SP-PROV-I07-030728
> > PKT-SP-SEC-I08-030415       PKT-SP-SEC-I09-030728
> ok, done in draft-02.
...
> > You may also want to consider including the URLs where these 
> > documents can be found (in addition to including the title 
> > and document number):
> > 
> > http://www.packetcable.com/downloads/specs/PKT-SP-MIB-MTA-I07-030728.pdf
> > http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I07-030728.pdf
> > http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I09-030728.pdf
> The PacketCable specs are revised 3 times a year so this link will
> become obsolete soon. Therefore, we would rather not include the
> specific URLs, but just http://www.packetcable.com/specifications/

Sounds OK to me.  However, you should probably consider adding some
words to the introductory part of the spec to let the readers know
that they should look for the latest versions of the PacketCable
specs by title rather than document number.  This is especially
important since two of these documents are normative references.  
We'd prefer to be able to point at stable documents, but my
recollection is that the titles don't change (at least not much) and
if a specific document number gets obsoleted you will see that
stated in the replacement document.

> > (e) I could find no citations for the following informative
> > references:  
> added citation text and informative references to the ETSI and ITU-T
> MTA MIB publications:
> [ETSI TS 101 909-8] ETSI TS 101 909-8: "Access and Terminals (AT);
>                     Digital Broadband Cable Access to the Public
>                     Telecommunications Network; IP Multimedia Time
>                     Critical Services; Part 8: Media Terminal
>                     Adaptor (MTA) Management Information Base
>                     (MIB)".
> 
> [ITU-T-J168] IPCablecom media terminal adapter (MTA) MIB
>              requirements, J.168, ITU-T, March, 2001.
> 
> Note that the intent of this ID is to become an IETF RFC that will
> obsolete the 3 separate MIB definitions.

Good, that's useful information for the document readers (as I
recall, you had to give me an education on this point :-).

[ ... skipping down to security considerations ... ]
> In addition, we deleted 2 security consideration paragraphs on 2
> readable objects: pktcMtaDevEndPntCount and pktcMtaDevHttpAccess.
> After more reviews, we do not believe those objects actually pose real
> threats given that the endpoint naming convention is in the spec and
> easy to figure out and that pktcMtaDevHttpAccess text was not really
> relevant.

Fine by me, you are the subject matter experts.

> > Finally, this section includes only the standard "deployment 
> > of SNMP versions prior to SNMPv3 is NOT RECOMMENDED."  It has 
> > been my understanding that versions of SNMP prior to SNMPv3 
> > are not permitted for DOCSIS devices.  If that's true, then 
> > the last paragraph should say that instead of the standard stuff.
> For MTAs, anything other than SNMPv3 is not recommended in our current
> specs - at least that is true today for PacketCable. The issue we're
> facing is some service providers still have SNMPv2.

Just out of curiousity, do you really mean classic party-based
SNMPv2, which these days is usually called SNMPv2p?  I would guess
that this is a typo, and you meant to say SNMPv1 (the previous
standard, widely deployed) or perhaps SNMPv2c (the experimental
prococol, not so widely deployed).  But that's not really important.

> So we decided it is sufficient to leave this section as-is per the
> recommendation of http://www.ops.ietf.org/mib-security.html and take
> the 2 last paragraphs of mib-security.html as-is.

Fine by me.

> > (g) Section 2.10:  s/algorithm/device/
> comment rejected by co-authors, not changed.

The problem that I was trying to address is that this usage of the
word algorithm does not seem to be correct:

2.10 Voice Coder-Decoder

   Voice COder-DECoder (CODEC) - is an algorithm used to transform the
   audio information to the packets of digitized Data being transferred
   over the IP networks.

I say that because an encoder or decoder _implements_ an encoding or
decoding algorithm, but is not identical with that algorithm.

If you don't care for the word "device", some other possibilities
are "element" or "system component".

Mike
Wijnen, Bert (Bert | 7 Sep 20:39 2003
Picon

RE: RE: MIB doctor review of: draft-ietf-ipcdn-pktc-mtami b-01.txt (Part 1)

W.r.t.
> > > (d) The following PacketCable references need to be updated 
> > > to point to the latest versions of the documents:
> > > 
> > > Current reference           Latest version
> > > 
> > > PKT-SP-MIB-MTA-I06-030415   PKT-SP-MIB-MTA-I07-030728
> > > PKT-SP-PROV-I06-030415      PKT-SP-PROV-I07-030728
> > > PKT-SP-SEC-I08-030415       PKT-SP-SEC-I09-030728
> > ok, done in draft-02.
> ...
> > > You may also want to consider including the URLs where these 
> > > documents can be found (in addition to including the title 
> > > and document number):
> > > 
> > > 
> http://www.packetcable.com/downloads/specs/PKT-SP-MIB-MTA-I07-030728.pdf
> > > 
> http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I07-030728.pdf
> > > 
> http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I09-030728.pdf
> > The PacketCable specs are revised 3 times a year so this link will
> > become obsolete soon. Therefore, we would rather not include the
> > specific URLs, but just http://www.packetcable.com/specifications/
> 
> Sounds OK to me.  However, you should probably consider adding some
> words to the introductory part of the spec to let the readers know
> that they should look for the latest versions of the PacketCable
> specs by title rather than document number.  This is especially
> important since two of these documents are normative references.  
> We'd prefer to be able to point at stable documents, but my
> recollection is that the titles don't change (at least not much) and
> if a specific document number gets obsoleted you will see that
> stated in the replacement document.
> 

Let me point out that IETF/IESG basiscally wants references 
(especially NORMATIVE) to be to stable documents.
I have seen docs pushed back by IESG in the past for not having 
stable normative references. So pls make sure it is very
clear how people can get to the proper document (that is
being referenced).

Bert
Wijnen, Bert (Bert | 8 Sep 15:06 2003
Picon

FW: [Bridge-mib] VlanID and VlanIDOrAny

Some (good) feedback on the use of VLANID.
Can we get some answers and or discussion on this?

Andrew, allowing users of a TC to spcify what one specific 
value means is quite common, specifically for TCs that
end in xxxOrZero or xxxOrNone, pls see the many TCs
we have defined that way.

Thanks,
Bert 

-----Original Message-----
From: Andrew Smith [mailto:ah_smith <at> acm.org]
Sent: zondag 7 september 2003 22:40
To: 'Wijnen, Bert (Bert)'; 'Bridge-Mib (E-mail)'
Subject: RE: [Bridge-mib] VlanID and VlanIDOrAny

Bert,

It seems pointless to me to define a TC where any module that uses it
MUST (or even MAY) add special semantics to one or more of the values.
Why then bother defining the TC at all? We should either define what the
special "none" value is, including its semantics, in the TC definition
or else not define any such TC. I also don't think that the name
"...OrZero" is very helpful: the name should give a hint as to the
semantics, not the syntax, even for a TC name.

N.B. if what IPCDN wants to do is identify the "priority-tagged" frames
permitted by 802.1D/802.1Q (that is frames that carry user_priority
information but no relevant VLAN information) then that should be
handled in one of 2 ways: (a) add 0 as a valid value for VlanId or
VlanIdOrAny or (b) define separate VlanIdOrPriorityOnly and/or
VlanIdOrAnyOrPriorityOnly TCs with ranges (0 | 1..4094) and/or (0 |
1..4094 | 4095) respectively [but I thought in the bridge-mib list
discussions previously, we'd decided that there was no requirement for
the priority-tagged semantics, no?].

Andrew

-----Original Message-----
From: bridge-mib-admin <at> ietf.org [mailto:bridge-mib-admin <at> ietf.org] On
Behalf Of Wijnen, Bert (Bert)
Sent: Sunday, September 07, 2003 11:14 AM
To: 'Romascanu, Dan (Dan)'; Bridge-Mib (E-mail)
Subject: RE: [Bridge-mib] VlanID and VlanIDOrAny

Not sure if they need it or not, but it would be to
indicate "wildcard", not "none"

Thanks,
Bert 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
> Sent: zondag 7 september 2003 10:55
> To: Wijnen, Bert (Bert); Bridge-Mib (E-mail)
> Subject: RE: [Bridge-mib] VlanID and VlanIDOrAny
> 
> 
> So, I guess that the IPCDN people do not need 4095. 
> 
> Otherwise, it looks OK to me. 
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> > Sent: 07 September, 2003 10:29 AM
> > To: Bridge-Mib (E-mail)
> > Subject: FW: [Bridge-mib] VlanID and VlanIDOrAny
> > 
> > 
> > It seems that in IPCDN, some people would like
> > to see yet another TC, namely:
> > 
> >     VlanIdOrZero      ::= TEXTUAL CONVENTION
> >         DISPLAY-HINT "d"
> >         STATUS        current
> >         DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
> > 
> >                       The value zero is NOT a valid VLAN ID. 
> >                       
> >                       When this textual convention is used as the
> >                       syntax of an object, the object definition
> >                       MUST specify in the DESCRIPTION clause what
> >                       the value zero means.
> >                      "
> >         SYNTAX        Integer32 (0 | 1..4094)
> > 
> > Does anyone see a problem with that?
> > 
> > Thanks,
> > Bert 
> > 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> > Sent: vrijdag 5 september 2003 0:48
> > To: Bridge-Mib (E-mail)
> > Subject: [Bridge-mib] VlanID and VlanIDOrAny
> > 
> > 
> > So... nobody has reacted to my request for
> > writeup. So I am preparing to do an ID myself.
> > 
> > This is what I think the discussion boiled down to.
> > 
> >     VlanId            ::= TEXTUAL CONVENTION
> >         DISPLAY-HINT "d"
> >         STATUS        current
> >         DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN."
> >         SYNTAX        Integer32 (1..4094)
> > 
> > 
> >     VlanIdOrAny       ::= TEXTUAL CONVENTION
> >         DISPLAY-HINT "d"
> >         STATUS        current
> >         DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
> >                       The value of 4095 is used to indicate a 
> > wildcard,
> >                       i.e. any value.
> >                      "
> >         SYNTAX        Integer32 (1..4094 | 4095)
> > 
> > Any comments?
> > 
> > Bert
> > 
> > _______________________________________________
> > Bridge-mib mailing list
> > Bridge-mib <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/bridge-mib
> > 
> > _______________________________________________
> > Bridge-mib mailing list
> > Bridge-mib <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/bridge-mib
> > 
> 

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib

Gmane