Subject: [ipcdn] RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 12 Sep 2005 17:39:04 +0200

Sorry that it took a while. But I just cannot always jump up at the exact moment
that a MIB document from you arrives. 
 
First a geneal remark about my comments about missing referecnces and/or citations.
As I said in my evaluation, the tool I use has bugs and is primitive. One can use it
as a bit of a helper to try and get the references/citation as good as possible.
So I am going to assume you have now done so.
 
Inline (blue text is mine. You had "commnt n" already in blue too)

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Monday, September 05, 2005 15:52
To: Wijnen, Bert (Bert); Ipcdn (E-mail)
Cc: [email-masked]; Richard Woundy @ Comcast; Jean-Francois Mule
Subject: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

Bert, and all,
 
   Thanks again for the AD review of the IPCDN MTA MIB module. Eugene
and I got together to review and address them. Find below our
responses along with our proposed resolutions.
 
  We would appreciate receiving quick input from you and the wg on the
proposed changes for draft 07, and in particular, for Comments #:
  12, 13, 14, 15, 19, 20, 21, 22, 23, 28, 29, 30, 31, 32, and 38.
 
   Let us know what you think, pending your ack and wg consensus, we
will update the Internet-Draft by mid September.
 
Thanks,
Eugene and Jean-Francois.
 
---
--- Summary of responses to AD comments on
---            draft-ietf-ipcdn-pktc-mtamib-06.txt
---
 
Bert wrote:
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01693.html <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01693.html> 
 
# 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: <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. We propose
to add the following text in section 3:
   EMTA devices implementing this MIB Module MUST be compliant with
   RFC 2863 [RFC2863] and the Packetcable MTA Device Provisioning
   Specification [PKT-SP-PROV].
(we're also proposing to also add the existing normative reference to
the MTA device provisioning spec here).

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

# 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.
Proposed resolution: add 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]

bw: That would be fine

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

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

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

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

# 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
yep, will do another check once we run idnits.
We also plan to update some of the PacketCable references:
   - Updated reference to PacketCable MTA MIB Specification
   - Updated reference to PacketCable Provisioning Specification
   - Updated reference to PacketCable Security Specification
  
bw: fine 
 
# Comment 12
> - what is the persistency behaviour of the various read-write objects?
>     pktcMtaDevEnabled
>     ... etc ..
ok.
Proposed resolution and text:
Out of all the read-write objects, none of the values set in those
objects should persist, except for pktcMtaDevResetKrbTickets.
 
a) We propose to add the following text for non-persistant values:
 => for e.g., for pktcMtaDevResetNow, add:
          If a value is written into an instance of
          pktcMtaDevResetNow, the agent must not retain the supplied 
 
bw: did you mean MUST NOT instead of must now lower case?
 
          value across MTA re-initializations or reboots."
Similar text for pktcMtaDevEnabled, pktcMtaDevProvisioningTimer,
pktcMtaDevServerDns1, pktcMtaDevServerDns2, pktcMtaDevTimeServer,
pktcMtaDevConfigFile, pktcMtaDevProvConfigHash,
pktcMtaDevProvConfigKey.
b) Add 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.
  
bw: seems fine to me. As said many times before: it is important to document what
the expected behaviour is.
 
# 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?
Proposed resolution: no action
In general, we agree with the comment and our first reaction was, yes,
let's rename it and add an operStatus one.
But after looking at its definition in more details, syntax
(ThruthValue) and after considering a new operStatus object, we think
that:
        - pktcMtaDevEnabled is both an admin and operational status
          object, hence the name is probably ok,
        - it returns the operational status of the enable/disable
          switch when read.
Our proposal, after reviewing your comment is still to leave it as-is.
Is this ok? if not, can you elaborate?
  
bw: The issue is that if you use one single object for both the admin's desire of the status and
at the same time for the actual operational status, then it gets difficult.
 
If you issue an SNMP SET to enable, then if you accept it, then that means that the value
is to be changed to enabled. If however the value then later changes, then I bet that the
management station is at least very surprised. It is not for nothing that the IF-MIB (after a long
experience) has chosed to haev a Admin and Operational status in two separate objects.
 
If you use one object, and I do a SET for ENABLE, then you are telling
me that a GET-RESPONSE to the SET that say it is OK is useless, and
that I need to do another GET for the object in order to check if my
SET actually succeeded or not? 
  
# 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?
Proposed resolution: no action
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.5:xxxxxx". Where xxxxxx MUST be an ASCII
representation of the hexadecimal encoding of the MTA TLV Encoded
Capabilities, as defined in Section 10."
 No action required, leave as-is.

bw: See, it seems you do have a valid explanation. If so, then fine. It would be best if some of
that explanation is added to the description clause or easily available via the REFERENCE
clause. Given the discussion on this topic sofar, it seems best to add some text to the 
description clause.
 
Not also that the SnmpAdminString has some special semantics. 
I bleiev that these 2 are more generic:

The following TCs are defined in SYSAPPL-MIB [RFC2287]: 

   Utf8String                  OCTET STRING (SIZE (0..255))

   LongUtf8String              OCTET STRING (SIZE (0..1024))

This is listed on page:http: //www.ops.ietf.org/mib-common-tcs.html
 
# Comment 15
>   There are other such objects too I think
> pktcMtaDevSerialNumber
> pktcMtaDevSwCurrentVers
> etc.
Right. 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."
Proposal: 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."
Proposal: 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.
Proposal: 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. Any input on this?
There are a couple of other objects related to DHCP but they are not
strings.

bw: See above my comment on SnmpAdminString, Utf8String and clear text in description
clauses 
 
# 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 <http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I11-050812.pdf> 
section 8.5
  
bw: I hope that this is now clear from the MIB writeup 
 
# Comment 17
>   are they all valid SnmpAdminStrings as you seem to assume for
>   several of them?
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.
Proposed text:
    REFERENCE
        " PacketCable MTA Device Provisioning Specification."
 in the 2 objects referencing DHCP option 43.

bw: as I have seen on the list, I am not sire that such makes it completely
clear. But I leave it to the WG to decide.
 
# 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.
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.
 
bw: I stand corrected. I guess I overlooked it.
 
# 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.
Proposed resolution:
   Define 3 Internet Address types:
        one for 2 DHCP server objects
        one for 2 DNS server objects
        1 for Time Server object.

bw : good. Pls adapt the InetAddress objects accordingly to refer to the proper
AddressType object.
 
# Comment 21
> - Mmm do we expect we can get away with pktcMtaDevProvConfigKey
>   once the Security ADs take a look?
Proposed Resolution:
  - change the syntax of pktcMtaDevProvConfigKey to be 32 octets (256)
    or may be more
  - add a new object named pktcMtaDevProvConfigEncryptAlg to specify
    the encryption algorithm
                           none(0),
                           des64CbcMode(1),
                           t3Des128CbcMode(2),
                           aes128CbcMode(3),
                           aes256CbcMode(4)
  - 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.
  
bw: if that is same as for BPI+, then I guess it will be acceptable.

# Comment 22
> - The comment lines on page 26 probably better go into some
>   object DESCRIPTION clause, no?
OK they have been in the draft for a long time.
But where do we put it? should we just paste it in one or all of the 3
relevant objects (pktcMtaDevProvUnsolicitedKeyMaxTimeout,
pktcMtaDevProvUnsolicitedKeyNomTimeout,
pktcMtaDevProvUnsolicitedKeyMaxRetries)
We can also put it in section 3.3 and/or in the mib objects. if so, in
which one do we duplicate the same text in all the 3 objects?
Please let us know your preference.
 
bw: In general we must realize that when a MIB module gets extracted from a document,
then the comments often go away. So the more text you can put in appropriate DESCRIPTION
clauses, the better. If that sometimes means a repeat of text, so be it.
 
It is not a hard rule. I always make sure people realize that the comment lines
may disappear after MIB module is extracted into tools or GUI interfaces.

# 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.
CONCLUSION: "SnmpAdminString" type is the closest mapping to "UTF8String"
                Hence, leave the SYNTAX "as is" - SnmpAdminString.
Proposed resolution no action required, leave as-is.

bw: See my comments above about SnmpAdminString and UTF8String
 
W.r.t. the upper limit 64, is it octets or is it characters. You are aware that a single
character can need up to 6 octets to be represented in a UTF8string or SnmpAdminString
right? In any event, it is important to be very clear what the size restriction is.

# 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.
ok, will be reflected in all applicable objects. will check thorougly.

# Comment 26
>   and is a similar refinement for pktcMtaBasicSmtaCompliance also not
>   needed/wanted?
ok, agree. Will be addressed.

# 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.

bw: Well, such may all be true, but you also do agree that we still found serious issues, no?
 
> 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.
  based on the above, we think we have addressed the concerns, if not,
let us know.

bw: probably so.
 
> Did the WG have any DHCP or Kerberos (or Security people) do
> an early review for this doc?
I think we have justified the DHCP questions. I (Jean-Francois) can
certainly asked Ralph Droms for cross-review. As for the security, per
the fixes of BPI+, let us know if this is not good enough.
 
If you are confident, we can go ahead. I do know that we have security ADs and other
ADs who will look after the DHCP issues at IESG review time. My point was that it is
probably better to ensure early that things are OK.  You seem to trust such is the case,
then fine by me.
  
> Bert
Thanks again for all the comments
  
Welcome... I am going on with inline comments/answers
 
# 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?
Proposed resolution:
delete       If this object is set to a zero value, the MTA MUST return
             an 'inconsistentValue' in response to SNMP SET operations.
 
bw: sounds fine, assuming the object was indeed intended to be read-only
  
# Comment 30
> - Same for pktcMtaDevProvUnsolicitedKeyNomTimeout
Proposed resolution:
delete       If this object is set to a zero value, the MTA MUST return
             an 'inconsistentValue' in response to SNMP SET operations.
 
bw: same
  
# Comment 31
> - I wonder if for an object like pktcMtaDevProvKerbRealmName 
>   it is wise to use SnmpAdminString while the content MUST be
>   uppercase ASCII ??
Proposed resolution:
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. Any input on this?
 
bw: DisplayString better not be used anymore. Certainly not if the underlying technology
is prepared to do UTF8 in the future. Then we better be prepared too.
And (as I think you know), US ASCII is represented the same in a DisplayString as
it is in an SNmpAdminString or Utf8String.
 
See my comments earlier on aswell

# Comment 32
> - Same for pktcMtaDevRealmName
Proposed resolution:
       see above, 2 options:
        change to DisplayString or leave as-is,
        keep SnmpAdminstring

# 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.
Proposed 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)
Proposed 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
Proposed resolution:
  change text to follow mib design guidelines as follows:
   pktcMtaNotifications OBJECT IDENTIFIER ::= { pktcMtaMib 0 }

# 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 }
Agree. will be changed accordingly.

# Comment 37
> - Same for the pktcMtaBasicSmtaCompliance spec.
Agree. will be changed accordingly.

# 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.
Proposed new text:
  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.
 
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.
 
we need to double check that and report back. 
 
bw: hope you did so and have agreement from original commenting people.
 
Bert 
 
> end.

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 12 Sep 2005 21:52:38 +0200

Inline

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
Sent: Monday, September 12, 2005 21:12
To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
Cc: Richard Woundy @ Comcast
Subject: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

# Comment 13
> experience) has chosed to haev a Admin and Operational status in two separate objects.
 
Let me put some more clarification on the issue which may address your general concern with the Admin and Operational Status separation. One of the reasons it would make sense to separate Admin and Operational status is the potentail delay between the the SNMP SET changing the Admin Status and actual Operational status of the device including the case when the device might be not able to set the corresponding Admin status for some reasons internal to the device. In case of EMTA Enabling/Disabling, the PacketCable Provisioning spec does not allow such delays and requires the EMTA to disable/enable the Telephony Services on the EMTA with very minimal delay (if at all). Hence, from the operational prosective, the separation of the Admin and Operational Statuses in PacketCable environment does not seem to be required.
 
Hope this clarifies. Please elaborate further - otherwise.
 
bw: Answered in other email

# Comment 14

> that explanation is added to the description clause or easily available 

> via the REFERENCE clause. Given the discussion on this topic so far, it seems best to add some text to the 
description clause.

       DESCRIPTION  
           " This object provides the MTA device type identifier. The 
             value of this object must be a copy of the DHCP option 60 
             value exchanged between the MTA and the DHCP server."  
 
And from that it seems most people do/did not understand exactly what the content
should be, right?
 
Berty

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Mon, 12 Sep 2005 12:57:12 -0700

To clarify: I recalled my response to the group as it was not complete at the
moment it was sent accidentaly. Please disregard it if somebody did not
receive the recall notification.
 
Thanks,
 
Eugene.

________________________________

From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Monday, September 12, 2005 12:53 PM
To: Eugene Nechamkin; Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
Cc: Richard Woundy @ Comcast
Subject: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

Inline

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]]
	Sent: Monday, September 12, 2005 21:12
	To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
	Cc: Richard Woundy @ Comcast
	Subject: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

	# Comment 13
	> experience) has chosed to haev a Admin and Operational status in
two separate objects.
	 
	Let me put some more clarification on the issue which may address
your general concern with the Admin and Operational Status separation. One of
the reasons it would make sense to separate Admin and Operational status is
the potentail delay between the the SNMP SET changing the Admin Status and
actual Operational status of the device including the case when the device
might be not able to set the corresponding Admin status for some reasons
internal to the device. In case of EMTA Enabling/Disabling, the PacketCable
Provisioning spec does not allow such delays and requires the EMTA to
disable/enable the Telephony Services on the EMTA with very minimal delay (if
at all). Hence, from the operational prosective, the separation of the Admin
and Operational Statuses in PacketCable environment does not seem to be
required.

	# Comment 14
	
	> via the REFERENCE clause. Given the discussion on this topic so
far, it seems best to add some text to the 
	description clause.

	       DESCRIPTION  

	             value of this object must be a copy of the DHCP option
60 
	             value exchanged between the MTA and the DHCP server."  
	 
	And from that it seems most people do/did not understand exactly what
the content
	should be, right?
	 
	Berty

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Mon, 12 Sep 2005 12:11:41 -0700

# Comment 13

> experience) has chosed to haev a Admin and Operational status in two
separate objects.
 
Let me put some more clarification on the issue which may address your
general concern with the Admin and Operational Status separation. One of the
reasons it would make sense to separate Admin and Operational status is the
potentail delay between the the SNMP SET changing the Admin Status and actual
Operational status of the device including the case when the device might be
not able to set the corresponding Admin status for some reasons internal to
the device. In case of EMTA Enabling/Disabling, the PacketCable Provisioning
spec does not allow such delays and requires the EMTA to disable/enable the
Telephony Services on the EMTA with very minimal delay (if at all). Hence,
from the operational prosective, the separation of the Admin and Operational
Statuses in PacketCable environment does not seem to be required.

# Comment 14
description clause.

       DESCRIPTION  

From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Monday, September 12, 2005 8:39 AM
To: Jean-Francois Mule; Ipcdn (E-mail)
Cc: Eugene Nechamkin; Richard Woundy @ Comcast
Subject: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

Sorry that it took a while. But I just cannot always jump up at the exact
moment
that a MIB document from you arrives. 
 
First a geneal remark about my comments about missing referecnces and/or
citations.
As I said in my evaluation, the tool I use has bugs and is primitive. One can
use it
as a bit of a helper to try and get the references/citation as good as
possible.
So I am going to assume you have now done so.

	-----Original Message-----
	From: Jean-Francois Mule [mailto:[email-masked]]
	Sent: Monday, September 05, 2005 15:52
	To: Wijnen, Bert (Bert); Ipcdn (E-mail)
	Cc: [email-masked]; Richard Woundy @ Comcast; Jean-Francois
Mule

	Bert, and all,

	  We would appreciate receiving!
	  quick input from you and the wg on the
	proposed changes for draft 07, and in particular, for Comments #:
	  12, 13, 14, 15, 19, 20, 21, 22, 23, 28, 29, 30, 31, 32, and 38.

	Thanks,
	 
	---
	 
	Bert wrote:
	http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01693.html
	 
	# Comment 1
	> <
	/SPAN>
	>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
	> &n
	bsp;   accepted.)
	>   If you use xml2rfc, then it is taken care of automagically by the
	ok, fixed.
	Will run the latest idnits tool before submission, just l!
	 ike we did
	for draft06 (the boilerplate was updated since draft06 submission).

	# Comment 2

	 
	 
	# Comment 3

	# Comment 4
	Proposed resolution: re
	ference to [RFC2863] is introduced. We propose

	# Comment 5
	>     P049 L042:    [RFC3410] Case, J., Mundy, R., Partain, D. and B.
	&nb!
	 sp;  [RFC3410] - the citation is not missing, it is present in th
	e text.
	               See: section 1, end of 1st sentence.
	               No action taken.

	# Comment 6
	&!
	 nbsp;   MODULE-IDENTITY,
	          FROM SNMPv2-SMI              !
	 ;      -- [RFC2578]
	    NOTIFICA!
	 TION-GROUP
	 &nbs!
	 p;        FROM SNMPv2-MIB                    -- [RFC3418]
	 & nbsp;  --
************************************************************
	    -- *                                   !
	            &nbs
	p;           *

	    ifPhysAddress

	bw: That would be fine
	<
	/SPAN> 
	  
	# Comment 7
	>     P004 L025:    Configuration DHCP specifications, RFC 3495
	   RFC3495 - Reference is not missing it's pre!
	 sent in the Normative References.
	               No action taken.

	# Comment 8
	>    P048 L027:    [RFC3594] P. Duffy, "PacketCable Security Ticket
	  RFC3594 - Reference is not missing it's present in the Normative
References.
	               No action taken.

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

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

	# Comment 11
	  
	bw: fine 
	 
	# Comment 12
	>    !
	 ; ... etc ..
	ok.

	 !
	 
	pktcMtaDevReset!
	 KrbTickets:
	  
	bw: seems fine to me. As said many times before: it is important to
document what
	the expected behaviour is.
	 
	# Comment 13
	Proposed resolution: no action
	In general, we agree with the comment and our first reaction was,
yes,
	let's rename it and add an operStatus one.
	But after looking at its definition in more details, syntax
	(ThruthValue) and after c
	onsidering a new operStatus object, we think
	that:
	        - pktcMtaDevEnabled is both an admin and operational status
	          object, hence the name is probably ok,
	        - it returns the operational status of the enable/disable
	          switch when read.
	Our proposal, after reviewing your comment is still to leave it
as-is.
	Is this ok? if not, can you elaborate?
	  
	bw: The issue is that if you use one single object for both the
admin's desire of the status and
	at the same time for the actual operational status, then it gets
difficult.
	 
	If you issue an SNMP SET to enable, then if you accept it, then that
means that the value
	is to be changed to enabled. If however the value then later changes,
then I bet that the
	management station is at least very surprised. It is not for nothing
that the IF-MIB (after a long
	experience) has chosed to haev a Admin and Operational status in two
sep!
	 arate objects.
	 
	If you use one object, and I do a SET for ENABLE, then you are
telling
	me that a GET-RESPONSE to the SET that say it is OK is useless, and
	that I need to do another GET for the object in order to check if my
	SET actually succ!
	 eeded or not? 
	  
	# Comment 14
	Proposed resolution: no action
	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.5:xxxxxx". Where xxxxxx MUST be an ASCII
	representation of the hexadecimal encoding of the MTA TLV Encoded!

	bw: See, it seems you do have a valid explanation. If so, then fine.
It would be best if some of
	th!
	 at explanation is added to the description clause or easily
available 
	via the REFERENCE
	clause. Given the discussion on this topic sofar, it seems best to
add some text to the 
	description clause.

	
	 
	# Comment 15
	 
	pktcMtaDevSerialNumber

	pktcMtaDevSwCurrentVers
	 
	pktcMtaDevSnmpEntity
	Proposal: No action re!
	 quired, 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.")
	 
	The "IA5String" type !
	 is defined in ISO/IEC646:1991 and also known

	bw: See above my comment on SnmpAdminString, Utf8String and clear
text in description
	clauses 
	 
	# Comment 16
	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
	  
	bw: I hope that this is now clear from th
	e MIB writeup 
	 
	# Comment 17

	# Comment 18
	Yes, agree.
	Proposed text:
	    REFERENCE

	bw: as I have seen on the list, I am not sire that such makes it
completely
	clear. But I leave it to the WG to decide.
	 
	# Comment 19

	bw: I stand corrected. I guess I overlooked it.!

	# Comment 20
	>&nbs!
	 p;  different server addresses.
	Good point.
	Proposed resolution:

	bw : good. Pls adapt the InetAddress objects accordingly to refer to
the proper
	AddressType object.
	 
	# Comment 21
	>   once the Security ADs take a look?
	Proposed Resolution:
	  - change the syntax of pktcMtaDevProvConfigKey to be 32 octets
(256)
	    or may be more
	  - add a new object named pktcMtaDevProvConfigEncryptAlg to specify
	    the encryption algorithm
	                           none(0),
	                           des64CbcMode(1),
	                           t3Des128CbcMode(2),
	                !
	            ae
	s128CbcMode(3),
	                           aes256CbcMode(4)
	  - 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 pag!
	 e 26 probably better go into some
	<
	FONT face="Courier New" color=teal size=2>>   object DESCRIPTION
clause, no?
	OK they have been in the draft for a long time.
	But where do we put it? should we just paste it in one or all of the
3
	relevant objects (pktcMtaDevProvUnsolicitedKeyMaxTimeout,
	pktcMtaDevProvUnsolicitedKeyNomTimeout,
	pktcMtaDevProvUnsolicitedKeyMaxRetries)
	We can also put i!
	 t in section 3.3 and/or in the mib objects. if so, in
	which one do we duplicate the same text in all the 3 objects?
	Please let us know your preference.
	 
	bw: In general we must realize that when a MIB module gets extracted
from a document,
	then the comments often go away. So the more text you can pu!
	 t in appropriate DESCRIPTION

	clauses, the better. If that sometimes means a repeat of text, so be
it.

	It is not a hard rule. I always make sure people realize that the
comment lines
	may disappear after MIB module is extracted into tools or GUI
interfaces.

	# Comment 23
	CONCLUSION: "SnmpAdminString" type is the closest mapping to
"UTF8String"

	W.r.t. the upper limit 64, is it octets or is it characters. You are
aware that a single
	character can need up to 6 octets to be represented in a UTF8string
or SnmpAdminString
	right? In any event, it is impor
	tant to be very clear what the size restriction is.

	# Comment 24
	>                    !
	 ;  is not presently specified and therefore, is not
	
	>           &nbs!
	 p;          is not presen
	tly specified and therefore, is not

	# Comment 25
	>   You have done this in other MIB modules, so you should know I
think.
	ok, will be reflected in all applicable objects. will check
thorougly.

	# Comment 26

	# Comment 27
	ok, fixed.

	# Comment 28
	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.

	bw: Well, such may all be true, but you also do agree that we still
found serious issues, no?
	 
	> my head that I could quickly ensure they are all correct.
	  based on the above, we think we have addressed the concerns, if
not,
	let us know.

	bw: probably so.
	 
	I think we have justified the DHCP questions. I (Jean-Francois) can
	certainly asked Ralph Droms for cross-review. As for the security,
per
	the fixes of BPI+, let us know if this is not good enough.
	 
	If you are confident, we can go ahead. I do know that we have
security ADs and other
	ADs who will look after the DHCP issues at IESG review time. My point
was that it is
	probably better to ensure early that things are OK.  You seem to
trust such is the case,
	then fine by me.

	 
	# Comment 29
	>   That seems conflicting, no?
	Proposed resolution:
	delete       If this object is set to a zero value, the MTA MUST
return
	             an 'inconsistentValue' in response to SNMP SET
operations.
	 
	bw: sounds fine, assuming the object was indee!
	 d intended to be read-only
	  
	# Comment 30
	> - Same for pktcMtaDevProvUnsolicitedKeyNomTimeout
	Proposed resolution:
	delete       If this object is set to a zero value, the MTA MUST
return
	             an 'inconsiste!
	 ntValue' in response to SNMP SET operations.<
	/PRE>
	 
	bw: same
	  
	# Comment 31
	Proposed resolution:
	of ASN.1 type "GeneralString". This type has numerous interop
problems
	!
	"SnmpA!
	 dminString" seem to be the closest mapping in SMI. The
	 
	bw: DisplayString better not be used anymore. Certainly not if the
underlying technology
	is prepared to do UTF8 in the future. Then we better be pre!
	 pared too.
	And (as I think you know), US ASCII is represented the same in a
DisplayString as
	it is in an SNmpAdminString or Utf8String.

	# Comment 32
	Proposed resolution:
	       see above, 2 options:

	# Comment 33
	>   Should they not be both limited to 64 or 32 (i.e. same value) ??
	Agree.
	Proposed resolution:
	 !
	 ; change pktcMtaDevRealmIndex's SYNTAX to
	       SYNTAX      Unsigned32 (1..64)

	 # Comment 34
	>        SYNTAX      Unsigned32 (1..64)
	Proposed resolution:
	  change pktcMtaDevCmsInd!
	 ex's SYNTAX to

	# Comment 35
	Proposed resolution:

	# Comment 36
	    DESCRIPTION
	>        MODULE  -- Unconditionally man!
	 datory groups for MTAs
	>      &nb!
	 sp;           &
	nbsp; " Support for address types other than 'ipv4(1)'
	>                pktc!
	 MtaGroup,
	>                SYNTAX      I!
	 netAddressType { ipv4(1) }
	>   !
	            &nbs
	p;       required. It may be defined in future versions of
	>  &nbs!
	 p;             SESCRIPTION

	# Comment 37

	# Comment 38
	Agree.
	Proposed new text:
	  for pktcMtaDevFQDN:
	 
	pktcMtaDevSnmpEntity
	          The MTA must resolve
	  &nbs!
	 p;       the FQDN value before its very 
	first network interaction
	          with the SNMP entity during the provisioning phase.
	 
	pktcMtaDevCmsFqdn

	# Comment 39

	bw: hope you did so and have agreement from original commenting
people.
	 
	Bert