[ipcdn] RE: IPCDN eventmess-09 review

["Jean-Francois Mule" <[e-mail]>]

Hi, David,

   First, thank you for taking the time to review and for your comments.
I copy ipcdn as I think those discussions should go to the list.

   I think some of your comments deserve more time to review and the
authors should respond soon in more details.

   That said, there are a few comments that I want to answer now. 

See inline.
Jean-Francois.
IPCDN co-chair

> -----Original Message-----
> From: David B Harrington [mailto:[e-mail]]
> Sent: Monday, March 12, 2007 1:50 PM
> To: Jean-Francois Mule
> Cc: Richard Woundy @ Comcast; Sumanth Channabasappa;
> [e-mail]; [e-mail]; 'Romascanu, Dan (Dan)'
> Subject: IPCDN eventmess-09 review
> 
> Hi,
> 
> Executive Summary:
> To try to get you some feedback sooner rather than later, I did a
> fairly quick review of the document. I did NOT do a throrough review.
> I have some serious concerns with the document. Some things suggest
> that this document did not get a thorough review by the WG first. The
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Expert review was requested and Greg Nakanishi who authored the Docsis
event mgmt mib module provided comments late 2005. You reviewed draft-06
and provided comments to Sumanth on 6/20/2006 which were addressed in
draft-07 and subsequent versions.
Also, many ipcdn folks are acknowledged in the ID: some are device
manufacturers who reviewed this a few times, as did folks from tComLabs.
Finally Randy and Bert did chime in a couple of times on issues raised
on the ID.
That said, we always benefit from more reviews.

> document does not pass id-nits cleanly (although partly because we
> moved into a new year, and partly because the IPR boilerplate
> changed).

Ok, note that this was caught in the proto write-up.
This must be fixed but they are easy to fix (we caught the same kind of
issues on the ipcdn signaling mib module and they were fixed in
draft-13).

> Two very major issues of consistency with other IETF efforts plague
> this document. This is understandable because this document tries to
> correlate SNMP and syslog event messaging, and it is based on work
> being done by Packetcable, but if this is going to be published as an
  ^^^^^^^^^^^^^^^^^^^^^^^^^
  Since 2002, the work on this ID has been done in the IETF.

> IETF document, it should be consistent with the IETF SNMP and Syslog
> standards work.
Certainly and this has been a driver for the other IDs in IPCDN and the
main purpose for moving the work to IETF IPCDN.


> SNMPv1 and SNMPv2c have been declared Historic and NOT RECOMMENDED,
> but this document is obviously geared to working with SNMPv1 message
> formats, especially the SNMPv1 Trap-PDU.
This is not the intent and not my personal recollection. 
All mib modules in IPCDN are 'geared to' working with SNMPv3.
As a matter of fact, this is mentioned in the security consideration
section. 
What makes you say that w.r.t. the pdu format and what restrictions do
exist in the current mib module that would prevent SNMPv2 and SNMPv3 msg
formats? 
Let fix this and please elaborate.
Is this because pktcDevEventDescrEnterprise is included in
notifications?

> The syslog WG has been working to standardize the syslog protocol,
> including a UDP and a TLS transport, and a MIB module. Yet this
> document is based on RFC3164, which the syslog WG is probably going to
This document started in 2002 and is based on rough consensus and
working code.

> request be declared obsolete. This document does not properly hanlde
> different types of transports for Syslog. I do not think this document
> should progress unless it is brought into alignment with the syslog
> documents.
I think we should discuss this more.
Not all transport of syslog may be used or supported by all devices,
certainly not devices in the field right now without a TCP stack... 
Some of these limitations do exist because of small memory footprint on
some devices and just common usage of syslog on some access networks.

> Some objects in this document contain address information, and do not
> appear to support both IPv4 and IPv6 addressing, although the document
  ^^^^^^^^^^^^^^^^^
  Elaborate
> is actually inconsistent on this point, using InetAddress TCs in some
> places and not others.

I have not done a recent review of the MIB but objects use the
InetAddress TC.
If you are talking about making the DESCRIPTION clause of objects like
pktcDevEvSyslogAddress  more generic to use IPv6 examples, ok, this can
certainly and should be done. 
Is that what you mean here?

> ISMS is expanding the types of InetAddresses
> that can be used for SNMP (to support SSH transports). This MIB does
> not have transport agility.

Stopping here due to time constraints, will let the authors review and
chime in here.


> 
> I believe a revision of this document is necessary, even before I do a
> thorough review.
> 
> Some details to be addressed:
> 
> 1) The title on pages after the first use different authors and dates
> inconsistent with the first page.
> 
> It is your choice, but I recommend using xml2rfc; that tool would have
> made sure you had consistency on these points. I do think this MIB
> module document is likely to go through another 2-3 revisions, to deal
> with RFC4181 consistency, and to go through an analysis of the SNMP
> type usages, addressing, table relations, and to handle updates to
> coordinate with other documents in progress, so making the change to
> xml2rfc could be justified.
> 
> 2) This document does not pass the idnits tools cleanly.
> IPR boilerplate needs to be updated per RFC4748
> There is no Intended Status
> Page lengths exceed maximum allowed
> Copyright needs to be updated (due to crossing into the new year)
> 
> (page lengths might be longer because you are word-wrapping sooner;
> there are lots of lines that have wrapped in the new revision that
> were not wrapped in the old revision. Changing your line-length value
> might fix the page length problem, and resolve most of the hyphen
> breaks as well.)
> 
> 3) I think the copyright and disclaimer normally do not get section
> numbers.
> 
> 4) section 3.0 has an unusual line break
> 
> 5) section 3.1, 3.2, etc have unusual numbering; this is apparent
> through most of the document, and is probably the result of an nroff
> macro or something similar.
> 
> 6) section 3.2 and section 3.3 have line breaks on a hyphenated term.
> 
> 7) I personally preferred having the subtree descriptions numbered in
> section 4, but that's just personal preference.
> 
> 8) top level assignments in the MIB have a closing parenthesis on a
> separate line.
> 
> 9) SyslogSeverity in the syslog MIB is not a BITS type, but an Integer
> enumeration. pktcDevEventClassSeverityLevel discusses setting bits. It
> appears you are modeling a bit-mask rather than modeling severity
> level. I will discuss this with my syslog co-chair and other MIB
> Doctors and get back to you about the preferred approach to resolve
> this. My first impression is that defining a SeverityLevelMask TC
> (from your previous revision, but renamed to clarify that it is a
> mask) would be the simplest approach for ipcdn, and keep the
> syslogSeverity TC in the syslog mib. See below for more on this topic.
> 
> 10) What is the value of pktcDevEventDescrEnterprise for an SNMP
> warmStart (defined in rfc1157)?
> 
> The enterpise field in an SNMP Trap-PDU is an OID that identifies the
> object generating a trap. For an SNMPv1 warmStart trap, the enterprise
> is iso(1).org(3).dod(6).internet(1).mgmt(2).mib(1).snmp(11); how is
> that represented as an integer value in the eventmess mib?
> 
> What is the value of pktcDevEventDescrEnterprise for the
> lldpNotificationInterval notification from the LLDP MIB defined by
> IEEE 8021? The notification identifier is "iso(1) std(0) iso8802(8802)
> ieee802dot1(1) ieee802dot1mibs(1) lldpMIB(2) lldpNotifications(0)
> lldpNotificationPrefix(0) lldpRemTablesChange(1)". SMIv2 traps and
> informas do not use the Enterprise field; they use an OID to identify
> the notification, which usually includes where it is defined; this
> identification does not depend on the IANA-assigned enterprise values.
> 
> 
> RFC3584 describes how to convert from an RFC1157 enterprise object
> identifier to an SMIv2 notification object identifier. I recommend
> lokin gthis over to understand the relationship.
> 
> What is the value of pktcDevEventDescrEnterprise for a syslog event,
> descrbed using an SDE with enterpriseId of "0.1.2"?
> 
> Suggestion: Using an SMIv2 style OID for the event might make more
> sense than using an integer value.
> 
> 11) the syslogMIB defines SyslogFacility TC I recommend using that as
> the syntax for pktcDevEventDescrFacility.
> 
> 12) Some objects defined with SyslogSeverity treat the object as a
> BITS type (with multiple bits set), others treat the object as an
> enumeration (one value at a time). This needs to be fixed.
> 
> 13) For pktcDevEventDescrReporting, why MUST the values be set? The
> BITS type is extensible; why MUST the bits for any new types be set to
> 0, even though you do not know what the notification types are?
> 
> 14) For pktcDevEventDescrReporting, where are the default values
> specified that correspond to the severitylevel values? Are the
> following two paragraphs setting default values? It doesn't say that.
> 
> 15) why must pktcDevEventDescrId be either packetcable-defined or
> vendor-specific? Why not ietf-defined? What about, say, ieee defined?
> See note 10, which would make this distinction unnecessary.
> 
> 16) I have real concerns about the number of objects that are specific
> to PacketCable. Can this MIB be genericed to work for other MTAs as
> well? If this is a PacketCable-specific MIB, then it should probably
> be published by PacketCable as an enterprise MIB or as a Packetcable
> standard MIB rather than as an IETF MIB. If there are no other MTA
> standards, then you shouldn't need all the referebces to PacketCable
> in the Description clauses.
> 
> 17) The I-D does not specify the Intended Status.
> 
> 18) pktcDevEventDescrReporting mentions SNMP traps; for
> interoperability reasons, I believe it is necessary to specify whether
> that refers to Trap-PDU (SNMPv1) or Trapv2-PDU (SNMPv3). Since SNMPv1
> has been declared Historic by IETF, I think only Trapv2-PDU should be
> generated by an IETF standards-track MIB module. But I might be
> convinced otherwise.
> 
> 19) I have some concerns about naming conventions. I recommend
> checking the recommended practices discussed in RFC4181.
> 
> Consistent prefixes, shorter names, and fewer embedded abreviations
> make object names easier for operators to remember.
> 
> 19a) It will not be immediately obvious to users that objects starting
> with pktcDev came from the pktcIetfEventMib. Do you intend to publish
> an pktcIEEEeventMIB and a pktcITUEventMIB and a ...? If not, then
> pktcEventMIB would probably suffice.
> 
> 19b) Does this MIB only document pktc device events? Are there other
> types besides device events? If not, you could drop the Dev from all
> these object names, and stick with pktcEvent as a consistent prefix.
> 
> 19c) Why use different prefixes for pktcDevEventControl and
> pktcDevEvSyslogAddressType?
> 
> 20) RFC3164 is an informational RFC. The Syslog WG is probably going
> to recommend it be declared Historic or Obsolete as an IETF document.
> The IETF is publishing a standardized syslog protocol, and this MIB
> module should be consistent with the IETF standard protocol and
> transports.
> 
> Notably, you have an object pktcDevEventSyslsogUdpPort, but the syslog
> WG is defining multiple transports. Your addressing should be
> consistent with the syslog standard work. You have no way of
> specifying a TLS port or a BEEP encapsulation.
> 
> 21) DevEvLogIndex - what does the sentence "The next entry for all the
> above cases is 1." mean?  In the sentence "This also serves as an
> indicator of event sequence.", what does This refer to?
> 
> 22) DevEvLogTargetInfo does not provide enough information to take the
> actions. To send an Inform, you need more than an IP address and port;
> you need the SNMPv3 context and security information. To send a syslog
> message, you should have the address type (IPv4/IPv6/DNS/etc.), the
> address, the port, and the encapsulation. The IP address should be
> either IPv6 or IPv4, so you need an address type identifier.
> 
> RFC3413 defines target tables, and you could use pointers to a row in
> those tables, which would give you adequate info to send the SNMP
> traps and informs.
> 
> 23) Why do you need pktcDevEvNotificationIndex? You already have
> pktcDevEvNotifications creating a subtree (with the 0 value required
> for notifications); why create another 0-valued subtree under that?
> 
> 24) pktcDevEvInform contains an enterprise value, which was
> deliberately eliminated from traps in SMIv2, and RFC3584 discusses how
> to convert from SNMPv1 traps to SMIv2 traps/informs. Why do you have
> this value here?
> 
> Hope this helps,
> David Harrington
> [e-mail]
> [e-mail]
> [e-mail]


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