RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt
"Eugene Nechamkin" <[email protected]> Mon, 12 Sep 2005 12:11:41 -0700
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <24CDBA67F085904999751B3C4F9E8C0B031231F4@NT-RMNA-0740.brcm.ad.broadcom.com> |
# Comment 13
> 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.
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.
# Comment 14
> 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 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."
________________________________
From: Wijnen, Bert (Bert) [mailto:[email protected]]
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.
Inline (blue text is mine. You had "commnt n" already in blue too)
-----Original Message-----
From: Jean-Francois Mule [mailto:[email protected]]
Sent: Monday, September 05, 2005 15:52
To: Wijnen, Bert (Bert); Ipcdn (E-mail)
Cc: [email protected]; 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
# Comment 1
> - $ idnits draft-ietf-ipcdn-pktc-mtamib-06.txt
> idnits 1.74
> <
/SPAN>
> 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
> &n
bsp; 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 l!
ike 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: re
ference 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,
&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
> !! 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
&!
nbsp; 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,
NOTIFICA!
TION-GROUP
FROM SNMPv2-CONF -- [RFC2580]
InetAddressType,
InetAddress
FROM INET-ADDRESS-MIB -- [RFC4001]
sysDescr
&nbs!
p; FROM SNMPv2-MIB -- [RFC3418]
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
docsDevSoftwareGroupV2
FROM DOCS-CABLE-DEVICE-MIB -- [RFCxxxx]
& nbsp; --
************************************************************
-- * 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 *
-- * !
&nbs
p; *
-- ************************************************************
DocsX509ASN1DEREncodedCertificate,
docsBpi2CodeDownloadGroup
FROM DOCS-IETF-BPI2-MIB -- [RFC4131]
ifPhysAddress
FROM IF-MIB; -- [RFC2863]
bw: That would be fine
<
/SPAN>
# 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 pre!
sent 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
pktcMtaDevReset!
KrbTickets:
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 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
> - 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
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.
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 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.")
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
section 8.5
bw: I hope that this is now clear from th
e 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
>&nbs!
p; 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 pktcMtaD
evProvConfigKey
> 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.
bw: if that is same as for BPI+, then I guess it will be acceptable.
# 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
> - 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 impor
tant 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)'
> &nbs!
p; is not presen
tly 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 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
> - 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
"SnmpA!
dminString" 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 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.
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 pktcMtaDevCmsInd!
ex'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 man!
datory groups for MTAs
>
> MANDATORY-GROUPS {
> pktcMtaGroup,
> pktcMtaNotificationGroup
> }
>
> OBJECT pktcMtaDevServerAddressType
> SYNTAX InetAddressType
> DESCRIPTION
> &nb!
sp; &
nbsp; " 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 {
> pktc!
MtaGroup,
> pktcMtaNotificationGroup
> }
>
> OBJECT pktcMtaDevServerAddressType
> SYNTAX I!
netAddressType { ipv4(1) }
> DESCRIPTION
> " Support for address types other than 'ipv4(1)'
> is not presently specified and therefore, is
not
> !
&nbs
p; required. It may be defined in future versions of
> this MIB module."
> OBJECT pktcMtaDevServerDhcp1
> SYNTAX InetAddress SIZE (4)
> &nbs!
p; 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
&nbs!
p; 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 protected]
https://www1.ietf.org/mailman/listinfo/ipcdn