[01:28:58] --- jean-francois has joined
[01:37:57] <jean-francois> it's 9:01 local time and there are 3 people in the room
[01:38:01] <jean-francois> waiting for more
[01:38:55] <jean-francois> Bert arrived in the meeting room
[01:39:03] --- rwoundy has joined
[01:39:36] <jean-francois> good morning Rich
[01:39:41] <rwoundy> good morning
[01:39:49] <jean-francois> early wake up call?
[01:40:00] <rwoundy> yes it is (3:03am)
[01:40:33] <jean-francois> thanks for joining
[01:40:45] <rwoundy> i also have the audio on, <http://videolab.uoregon.edu/events/ietf/ietf63.html>
[01:41:29] <jean-francois> the meeting agenda is at
[01:41:30] <jean-francois> http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01663.html
[01:42:23] <rwoundy> got it
[01:42:30] <rwoundy> make sure u speak into the microphone
[01:43:14] --- bert has joined
[01:43:21] <bert> hi rich!
[01:43:26] <rwoundy> good morning!
[01:45:45] <jean-francois> we now have about 8 people
[01:49:25] <bert> Rich, could you hear me better now
[01:50:12] <rwoundy> wow it's really hard to hear
[01:51:36] <jean-francois> discussing the wg milestones
[01:51:41] <rwoundy> ok
[01:52:08] <rwoundy> can't hear bert at all
[01:52:11] <jean-francois> for ipcdn mibs, we (the qg chairs) propose October 2005 for the 2 DOCSIS mibs
[01:52:21] <rwoundy> yes
[01:52:29] <rwoundy> now i hear bert
[01:52:29] <jean-francois> and the 2 first PacketCable Ipcablecom mibs (October 2005) as well
[01:52:46] <jean-francois> then the last packetcable mib (event mgmt mib) dec 2005
[01:52:49] <rwoundy> ok, that might be aggressive, esp. ncs signaling
[01:53:35] <rwoundy> also waiting for rfi mib?
[01:54:42] <jean-francois> yes Bert has it on his plate
[01:54:45] <jean-francois> anything else?
[01:54:49] <jean-francois> from you Rich?
[01:55:03] <jean-francois> we are done with
[01:55:04] <jean-francois> II. Administration
[01:55:10] <jean-francois> moving to III. IPCDN DOCSIS mibs
[01:55:12] <rwoundy> no, randy is reviewing my mib,
[01:56:57] <jean-francois> that is what i said
[01:57:16] <rwoundy> we can review the top four issues
[01:57:25] <rwoundy> <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html>
[01:57:27] <jean-francois> ok
[01:57:54] <rwoundy> hi randy
[01:59:42] <jean-francois> what open issue would you kike to discuss on NmaccessInterface
[01:59:42] <rwoundy> the first issue
[01:59:54] <rwoundy> i think we have the right defval
[02:00:17] <rwoundy> the hard part is to describe 'non-existent' interfaces
[02:00:31] <rwoundy> we want enuf clarity for implementors
[02:00:47] <rwoundy> but don't want to kill ourselves for a deprecated object
[02:03:51] <rwoundy> (as long as we have time to discuss them, :27 into the mtg)
[02:05:26] <jean-francois> Randy comments on issue #1, defval for docsDevNmAccessInterfaces
[02:05:47] <jean-francois> bert added
[02:05:53] <jean-francois> could we delete the DEFVAL?
[02:06:08] <rwoundy> i guess we could delete the defval
[02:06:26] <rwoundy> i think we added due to prior mib dr comment
[02:06:34] <rwoundy> but i see this is problematic
[02:06:55] <rwoundy> b/c there was an implicit (commented out) defval before, right?
[02:07:14] <rwoundy> i have no problem getting rid of the defval, tho
[02:07:54] <jean-francois> Based on discussion, the proposal is to
[02:07:57] <jean-francois> DELETE the defval
[02:08:02] <jean-francois> and text to DESCRIPTION
[02:08:37] <jean-francois> bits set corresponding to non-existing interfaces is implementation specific
[02:08:49] <rwoundy> ok, sounds very reasonable
[02:09:22] <rwoundy> what tables should be persistent
[02:09:28] <jean-francois> good - recorded in the notes
[02:09:29] <rwoundy> that is issue #2
[02:09:31] <jean-francois> re: docsDevNmAccessStatus
[02:11:44] <rwoundy> yes #2 and #4 are very much related
[02:11:56] <rwoundy> my assumption is that most docsis tables are transient
[02:12:23] <jean-francois> what is the issue there?
[02:12:59] <rwoundy> wording in several Table objects saysing "Table entries MAY persist across reboots..."
[02:13:00] <jean-francois> for all the tables MUST NOT persit except for docsDevEvControlTable rich commented that only those with local reporting should persist
[02:13:27] <rwoundy> i don't think that was ever supposed to be the intent
[02:13:41] <jean-francois> so is it your understanding ?
[02:13:54] <rwoundy> exactly, the config file is supposed to drive entries into those other (non-event) tables
[02:14:10] <rwoundy> please repeat
[02:14:48] <bert> but we speak about read-create tables here, so what if anyone creates an entry?
[02:15:11] <jean-francois> the proposal is
[02:15:19] <rwoundy> yes, kevin added text
[02:15:31] <rwoundy> i think the intent is that more rows can be added to those tables
[02:15:38] <jean-francois> in docsDevEvControlTable, clarify that rows with local reporting should persist
[02:15:48] <rwoundy> but those tables clear out when the cable modem is rebooted
[02:15:56] <bert> and what happens to those rows after reboot?
[02:16:25] <rwoundy> other than docsDevEvControlTable, i think they disappear -- at least on cable modems
[02:16:54] <rwoundy> that way, they can be moved from one cable operator to another with predictable behavior
[02:17:06] <rwoundy> i.e. without "hidden config"
[02:17:18] <jean-francois> is it true that there is no persistence per se
[02:17:46] <jean-francois> CM clears them in reboot and recreates them after reading the CM config file
[02:18:14] <rwoundy> yes, that has always been my understanding
[02:18:26] <rwoundy> want to ensure that is the "common" understanding as well :)
[02:18:37] <jean-francois> ok
[02:19:10] <rwoundy> that is my understanding as well
[02:19:48] <jean-francois> re:
[02:19:49] <jean-francois> docsDevFilterLLCTable
[02:19:50] <rwoundy> initial entries in those tables
[02:19:58] <jean-francois> moving to docsDevFilterLLCTable
[02:20:00] <rwoundy> emphasis on "initial" entries
[02:20:04] <jean-francois> (issue #3 in the email from 7/24
[02:20:19] <rwoundy> i agree with randy's comment
[02:20:27] <rwoundy> re: local(0) rows MUST persist
[02:20:55] <jean-francois> so no additional comments to resolve #3?
[02:21:19] <rwoundy> i think that is it
[02:21:46] <rwoundy> want to make sure randy understands this object
[02:23:02] <rwoundy> which table?
[02:23:29] <jean-francois> sorry my bad
[02:23:30] <jean-francois> docsDevEvReporting
[02:24:05] <rwoundy> the rows (local(0)) are persistent
[02:24:27] <rwoundy> the value of this particular object (Reporting) is not persistent
[02:24:31] <jean-francois> are you ok with deleting the last sentence of that DESCRIPTION
[02:24:35] <jean-francois> Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated.
[02:24:47] <jean-francois> -- IF -- there is actually no dependency
[02:25:08] <rwoundy> good question, b/c i don't remember the genesis of that paragraph
[02:25:27] <rwoundy> okay, let's just delete it, doesn't add much value
[02:26:19] <rwoundy> should the persistence be captured in the Table object, or in the compliance statement???
[02:26:28] <jean-francois> re: docsDevFilterLLCTable
[02:26:32] <rwoundy> yes
[02:26:52] <rwoundy> i think we want persistance defined for the cable modem
[02:27:02] <rwoundy> (not persisting across reboots)
[02:27:08] <rwoundy> i'm not sure about CMTSs
[02:27:13] <jean-francois> the mib review guidelines would do it in the table or the entry object
[02:27:19] <rwoundy> ok
[02:27:21] <jean-francois> (Randy and Bert stated)
[02:27:26] <rwoundy> that's afir
[02:27:28] <rwoundy> fair
[02:27:37] <jean-francois> (what object is this question for ?)
[02:27:44] <rwoundy> e.g. LLCTable
[02:27:51] <jean-francois> ok, just wanted to make sure
[02:28:39] <rwoundy> is randy asking about "Any attempt to SET the traps(1) or syslog(2) bits..." for #3?
[02:29:42] <rwoundy> i think that sentence may be overspecification
[02:29:43] <jean-francois> Randy added for consideration: where you have this must not persist langage, sya they may come back as entriues may reappear when CM reboots and comes up with config file entries
[02:29:54] <rwoundy> reading...
[02:30:29] <rwoundy> not sure i understand the comment???
[02:31:06] <jean-francois> if that is too many little edits, in the main body of the document, add a note on persistence model explaining the persistance of some mib objects and the CM re-creating them upon config file reloading
[02:31:29] <rwoundy> ok
[02:32:45] <rwoundy> i was less concerned about all the edits, and wanted to be sure i had the same persistance models as the WG
[02:33:03] <jean-francois> Rich - any other comments on cd mib?
[02:33:14] <rwoundy> only asked about compliance statements b/c we have CM vs. CMTS compliances
[02:33:43] <rwoundy> i think those are the big issues
[02:33:53] <jean-francois> what the question?
[02:33:58] <jean-francois> what's the question?
[02:34:08] <rwoundy> randy had two-three other comments, i'll take them to the list, they are much simpler
[02:34:14] <rwoundy> bert's review!
[02:34:20] <jean-francois> ok
[02:35:03] <rwoundy> didn't hear randy's last comment
[02:35:27] <jean-francois> no issue from Randy
[02:35:33] <jean-francois> that is Bert talking
[02:35:41] <jean-francois> the last comment Randy made was about the persistence note
[02:36:02] <rwoundy> ok, so is there any more advice for me on this mib?
[02:36:06] <jean-francois> are you ok with Bert's comment on the mike re:
[02:36:18] <jean-francois> CM vs. CMTS compliance statement
[02:36:26] <rwoundy> didn't hear it
[02:36:40] <jean-francois> if different requirements for CM vs. CMTS, suggestion is to make 2 different compliances rather than
[02:36:51] <jean-francois> having optional statements in each of the compliance group statements
[02:37:05] <rwoundy> not to worry, we HAVE two separate compliance statements already
[02:37:11] <bert> good!
[02:37:19] <rwoundy> the old compliance statement was not like that
[02:37:33] <rwoundy> the two new compliances are split between CM/CMTS
[02:37:56] <rwoundy> i appreciate the time on this mib, thanks!!!
[02:38:31] <rwoundy> i'll take the rest to the list
[02:38:45] <rwoundy> i think i know what i need to do
[02:39:34] <rwoundy> i'm all done
[02:40:01] <rwoundy> let's get to rf mibv2
[02:43:34] <jean-francois> any final comments from you Rich?
[02:43:39] <rwoundy> we have docsDevCmCompliance and docsDevCmtsCompliance in the CD mib right now
[02:43:46] <jean-francois> ok
[02:43:46] <rwoundy> no further comment
[02:43:52] <jean-francois> great, we are done
[02:44:00] <jean-francois> thx for being online Rich, appreciate it
[02:44:07] <rwoundy> (sorry about hogging the time :))
[02:44:11] <jean-francois> np
[02:44:16] <jean-francois> glad you were with us
[02:44:18] <jean-francois> ok ttyl
[02:44:21] <jean-francois> gn
[02:44:27] --- jean-francois has left
[02:44:44] --- rwoundy has left
[02:49:01] --- rwoundy has joined
[02:49:06] <rwoundy> no comment
[02:49:08] --- bert has left
[02:49:18] --- rwoundy has left