Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Fri, 14 May 2004 14:52:08 -0700

Eduardo,

Thanks for the feedback.

Let's wait to hear what the MIB doctors say about the object name.  I'm OK with changing the name, if that's the recommendation.

greg

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 1:11 PM
To: Nakanishi Greg-MGI8179; Raftus, David; Ipcdn List (E-mail)
Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt

Greg, 
You are right to point the RFC3413 filtering mechanism and trap/inform dispatch.

The discussion of Notification vs Trap in the object names was handled before (draft01-02 transition I guess) under the assumption of not re-rooting, (to avoid deprecation and too much unnecesary work). If it is going to be rerooted, I believe a 'Notification'/'Notify' rather than 'Trap' would be precise as IETF might concern or stay as it is right now if that is ok for MIB doctors to keep the terminology as 'Trap's.

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 12:37 PM
To: 'Raftus, David'; Ipcdn List (E-mail)
Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt

hi Dave,

Thanks for reviewing the draft.  Sorry for the delayed response. My responses are inline.

> 1) Not sure if the default value of NULL is appropriate for the BITs 
> defval for object docsDevCmTrapControl. This doesn't give any real 
> guidance as to whether the traps should be enabled or disabled. The 
> original value of 0x00, while perhaps not strictly conforming to the 
> octet string nature of BITs, did signal that all traps default to off.
> 

I think some input from a MIB expert would be useful here.  However, from the example given in RFC2578, I think a NULL value indicates that all the bits are set to zero.  The following snippet is from section 7.9 of RFC 2578.

BITS               DEFVAL { { primary, secondary } }
                   -- enumerated values that are set
BITS               DEFVAL { { } }
                   -- no enumerated values are set

> 2) The intention of keeping the deprecated mib objects within
> the trap definitions was to maintain back-compatibility with 
> existing 1.1 applications that implemented the trap defs 
> using the original docs-if ext mib. With the deprecated 
> objects removed, it is possible that these pre-rf mib v2 
> draft 1.1 applications may not be compatible with the new trap defs. 
> 
This MIB isn't going to be backward compatible anyway since the MIB root is going to change.  The docs-if ext mib is rooted under docsdev while this mib will be rooted under mib-2.  So, implementations will have to change regardless.

> 3) The event mib is not in sync with the MTA event mgmt mib.
> It is not really fair to compare them. The MTA event mgmt mib 
> uses a generic definition for all informs and traps 
> pertaining to MTA events. The Docsis event mib creates 
> individual trap defs for each event. It may be a nice idea to 
> add inform defs in the Docsis event mib though. 

I think that the notifications defined in this MIB can be sent as a Trap or an Inform.  Although, the notification object all end with the term 'trap' which would seems to imply that they should be sent as a trap.  Whether a notification is sent as a Trap or Inform should be defined outside of the MIB itself, I think.  For example, the Notification MIB (RFC 3413) supports the ability to do this.

Thanks again for reviewing.

greg
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Raftus, David
Sent: Thursday, April 29, 2004 11:15 AM
To: Ipcdn List (E-mail)
Subject: FW: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt

Hi, 
Forwarding event mib review comments to the list. 
Thanks, 
Dave 
-----Original Message----- 
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Thursday, April 29, 2004 12:24 PM 
To: Raftus, David 
Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail) 
Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt 
Hi David, 
Thank for your DOCSIS review, this is the most important. Can you still send your DOCSIS review comments to the list? This was requested by Bert as it is standard ietf process... Thanks again, 
Jean-François 
> -----Original Message-----
> From: Raftus, David [mailto:[email-masked]] 
> Sent: Thursday, April 29, 2004 8:30 AM 
> To: Jean-Francois Mule 
> Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail); Raftus, David 
> Subject: RE: [ipcdn] wg review of 
> draft-ietf-ipcdn-docsisevent-mib-03.txt 
> 
> 
> Hi Jean-Francois,
> 
> This event mib draft is actually not too different from the
> v2 version created in Jan/03. 
> 
> I'm afraid I don't have the necessary background to evaluate
> the mib according to compliance with the mib guidelines and 
> conformance with ID-nits. Sorry for that. Therefore, I didn't 
> CC my comments to the IPCDN list. 
> 
> I did examine the mib from a Docsis perspective though, and
> have the following comments: 
> 
> 1) Not sure if the default value of NULL is appropriate for
> the BITs defval for object docsDevCmTrapControl. This doesn't 
> give any real guidance as to whether the traps should be 
> enabled or disabled. The original value of 0x00, while 
> perhaps not strictly conforming to the octet string nature of 
> BITs, did signal that all traps default to off. 
> 
> 2) The intention of keeping the deprecated mib objects within
> the trap definitions was to maintain back-compatibility with 
> existing 1.1 applications that implemented the trap defs 
> using the original docs-if ext mib. With the deprecated 
> objects removed, it is possible that these pre-rf mib v2 
> draft 1.1 applications may not be compatible with the new trap defs. 
> 
> 3) The event mib is not in sync with the MTA event mgmt mib.
> It is not really fair to compare them. The MTA event mgmt mib 
> uses a generic definition for all informs and traps 
> pertaining to MTA events. The Docsis event mib creates 
> individual trap defs for each event. It may be a nice idea to 
> add inform defs in the Docsis event mib though. 
> 
> Again, sorry for not commenting on mib guidelines, etc.
> 
> Regards,
> Dave 
> 
> 
> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: Thursday, April 08, 2004 1:05 PM 
> To: Raftus, David 
> Cc: Richard Woundy @ Comcast 
> Subject: RE: [ipcdn] wg review of 
> draft-ietf-ipcdn-docsisevent-mib-03.txt 
> 
> Dave,
> 
> Thanks a lot.
> For your review, please consider the following: 
>   - compliance with mib guidelines check-list 
>   - conformance with ID-nits, 
>   - is this MIB in sync with the other ipcdn ID on event mgmt 
> for MTAs: 
>    
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-event
> mess-03.txt 
>   - etc. 
> 
> Also, please send your comments to the ipcdn list.
> thx, 
> jean-francois. 

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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 15 May 2004 10:07:30 -0700

Hi -

> From: "Nakanishi Greg-MGI8179" <[email-masked]>
> To: "'Eduardo Cardona'" <[email-masked]>; "Raftus, David" <[email-masked]>; "Ipcdn List (E-mail)"
<[email-masked]>
> Sent: Friday, May 14, 2004 2:52 PM
...
> Let's wait to hear what the MIB doctors say about the object name.
> I'm OK with changing the name, if that's the recommendation.
...

I agree that there don't seem to be any advantages to retaining the old name.

Current practice strongly favors referring to these things as
notifications.  Not only can RFC 3413 dynamically control whether
these things show up on the wire as informs or traps, but there's
also the possibility that they may end up being logged (locally or
remotely) using, for example, RFC 3014.

Randy