RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt
"Wijnen, Bert (Bert)" <[email protected]> Mon, 12 Sep 2005 17:39:04 +0200
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <7D5D48D2CAA3D84C813F5B154F43B1550808DA1C@nl0006exch001u.nl.lucent.com> |
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 <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 protected] https://www1.ietf.org/mailman/listinfo/ipcdn