RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt
"Jean-Francois Mule" <[email protected]> Mon, 5 Sep 2005 07:51:48 -0600
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
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
# 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. 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]
# 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
# 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
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.
# 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?
# 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.
# 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.
# 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
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
> 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.
> 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.
>
> Bert
Thanks again for all the comments
# 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.
# 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.
# 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?
# 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.
> end.
_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn