[ipcdn] Changes in draft-ietf-ipcdn-pktc-mtamib-07.txt

All,

   This note summarizes the comments received on MTA MIB draft06 (from
Bert's AD review and wg participants) and the changes made in draft07.

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-07.txt

Thanks,
Eugene and Jean-Francois.

---
--- Summary of responses to MTA MIB draft 06 comments
---            draft-ietf-ipcdn-pktc-mtamib-06.txt
---  from AD and wg participants

Bert wrote:
# Comment 1
> - $ 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)
ok, fixed.
Will run the latest idnits tool before submission, just like we did
for draft06 (the boilerplate was updated since draft06 submission).

# Comment 2
> - 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.
ok - fixed, removed white spaces.

# Comment 3
>     !! Missing Reference for citation: [RFC2119]
>     P003 L011:    interpreted as described in RFC 2119 [RFC2119].
ok fixed, added reference.

# Comment 4
>     !! Missing citation for Normative reference:
>     P047 L040:    [RFC2863] McCloghrie, K., Kastenholz, F., "The
> Interfaces Group
ok, the reference is mostly because of the IMPORT of the IF-MIB.
Proposed resolution: reference to [RFC2863] is introduced as comments
in the MIB module:
 added "-- [RFC2863]" to mib module

# Comment 5
>     !! Missing citation for Informative reference:
>     P049 L042:    [RFC3410] Case, J., Mundy, R., Partain, D. and B.
> Stewart,
No action taken.
   [RFC3410] - the citation is not missing, it is present in the text.
               See: section 1, end of 1st sentence.

# Comment 6
>     !! Missing citation for Normative reference:
>     P047 L043:    [RFC3411] Harrington, D., Presuhn, R., and Wijnen,
> B., "An
ok. This normative reference is required because of the IMPORTs.
Resolution: added RFC citations as comments in the MIB module
definition as follows:
IMPORTS
    MODULE-IDENTITY,
    OBJECT-TYPE,
    OBJECT-IDENTITY,
    Unsigned32,
    Counter32,
    NOTIFICATION-TYPE,
    mib-2
          FROM SNMPv2-SMI                    -- [RFC2578]
    RowStatus,
    TruthValue
          FROM SNMPv2-TC                     -- [RFC2579]
    OBJECT-GROUP,
    MODULE-COMPLIANCE,
    NOTIFICATION-GROUP
          FROM SNMPv2-CONF                   -- [RFC2580]
    InetAddressType,
    InetAddress
          FROM INET-ADDRESS-MIB              -- [RFC4001]
    sysDescr
          FROM SNMPv2-MIB                    -- [RFC3418]
    SnmpAdminString
          FROM SNMP-FRAMEWORK-MIB            -- [RFC3411]
    docsDevSoftwareGroupV2
          FROM DOCS-CABLE-DEVICE-MIB         -- [RFCxxxx]
    -- ************************************************************
    -- * NOTES TO RFC Editor (to be removed prior to publication) *
    -- *                                                          *
    -- *     The I-D <draft-ietf-ipcdn-device-mibv2-10.txt>       *
    -- * is expected to become RFC before this draft.             *
    -- * Please replace RFCxxxx with the RFC number of the IPCDN  *
    -- * Cable Device MIBv2 and remove this note                  *
    -- *                                                          *
    -- ************************************************************

    DocsX509ASN1DEREncodedCertificate,
    docsBpi2CodeDownloadGroup
          FROM DOCS-IETF-BPI2-MIB            -- [RFC4131]

    ifPhysAddress
          FROM IF-MIB;                       -- [RFC2863]

# Comment 7
>     !! Missing Reference for citation: [RFC3495]
>     P004 L025:    Configuration DHCP specifications, RFC 3495
> [RFC3495] and RFC 3594
No action taken.
   RFC3495 - Reference is not missing it's present in the Normative
References.

# Comment 8
>    !! Missing Reference for citation: [RFC3594]
>    P004 L026:    [RFC3594].
>    P048 L027:    [RFC3594] P. Duffy, "PacketCable Security Ticket
> Control Sub-Option
No action taken.
  RFC3594 - Reference is not missing it's present in the Normative
References.

# Comment 9
>    !! Missing Reference for citation: [RFC3617]
>    P048 L031:    [RFC3617] E. Lear, "Uniform Resource Identifier (URI)
> Scheme and
No action taken.
   RFC3617 - Reference is not missing it's present in the Normative
References.

# Comment 10
>    !! Missing Reference for citation: [RFCxxxx]
>    P009 L016:    module (DOCS-CABLE-DEVICE-MIB [RFCxxxx]).
No action taken.
   RFCxxxx - Reference is not missing it's present in the Normative
References.

# Comment 11
>   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
ok, did another check before submitting the ID.
We also updated some of the PacketCable and other IETF references:
   - Updated reference to PacketCable MTA MIB Specification
   - Updated reference to PacketCable Provisioning Specification
   - Updated reference to PacketCable Security Specification

# Comment 12
> - what is the persistency behaviour of the various read-write objects?
>     pktcMtaDevEnabled
>     ... etc ..
Resolution: updated a number of MIB objects, see below.
Out of all the read-write objects, none of the values set in those
objects should persist, except for pktcMtaDevResetKrbTickets.

a) We added the following text for non-persistent object
values:
 => for e.g., for pktcMtaDevResetNow, add:
          If a value is written into an instance of
          pktcMtaDevResetNow, the agent MUST NOT retain the supplied
          value across MTA re-initializations or reboots."
Similar text for pktcMtaDevEnabled, pktcMtaDevProvisioningTimer,
pktcMtaDevServerDns1, pktcMtaDevServerDns2, pktcMtaDevTimeServer,
pktcMtaDevConfigFile, pktcMtaDevProvConfigHash,
pktcMtaDevProvConfigKey.
b) Added text indicating persistence of object value only for
pktcMtaDevResetKrbTickets:
          If a value is written into an instance of
          pktcMtaDevResetKrbTickets, the agent MUST retain the
          supplied value across an MTA re-initialization or
          reboot.

# Comment 13
> - 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?
Resolution: see additional email thread on the ipcdn list in Sept
 2005. The following text was added:
           The MTA must execute all actions required to
           enable or disable the telephony services for all
           endpoints immediately upon receipt of an SNMP SET
           operation.

# Comment 14
> - 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?
Resolution: added clarification text, see below.
We traced this assurance to a requirement in the PacketCable MTA
Device Provisioning spec (see normative ref in the draft):
Section 8.2 says:
 8.2 DHCP Option 60: Vendor Client Identifier
"Option code 60 contains a string identifying Capabilities of the MTA.
The MTA- MUST send the following ASCII Coded String in DHCP Option
----->                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
code 60: "pktc1.0:xxxxxx". Where xxxxxx MUST be an ASCII
representation of the hexadecimal encoding of the MTA TLV Encoded
Capabilities, as defined in Section 10."
The following text was added per the subsequent email request from
Bert:

          ...              The
          DHCP option 60 value contains an ASCII encoded string
          identifying Capabilities of the MTA as defined in the
          PacketCable MTA Device Provisioning Specification.

# Comment 15
>   There are other such objects too I think
> pktcMtaDevSerialNumber
> pktcMtaDevSwCurrentVers
> etc.
Resolution: below is the list of objects with some analysis to justify
the object syntax.

pktcMtaDevSerialNumber
  object value == DHCP option 43 sub-option 4 value.
  see the PKT-SP-PROV spec, section 8.5, it says:
  "The sub-option 4 contains the device serial number represented as
   an ASCII string."
Resolution: No action required, leave as-is.

pktcMtaDevSwCurrentVers
  object value == DHCP option 43 sub-option 6 value.
  see the PKT-SP-PROV spec, section 8.5, it says:
  "The sub-option 6 contains the software version
   number represented as an ASCII string."
Resolution: No action required, leave as-is.

pktcMtaDevSnmpEntity
  object value == DHCP option 122 sub-option 3 value [RFC 3495]
                  in the form of an FQDN
  SnmpAdminString is therefore ok.
Resolution: No action required, leave as-is.

pktcMtaDevProvKerbRealmName
  object value == DHCP option 122 sub-option 6 value [RFC 3495]
                  ==> GeneralStrings encoded per RFC1510
  The Packetcable Security Specification adds a requirement for those
  names to be all UPPERCASE (note that this is consistent with RFC4120
  section 6.1, quote:
   "When establishing a new realm name based on an internet domain
   name it is recommended by convention that the characters be converted
   to uppercase.")

In addition, as noted below, the Kerberos protocol (RFC1510, RFC4120)
defines the RealmName to be of ASN.1 type "GeneralString". This type
has numerous interop problems (RFC4120, section 5.2.1).
The newer version of Kerberos protocol (RFC4120) requires that the
RealmName follows a new type "KerberosString" which effectively
constrains the value of the GeneralString to only contain characters
in IA5String.
     KerberosString  ::= GeneralString (IA5String)
The "IA5String" type is defined in ISO/IEC646:1991 and also known
as US-ASCII.
Hence, based on the above analysis, "DisplayString" and
"SnmpAdminString" seem to be the closest mapping in SMI. The
co-authors are shared on whether to change the current SYNTAX from
SnmpAdminstring to DisplayString.
Note that there are a couple of other objects related to DHCP but they
are not strings.
Resolution: based on the above and the subsequent discussions, the
co-authors prefer to leave the object as-is.

# Comment 16
> - Where are the suboptions of DHCP option 43 defined?
in PKT-SP-PROV a normative reference in the MTA MIB ID
http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I11-050812.pdf
section 8.5
Resolution: added the following text:
          The list of sub-options for
          DHCP option 43 are defined in the PacketCable MTA Device
          Provisioning Specification.

# Comment 17
>   are they all valid SnmpAdminStrings as you seem to assume for
>   several of them?
Resolution: no action
based on the above analysis, I think our use is legitime, if not,
please let us know.

# Comment 18
>   A REFERENCE clause migth help too.
Yes, agree.
Resolution: added text and reference in the 2 objects referencing DHCP
option 43:
          The list of sub-options for DHCP option
          43 are defined in the PacketCable MTA Device
          Provisioning Specification.
    REFERENCE
        " PacketCable MTA Device Provisioning Specification."

# Comment 19
> - 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.
Resolution: no action
This is already the case in draft06. We don't understand the comment.
For eg, pktcMtaDevServerDhcp1 states:
          The type of this address is determined by the value of
          the pktcMtaDevServerAddressType object.
same for pktcMtaDevServerDhcp2, pktcMtaDevServerDns1,
pktcMtaDevServerDns2, and pktcMtaDevTimeServer.

# Comment 20
>   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.
Good point.
Resolution:
   Define 3 Internet Address types:
        one for 2 DHCP server objects
        one for 2 DNS server objects
        1 for Time Server object.
The InetAddressType objects inthe pktcMtaDevServer table now look
like:
pktcMtaDevDhcpServerAddressType  OBJECT-TYPE
    SYNTAX      InetAddressType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        " This object contains the Internet address type for the
          PacketCable DHCP servers specified in MTA MIB."
    DEFVAL { ipv4 }
    ::= { pktcMtaDevServer 1}

pktcMtaDevDnsServerAddressType  OBJECT-TYPE
    SYNTAX      InetAddressType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        " This object contains the Internet address type for the
          PacketCable DNS servers specified in MTA MIB."
    DEFVAL { ipv4 }
    ::= { pktcMtaDevServer 17}

pktcMtaDevTimeServerAddressType  OBJECT-TYPE
    SYNTAX      InetAddressType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        " This object contains the Internet address type for the
          PacketCable Time servers specified in MTA MIB."
    DEFVAL { ipv4 }
    ::= { pktcMtaDevServer 18}

The description text in the affected objects was updated accordingly.

# Comment 21
> - Mmm do we expect we can get away with pktcMtaDevProvConfigKey
>   once the Security ADs take a look?
Resolution:
  - change the syntax of pktcMtaDevProvConfigKey to be 32 octets (256)
    or may be more
        - add a new TC PktcMtaDevProvEncryptAlg and put the list:
                           none(0),
                           des64CbcMode(1),
                           t3Des128CbcMode(2),
                           aes128CbcMode(3),
                           aes256CbcMode(4)
      - add a new object named pktcMtaDevProvConfigEncryptAlg to specify
       the encryption algorithm of type PktcMtaDevProvEncryptAlg
      - add DEFVAL des64CbcMode
     - add a compliance statement to only require des64CbcMode for
       compliant PacketCable 1.0 implementations.
The above proposal is inline with the Security AD comments on the BPI+
encryption algorithms and ok with us.

# Comment 22
> - The comment lines on page 26 probably better go into some
>   object DESCRIPTION clause, no?
Resolution: moved the comment into the description clauses and pasted
the same text in all of the 3 relevant objects
(pktcMtaDevProvUnsolicitedKeyMaxTimeout,
pktcMtaDevProvUnsolicitedKeyNomTimeout,
pktcMtaDevProvUnsolicitedKeyMaxRetries).

# Comment 23
> - pktcMtaDevRealmOrgName
>   Is this really an SnmpAdminString of max size 64?
We confirmed the 2 points:
per RFC2459:
   - Organization Name MUST be of "UTF8String" (for all certs after
     Dec 31, 2003).
   - upper boundery is 64 for Organization name. Given that a signle
     char can take up to 6 octets in SnmpAdminString, we proposed to
     increase the max limit to 255.
CONCLUSION: "SnmpAdminString" type is the closest mapping to
"UTF8String"
                Hence, leave the SYNTAX "as is" - SnmpAdminString.
Resolution:
        Increased upper bound limit.

# Comment 24
> - 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."
ok, will be reflected in all applicable objects.

# Comment 25
>   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.
Resolution:
   Changes reflected in all applicable objects.
        OBJECT    pktcMtaDevServerDhcp1
            SYNTAX  InetAddress (SIZE(4))
            DESCRIPTION
                 "An implementation is only required to support IPv4
            Addresses. Other address types support may be defined in
            future versions of this MIB module."
        OBJECT    pktcMtaDevServerDhcp2
            SYNTAX  InetAddress (SIZE(4))
            DESCRIPTION
                 "An implementation is only required to support IPv4
            Addresses. Other address types support may be defined in
            future versions of this MIB module."
        OBJECT    pktcMtaDevServerDns1
            SYNTAX  InetAddress (SIZE(4))
            DESCRIPTION
                 "An implementation is only required to support IPv4
            Addresses. Other address types support may be defined in
            future versions of this MIB module."
        OBJECT    pktcMtaDevServerDns2
            SYNTAX  InetAddress (SIZE(4))
            DESCRIPTION
                 "An implementation is only required to support IPv4
            Addresses. Other address types support may be defined in
            future versions of this MIB module."
        OBJECT    pktcMtaDevTimeServer
            SYNTAX  InetAddress (SIZE(4))
            DESCRIPTION
                 "An implementation is only required to support IPv4
            Addresses. Other address types support may be defined in
            future versions of this MIB module."

# Comment 26
>   and is a similar refinement for pktcMtaBasicSmtaCompliance also not
>   needed/wanted?
Resolution: agree. Added to the S-MTA compliance group.

# Comment 27
> - Refrence RFC3291 can now be repalced by RFC4001
ok, fixed.

# Comment 28
> I suspect we need another serious and close review.
We as co-authors would really like to understand the next steps in
more details. This draft has passed WGLC, has had at least 2 if not 3
MIB doctor reviews and now your complete review.

> Bert
Thanks again for all the comments

The following are comments received on the draft from Randy Presuhn
and other IPCDN WG participants.

# Comment 29
> - 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?
Resolution:
deleted:     If this object is set to a zero value, the MTA MUST return
             an 'inconsistentValue' in response to SNMP SET operations.

# Comment 30
> - Same for pktcMtaDevProvUnsolicitedKeyNomTimeout
Resolution:
deleted:     If this object is set to a zero value, the MTA MUST return
             an 'inconsistentValue' in response to SNMP SET operations.

# Comment 31
> - I wonder if for an object like pktcMtaDevProvKerbRealmName 
>   it is wise to use SnmpAdminString while the content MUST be
>   uppercase ASCII ??
Resolution: based on the above and the subsequent discussions, the
co-authors prefer to leave the object as-is.
See comment #15.
The Kerberos protocol (RFC1510, RFC4120) defines the RealmName to be
of ASN.1 type "GeneralString". This type has numerous interop problems
(RFC4120, section 5.2.1).
The newer version of Kerberos protocol (RFC4120) requires that the
RealmName follows a new type "KerberosString" which effectively
constrains the value of the GeneralString to only contain characters
in IA5String.
     KerberosString  ::= GeneralString (IA5String)
The "IA5String" type is defined in ISO/IEC646:1991 and also known
as US-ASCII.
Hence, based on the above analysis, "DisplayString" and
"SnmpAdminString" seem to be the closest mapping in SMI.

# Comment 32
> - Same for pktcMtaDevRealmName
Resolution: based on the above and the subsequent discussions, the
co-authors prefer to leave the object as-is.

# Comment 33
> - 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) ??
Agree.
Resolution:
  change pktcMtaDevRealmIndex's SYNTAX to
       SYNTAX      Unsigned32 (1..64)

# Comment 34
> - Same for
>    pktcMtaDevCmsAvailSlot   OBJECT-TYPE
>        SYNTAX      Unsigned32 (0..128)
>   and
>    pktcMtaDevCmsIndex  OBJECT-TYPE
>        SYNTAX      Unsigned32 (1..64)
Resolution:
  change pktcMtaDevCmsIndex's SYNTAX to
       SYNTAX       Unsigned32 (1..128)

# Comment 35
> - 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
Resolution:
  change text to follow mib design guidelines as follows:
   pktcMtaNotifications OBJECT IDENTIFIER ::= { pktcMtaMib 0 }
The text looks like this now:

pktcMtaNotification OBJECT IDENTIFIER ::= { pktcIetfMtaMib 0 }
pktcMtaMibObjects  OBJECT IDENTIFIER ::= { pktcIetfMtaMib 1 }
pktcMtaDevBase     OBJECT IDENTIFIER ::= { pktcMtaMibObjects 1 }
pktcMtaDevServer   OBJECT IDENTIFIER ::= { pktcMtaMibObjects 2 }
pktcMtaDevSecurity OBJECT IDENTIFIER ::= { pktcMtaMibObjects 3 }
pktcMtaDevErrors   OBJECT IDENTIFIER ::= { pktcMtaMibObjects 4 }
pktcMtaConformance  OBJECT IDENTIFIER ::= { pktcIetfMtaMib 2 }

# Comment 36
> - 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 }
ok, addressed.

# Comment 37
> - Same for the pktcMtaBasicSmtaCompliance spec.
Agree, fixed.

# Comment 38
> - At various 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.
Agree.
Resolution: added new text as follows:
  for pktcMtaDevFQDN:
          The MTA FQDN is used to uniquely identify the
          device to the PacketCable back office elements.
  (on this one, the MTA does not resolve it, just uses it).

pktcMtaDevSnmpEntity
         The MTA must resolve the FQDN value before its very first
         network interaction with the SNMP entity during the
         provisioning phase as specified in the PacketCable MTA Device
         Provisioning specification.

pktcMtaDevCmsFqdn
           The MTA must resolve the CMS FQDN as required
           by the corresponding PacketCable Specifications."
    REFERENCE
        " PacketCable MTA Device Provisioning Specification;
          PacketCable Security Specification;
          PacketCable Network-Based Call Signaling Protocol
          Specification."

# Comment 39
--- Other comments on MTA MIB draft06
Bert wrote:
> I also see that various comments/questions were posted to the
> IPCDN WG mailing list, so those need to be answered too.
ok, see Comments 40 and above for the log of other issues. We believe
draft07 does address all comments received to date. If we missed any,
let us know.

# Comment 40
>From Randy
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01600.html
Duplicate of Comment 31.

# Comment 41
>From Randy, thread with subject title "[ipcdn] pktcMtaDevProvConfigKey"
Initial pointer:
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01537.html

Resolution: add the following text in the description:
          The value of this object is provided along with the
          configuration file information (pktcMtaDevConfigFile)
          and hash (pktcMtaDevProvConfigHash) by the Provisioning
          Server via SNMP SET once the configuration file has been
          created as defined by the PacketCable Security
          specification.

          If the configuration file the MTA receives is not
          encrypted, the length of this object value is zero.
          If the file is encrypted, then the algorithm is DES in
          CBC mode and the length of this object value is 64 bits
          (an IV of zero is used to encrypt the file as specified
          in the PacketCable Security specification).

and change the MUST into SHOULD as proposed below:
          This object must not be used in non secure provisioning
          mode.  In non secure provisioning modes, the MTA SHOULD
          return an 'inconsistentValue' in response to SNMP SET
          operations, and, the MTA SHOULD return a zero-length
          string in response to SNMP GET operations.
 (this to address potential issues with some agent implementations
like AgentX).

# Comment 42
Comment from Thomas Anders:
delete
>             This object value is used as an index into the
>             pktcMtaDevRealmTable.
in the description clause of pktcMtaDevProvKerbRealmName.

> end.

> -----Original Message-----

> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]

> Sent: Thursday, October 27, 2005 8:50 AM

> To: i-d-announce@ietf.org

> Cc: ipcdn@ietf.org

> Subject: I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-07.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       : Multimedia Terminal Adapter (MTA) Management

>                           Information Base for PacketCable and

>                           IPCablecom compliant devices

>     Author(s)   : E. Nechamkin, J. Mule

>     Filename    : draft-ietf-ipcdn-pktc-mtamib-07.txt

>     Pages       : 60

>     Date        : 2005-10-27

> 

> 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 PacketCable and IPCablecom compliant

>    Multimedia Terminal Adapter devices.

> 

> A URL for this Internet-Draft is:

> http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-

> 07.txt

> 

> To remove yourself from the I-D Announcement list, send a message to

> i-d-announce-request@ietf.org with the word unsubscribe in the body of

> the message.

> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

> to change your subscription settings.

> 

> 

> 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-pktc-mtamib-07.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@ietf.org.

> In the body type:

>     "FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-07.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.