In fact I did send some review comments back in January,
see my attached email below. They also need to be
answered addressed, in addition to what I am writing here.

I also see that various comments/questions were posted to the
IPCDN WG mailing list, so those need to be answered too.

Here are my further comments

- $ idnits draft-ietf-ipcdn-pktc-mtamib-06.txt
  idnits 1.74

  draft-ietf-ipcdn-pktc-mtamib-06.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
    Checking conformance with RFC 3978/3979 boilerplate...
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgement.
    (The document uses RFC 3667 boilerplate or RFC 3978-like
    boilerplate instead of verbatim RFC 3978 boilerplate.  After 6 May 2005,
    submission of drafts without verbatim RFC 3978 boilerplate is not
    accepted.)

  So if you do a new revision, pls make sure you take care of above.
  If you use xml2rfc, then it is taken care of automagically by the
  latest version (I think)

- References:

   !! Contains embedded space:
   P050 L006:    [ETSI TS 101 909-8] ETSI TS 101 909-8: "Access and Terminals (AT);

   !! Contains embedded space:
   P050 L014:    [EN 300 001] EN 300 001 V1.5.1 (1998-10):"European Standard

   !! Contains embedded space:
   P050 L022:    [EN 300 659-1] EN 300 659-1: "Public Switched Telephone Network

   !! Contains embedded space:
   P005 L029:      - the ETSI MTA MIB [ETSI TS 101 909-8]. The ETSI MTA MIB

   !! Contains embedded space:
   P005 L031:        defined in [EN 300 001] and [EN 300 659-1].

   !! Contains embedded space:
   P005 L031:        defined in [EN 300 001] and [EN 300 659-1].

  Not sure if sapces in citations are really forbidden.
  But I know the RFC-Editor checking tool has trouble with it.

    !! Missing Reference for citation: [RFC2119]
    P003 L011:    interpreted as described in RFC 2119 [RFC2119].

    !! Missing citation for Normative reference:
    P047 L040:    [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group

    !! Missing citation for Informative reference:
    P049 L042:    [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,

    !! Missing citation for Normative reference:
    P047 L043:    [RFC3411] Harrington, D., Presuhn, R., and Wijnen, B., "An

    !! Missing Reference for citation: [RFC3495]
    P004 L025:    Configuration DHCP specifications, RFC 3495 [RFC3495] and RFC 3594

   !! Missing Reference for citation: [RFC3594]
   P004 L026:    [RFC3594].
   P048 L027:    [RFC3594] P. Duffy, "PacketCable Security Ticket Control Sub-Option

   !! Missing Reference for citation: [RFC3617]
   P048 L031:    [RFC3617] E. Lear, "Uniform Resource Identifier (URI) Scheme and

   !! Missing Reference for citation: [RFCxxxx]
   P009 L016:    module (DOCS-CABLE-DEVICE-MIB [RFCxxxx]).

  My tool may have gotten a bit confused in that it is seeing the refernce
  as a citation instead of the oterhway around. In that case there is no
  citation. Pls check carefully

- what is the persistency behaviour of the various read-write objects?
    pktcMtaDevEnabled
    ... etc ..

- For pktcMtaDevEnabled a better name woul probably be
      pktcMtaDevAdministrativelyEnabled
  And how is the NMS going to see what the real Operational status is?
  Is a AdminStatus and OperStatus (as in IF-MIB) not more appropriate?

- For
    pktcMtaDevTypeIdentifier     OBJECT-TYPE
       SYNTAX      SnmpAdminString
  I see that it is an identifier as per DHCP option 60 (RFC2132.
  There it is specified as a "string of octets". How are we sure that
  such a "string of octets" is a valid SnmpAdminString?

  There are other such objects too I think

- Where are the suboptions of DHCP option 43 defined?
  are they all valid SnmpAdminStrings as you seem to assume for
  several of them?
  A REFERENCE clause migth help too.

- You have pktcMtaDevServerAddressType and then follow some 5
  objects of InetAddress SYNTAX. The latter 5 objects MUST specify
  which object of SYNTAX InetAddressType controls their format.
  
  I also wonder if in the future all these servers need to be
  of the same InetAddressType, and so I wonder if it is wise
  to use just one object to identify the format of the 5
  different server addresses.

- Mmm do we expect we can get away with pktcMtaDevProvConfigKey
  once the Security ADs take a look?

- The comment lines on page 26 probably better go into some
  object DESCRIPTION clause, no?

- pktcMtaDevRealmOrgName
  Is this really an SnmpAdminString of max size 64?

- Page 44
           OBJECT  pktcMtaDevServerAddressType
               SYNTAX      InetAddressType
               DESCRIPTION
                   " Support for address types other than 'ipv4(1)'
                     is not presently specified and therefore, is not
                     required. It may be defined in future versions of
                     this MIB module."
  In order to say so in machine readable form, yopu do:
           OBJECT  pktcMtaDevServerAddressType
               SYNTAX      InetAddressType { ipv4(1) }
               DESCRIPTION
                   " Support for address types other than 'ipv4(1)'
                     is not presently specified and therefore, is not
                     required. It may be defined in future versions of
                     this MIB module."

  You then also add the InetAddress objects with alength of 4.
  You have done this in other MIB modules, so you should know I think.

  and is a similar refinement for pktcMtaBasicSmtaCompliance also not
  needed/wanted?

- Refrence RFC3291 can now be repalced by RFC4001

After all these things have been addressed (responded to or fixed)
I suspect we need another serious and close review.
I do not have all the details of Kerberos, DHCP and all such in
my head that I could quickly ensure they are all correct.

Did the WG have any DHCP or Kerberos (or Security people) do
an early review for this doc?

Bert

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: Monday, January 24, 2005 14:22
> To: Jean-Francois Mule; enechamkin@broadcom.com
> Cc: Richard Woundy @ Comcast; Randy Presuhn (E-mail)
> Subject: RE: IPCDN MTA draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt
> 
> 
> I did a very very quick browse through the MIB module, and I think
> there are a number of things that still need to be fixed.
> I will try to type them up later today.
> 
> Things I can report right away:
> 
> - object pktcMtaDevProvUnsolicitedKeyMaxTimeout
>   is a read-only object and has text in the DESCRIPTION clause about 
>              If this object is set to a zero value, the MTA MUST return
>              an 'inconsistentValue' in response to SNMP SET operations.
>   That seems conflicting, no?
> 
> - Same for pktcMtaDevProvUnsolicitedKeyNomTimeout
> 
> - I wonder if for an object like pktcMtaDevProvKerbRealmName 
>   it is wise to use SnmpAdminString while the content MUST be
>   uppercase ASCII ??
> 
> - Same for pktcMtaDevRealmName
> 
> - Why is 
>    pktcMtaDevRealmAvailSlot   OBJECT-TYPE
>        SYNTAX      Unsigned32 (0..64)
> 
>   While 
>    pktcMtaDevRealmIndex  OBJECT-TYPE
>        SYNTAX      Unsigned32 (1..32)
> 
>   Should they not be both limited to 64 or 32 (i.e. same value) ??
> 
> - Same for
>    pktcMtaDevCmsAvailSlot   OBJECT-TYPE
>        SYNTAX      Unsigned32 (0..128)
>   and
>    pktcMtaDevCmsIndex  OBJECT-TYPE
>        SYNTAX      Unsigned32 (1..64)
> 
> - I wonder why:
> 
>    pktcMtaNotificationPrefix OBJECT IDENTIFIER ::= { pktcMtaMib 2 }
>    pktcMtaNotification OBJECT IDENTIFIER ::= {
>    pktcMtaNotificationPrefix 0 }
> 
>   is not specified as:
> 
>    pktcMtaNotifications OBJECT IDENTIFIER ::= { pktcMtaMib 0 }
> 
>   as suggested in the mib-review-guideleines.
>   It is not forbidden. I just wonder
> 
> - I wonder why
>    pktcMtaBasicCompliance MODULE-COMPLIANCE
> 
>        STATUS      current
>        DESCRIPTION
>            " The compliance statement for MTA devices that implement
>              PacketCable or IPCablecom requirements.
> 
>              This compliance statement applies to MTA implementations
>              that support PacketCable 1.0 or IPCablecom requirements,
>              which are not IPv6-capable at the time of this
>              RFC publication."
> 
>        MODULE  -- Unconditionally mandatory groups for MTAs
> 
>            MANDATORY-GROUPS {
>                pktcMtaGroup,
>                pktcMtaNotificationGroup
>            }
> 
>            OBJECT  pktcMtaDevServerAddressType
>                SYNTAX      InetAddressType
>                DESCRIPTION
>                    " Support for address types other than 'ipv4(1)'
>                      is not presently specified and therefore, is not
>                      required. It may be defined in future versions of
>                      this MIB module."
>        ::= { pktcMtaCompliances 1 }
> 
>   Does not have the following:
> 
>            MANDATORY-GROUPS {
>                pktcMtaGroup,
>                pktcMtaNotificationGroup
>            }
> 
>            OBJECT  pktcMtaDevServerAddressType
>                SYNTAX      InetAddressType { ipv4(1) }
>                DESCRIPTION
>                    " Support for address types other than 'ipv4(1)'
>                      is not presently specified and therefore, is not
>                      required. It may be defined in future versions of
>                      this MIB module."
>            OBJECT pktcMtaDevServerDhcp1
>                SYNTAX     InetAddress SIZE (4)
>                SESCRIPTION
>                    " Support for address formats other than 'ipv4(1)'
>                      is not presently specified and therefore, is not
>                      required. It may be defined in future versions of
>                      this MIB module."
> 
>            .... and similar swtuff for the other InetAddress objects
> 
>        ::= { pktcMtaCompliances 1 }
> 
> - Same for the pktcMtaBasicSmtaCompliance spec.
> 
> - At cvarious places in your MIB module you have FQDNs present.
>   I wonder if it would not be wise (for interoperability) to 
>   specify WHEN such FQDNs are supposed to be resolved to IP addresses.
> 
> As I said, the above is my first set of questions after a very very 
> quick scan. Not a complete and detailed review.
> 
> Bert
> 
> > -----Original Message-----
> > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]
> > Sent: Saturday, January 22, 2005 01:55
> > To: Bert Wijnen
> > Cc: enechamkin@broadcom.com; Richard Woundy @ Comcast
> > Subject: IPCDN MTA draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt
> > 
> > 
> > Bert,
> >   Eugene and I worked on the MTA MIB draft update. It was 
> > submitted tonight per our earlier email exchange to allow it 
> > to be potentially on the next IESG telechat. 
> > 
> >   Please let us know if you have any comments and what the 
> > next steps are. 
> > Thanks,
> > Jean-François 
> > PS: Idnits 1.58 is clean on the ID, so is SMICng on the mib 
> > module (just 2 warnings due to imported grouped non used 
> > apart from the module compliance)
> > 
> > -----Original Message-----
> > From: Jean-Francois Mule 
> > Sent: Friday, January 21, 2005 5:50 PM
> > To: 'internet-drafts@ietf.org'
> > Cc: Richard Woundy @ Comcast; Jean-Francois Mule; Eugene 
> > Nechamkin (enechamkin@broadcom.com)
> > Subject: IETF I-D submission: IPCDN MTA draft06 
> > draft-ietf-ipcdn-pktc-mtamib-06.txt
> > 
> > 
> > Please find attached an update to an existing IPCDN wg I-D.
> > 
> > Title: Multimedia Terminal Adapter (MTA) Management Information Base
> >                for PacketCable and IPCablecom compliant device
> >  
> > Author(s)	: Eugene Nechamkin, Jean-Francois Mule
> >  
> > Filename	: draft-ietf-ipcdn-pktc-mtamib-06.txt
> >  
> > Working Group: IPCDN
> > 
> > 
> > Thanks,
> > Jean-Francois Mule.
> > jfm@cablelabs.com
> > IPCDN co-chair.
> >  
> > 
> 

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn