[ipcdn] Some comments on eventmess-09

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

IPCDN Folks,

   FYI. As a rule of thumb, please send ID comments to all authors of an Internet-Draft and the ipcdn list.

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

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
IETF document, it should be consistent with the IETF SNMP and Syslog
standards work.

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.

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

Some objects in this document contain address information, and do not
appear to support both IPv4 and IPv6 addressing, although the document
is actually inconsistent on this point, using InetAddress TCs in some
places and not others. ISMS is expanding the types of InetAddresses
that can be used for SNMP (to support SSH transports). This MIB does
not have transport agility.

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]


> -----Original Message-----
> From: Jean-Francois Mule [mailto:[e-mail]] 
> Sent: Monday, March 12, 2007 6:11 AM
> To: [e-mail]
> Cc: Richard Woundy @ Comcast; Sumanth Channabasappa; 
> [e-mail]; [e-mail]; Romascanu, Dan (Dan)
> Subject: RE: Re-sync on IPCDN wg activities
> 
> David, Dan,
> 
>   Any ETA re:
> > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-even
> > > tmess-09.t
> > > xt
> > > This ID has been submitted to IESG (publication was requested on
> > > 12/13/2006) along with the proto write-up. We are awaiting an
> > > update from you as our AD.
> > > The next step seems to be a MIB doctor review.
> > 
> > David Harrington committed to issuing a complete MIB Doctor review
> > sometime soon.
> 
> 
> Let me and Rich know. Also, Sumanth and I will be in IETF 
> next week and available to chat if needed.
> 
> Thank you in advance,
> Jean-François
> 
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> > Sent: Monday, February 26, 2007 7:17 AM
> > To: Jean-Francois Mule
> > Cc: Richard Woundy @ Comcast; Sumanth Channabasappa;
> > [e-mail]; [e-mail]; 
> [e-mail]
> > Subject: RE: Re-sync on IPCDN wg activities
> > 
> > 
> > Hi Jean-Francois,
> > 
> > Thank you for the update.
> > 
> > See in-line.
> > 
> > Dan
> > 
> > 
> > > -----Original Message-----
> > > From: Jean-Francois Mule [mailto:[e-mail]]
> > > Sent: Monday, February 26, 2007 11:37 AM
> > > To: Romascanu, Dan (Dan)
> > > Cc: Richard Woundy @ Comcast; Sumanth Channabasappa;
> > > [e-mail]; [e-mail];
> > [e-mail]
> > > Subject: RE: Re-sync on IPCDN wg activities
> > >
> > > Hi Dan,
> > >
> > >    This note provides a quick status update on IPCDN, a wg
> > > that will not meet at the upcoming meeting in Prage. This is
> > > based on some email exchanges Rich and I had with the current
> > > editors/co-authors of the IDs.
> > >
> > > -
> > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-even
> > > tmess-09.t
> > > xt
> > > This ID has been submitted to IESG (publication was requested on
> > > 12/13/2006) along with the proto write-up. We are awaiting an
> > > update from you as our AD.
> > > The next step seems to be a MIB doctor review.
> > 
> > David Harrington committed to issuing a complete MIB Doctor review
> > sometime soon.
> > 
> > >
> > > -
> > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-sign
> > > aling-12.t
> > > xt
> > > We expect that this draft will be revised one more time,
> > > likely before the cut-off date of March 5 2007. The proto
> > > write-up will follow shortly after that along with a request
> > > to publish it.
> > > (During the completion of my proto write-up for this ID,
> > > there were quite a few comments that we (Rich and I) feel
> > > should be addressed in a revised ID.)
> > >
> > > Let me or Rich know if you have any comments or questions on
> > > this. I will be in IETF if we need to chat live.
> > 
> > No questions by now. Normally I would have asked you to update the
> > dates
> > in the charter, but taking into consideration that you may 
> submit the
> > last document to the IESG by next week together with the 
> proto write-
> > up
> > I would wave this by now.
> > 
> > >
> > > Thank you,
> > > Jean-Francois.
> > > [e-mail]
> > >
> > 
> 
> 
> 





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