FW: IPCDN Digest, Vol 16, Issue 2
Freyman Phillip-FPF300 <[email protected]> Fri, 2 Sep 2005 08:17:22 -0500
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <370596D46C9BD711B61A00065BF365881A9E1A90@il06exm12> |
Eugene, Thank you for reviewing the ETSI requirement. I agree on your revised proposal for the range to be 20 ms to 1550 ms so that the SigMIB can cover international requirements but with the default values set per Telcordia. Regards, Phillip Freyman -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, September 01, 2005 11:17 PM To: [email protected] Subject: IPCDN Digest, Vol 16, Issue 2 Send IPCDN mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ipcdn or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of IPCDN digest..." Today's Topics: 1. RE: cable dev mib draft09 - WG consensus requested on pro posed changes (Nakanishi Greg-MGI8179) 2. RE: FW: IPCDN Digest, Vol 15, Issue 16 (Eugene Nechamkin) ---------------------------------------------------------------------- Message: 1 Date: Thu, 1 Sep 2005 09:44:14 -0700 From: Nakanishi Greg-MGI8179 <[email protected]> Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on pro posed changes To: Jean-Francois Mule <[email protected]>, [email protected] Message-ID: <D5A7E45D575DD61180130002A5DB377C145AA158@ca25exm01> Content-Type: text/plain; charset="iso-8859-1" I concur with the proposed resolution. For Issue 4, my preference is that 'MUST NOT' be used, rather than 'SHOULD NOT'. I think a device will run into operational problems if it maintains these table entries across reboots. When the device reboots, the config log will attempt to create rows in these tables and will fail if the rows already exists. greg _____ From: [email protected] [mailto:[email protected]] On Behalf Of Jean-Francois Mule Sent: Monday, August 15, 2005 3:20 PM To: [email protected] Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes Folks, As you may have read in meeting notes from last week, we spent the IETF 63 meeting discussing the closure of open issues on the CD mib v2. The meeting notes proposed some changes to get final (yes, final) closure on this mib. Please review the text below and please speak up if you have some concerns (it's also welcome that you express your agreement). Thanks, Jean-François [extract from ipcdn minutes] 3.1/ DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt> We spent most of the meeting reviewing the 4 top remaining issues, see summary sent by Rich and Kevin in: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html> + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces Raised by Randy, the issue is, in the defval we have a 4 octet value => How can systems with interfaces in a number not multiple of 8 interpret the DEFVAL value. Are bits ignored? Randy commented that he would be ok if there was some mention like 'octets containing bits corresponding to non-existent interfaces are ignored.' That said, if there are implementations that would reject a SET, then we need to say something about that. Rich commented that the DEFVAL was added due to prior MIB doctor comment and that the object is now deprecated. Bert asked whether there was any concern deleting the DEFVAL. Proposal for wg review: a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h } b) consider the following (NICE TO HAVE kind of fix) adding a sentence to say something like: bits set corresponding to non-existing interfaces is implementation specific (to warn the mgmt admin/apps that no assumptions should be made on existing implementations of this object. (Randy's suggestion) + ISSUE #2: docsDevNmAccessStatus -- Also, we should change the DESCRIPTION of docsDevCpeStatus -- and docsDevCpeInetRowStatus to document how the agent adds rows. See issue raised by Randy and the email summary provided by Rich for the context around this issue #2. We had some discussions around the persistency of those tables, the fact that the CM config file drives the row creation at boot-up and the fact that they are read-create tables so admins can also create entries as Bert pointed out. In most cases (except for docsDevEvControlTable), entries do not persist across CM reboots. Even in the case of docsDevEvControlTable, after some discussion, we believe that the entries are cleared and "recreated" after the CM reads the config file. That is the common understanding. Bert said: add a statement ("this is a deprecated table, this is vendor specific as to what vendors do with this table, mgmt app cannot expect a certain behavior"). + ISSUE #3: docsDevEvReporting and local(0) rows Comment close: ID authors agree with Randy's comment re: local(0) rows MUST persist. Text will be revised. in docsDevFilterLLCTable: 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. Proposal: DELETE above text if nobody complains after reading the meeting notes + ISSUE #4: docsDevFilterLLCTable Issue is around text for the level of requirements on table persistence. Agree with Rich's text proposal: |"Table entries MUST NOT persist across reboots for cable modems." Rich also proposed to apply this requirement to: NmAccess, FilterLLC, FilterIp, Policy, Tos, Cpe and InetCpe tables. It was suggested to use SHOULD NOT rather than MUST NOT but other than that, proposal is ok. + Other items on CD Device MIB: Randy added for consideration: wherever we have this "must not persist" langage in table definitions, it would be a plus to indicate that they may come back as entries may reappear when CM reboots and comes up with config file. Or consider adding this in the front paper as a consideration for users of the MIBs if that is too many little edits in the MIB objects. Proposal: add a note on persistence model explaining the persistance of some mib objects and the CM re-creating them upon config file reloading. A comment was made that in general, we should indicate the persistency model in each object rather than in the compliance section. Bert also commented on the compliance sections: if different requirements apply to CM and CMTS, suggestion is to make 2 different compliances. Rich added that the new compliance statement is designed like that. # AI: [authors: Kevin Marez & Rich Woundy] # Authors to summarize list of agreed changed and the technical # changes in the text per wg consensus and issue new draft after AD # review comments are in. # Due by early September? # AD review by Bert due by August 15 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/ipcdn/attachments/20050901/711d24ed/attachment.htm ------------------------------ Message: 2 Date: Thu, 1 Sep 2005 21:00:36 -0700 From: "Eugene Nechamkin" <[email protected]> Subject: RE: [ipcdn] FW: IPCDN Digest, Vol 15, Issue 16 To: [email protected] Message-ID: <24CDBA67F085904999751B3C4F9E8C0B031230FB@NT-RMNA-0740.brcm.ad.broadcom.com> Content-Type: text/plain; charset=iso-8859-1 Phil, I agree with your approach to modify two objects - Min and Max with the following comment: ETSI EN 300 001 V1.5.1 spec defines the break period (which is an equivalent for flash) as being as low as 50ms (Table 9.1.1). As a reality check - we have seen some European requests for having the flash range starting from 50-100ms. Hence, I would think that the lower range of 20 msec for both objects would have a better chance to meet the various requirements in the field. The following objects definitons seem to be satisfactory from our prospective: pktcNcsEndPntConfigMinHookFlash OBJECT-TYPE SYNTAX Unsigned32 (20..1550) ..... DEFVAL (300) pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE SYNTAX Unsigned32 (20..1550) ..... DEFVAL (1100) Eugene. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Freyman Phillip-FPF300 Sent: Thursday, September 01, 2005 7:14 AM To: '[email protected]' Subject: [ipcdn] FW: IPCDN Digest, Vol 15, Issue 16 Eugene, Thank you for reviewing the GR 506 document however, I do not fully agree with your proposal. Per your email, GR 506 states: Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds) SPCS Interpretation < 200 Hit 200 to 300 Hit or Flash 300 to 1100 Flash 1100 to 1550 Flash or Disconnect >1550 Disconnect This implies that the network MUST accept 300 to 1100 milliseconds as hook flash and must NOT accept less than 200 ms or more than 1550 ms. The ranges of 200 to 300 and 1100 to 1550 are ranges where the network may accept or may reject the timing. I do agree that some changes may be appropriate in the ranges of min/max values.. I do not agree with your proposed max default value and propose the following to bring the SigMIB into alignment with GR 506. Current rev8 text: pktcNcsEndPntConfigMinHookFlash OBJECT-TYPE SYNTAX Unsigned32 (20..1000) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the minimum time a line needs to be on hook for a valid hook flash. The value of this object MUST be greater than the value of pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of pktcNcsEndPntConfigMinHookFlash MUST be less than pktcNcsEndPntConfigMaxHookFlash. This object MUST only be set via the configuration file during the provisioning process. Furthermore, given the possibility for the 'pulse dial' and 'hook flash' to overlap, the value of this object MUST be greater than the value contained by the MIB Object pktcNcsEndPntConfigPulseDialMaxMakeTime." DEFVAL { 300 } ::= { pktcNcsEndPntConfigEntry 32 } pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE SYNTAX Unsigned32 (20..1000) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the maximum time a line needs to be on hook for a valid hook flash. The value of pktcNcsEndPntConfigMaxHookFlash MUST be greater than pktcNcsEndPntConfigMinHookFlash. This object MUST only be set via the configuration file during the provisioning process." DEFVAL { 800 } ::= { pktcNcsEndPntConfigEntry 33 } Proposed rev8 text change: pktcNcsEndPntConfigMinHookFlash OBJECT-TYPE SYNTAX Unsigned32 (200..1550) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the minimum time a line needs to be on hook for a valid hook flash. The value of this object MUST be greater than the value of pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of pktcNcsEndPntConfigMinHookFlash MUST be less than pktcNcsEndPntConfigMaxHookFlash. This object MUST only be set via the configuration file during the provisioning process. Furthermore, given the possibility for the 'pulse dial' and 'hook flash' to overlap, the value of this object MUST be greater than the value contained by the MIB Object pktcNcsEndPntConfigPulseDialMaxMakeTime." DEFVAL { 300 } ::= { pktcNcsEndPntConfigEntry 32 } pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE SYNTAX Unsigned32 (200..1500) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the maximum time a line needs to be on hook for a valid hook flash. The value of pktcNcsEndPntConfigMaxHookFlash MUST be greater than pktcNcsEndPntConfigMinHookFlash. This object MUST only be set via the configuration file during the provisioning process." DEFVAL { 1100 } ::= { pktcNcsEndPntConfigEntry 33 } Regards, Phil -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, August 31, 2005 11:08 AM To: [email protected] Subject: IPCDN Digest, Vol 15, Issue 16 Send IPCDN mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ipcdn or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of IPCDN digest..." Today's Topics: 1. RE: draft-ipcdn-pktc-signaling-08, further changes;result of conference call (Eugene Nechamkin) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Aug 2005 18:44:56 -0700 From: "Eugene Nechamkin" <[email protected]> Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of conference call To: "Sumanth Channabasappa" <[email protected]> Cc: [email protected] Message-ID: <24CDBA67F085904999751B3C4F9E8C0B031230A3@NT-RMNA-0740.brcm.ad.broadcom.com> Content-Type: text/plain; charset=iso-8859-1 Sumanth, Looking further at the Bellcore specs for pulse flash requirements (GR-506-CORE "LSSGR: Signaling for Analog Interfaces"), it turnes out that the requirements for the pulse range for flash are higher than it is currently allowed by the "pktcNcsEndPntConfigMaxHookFlash" MIB Object. Bellcore specs say that flash MUST be 300-1100, but may be up to 1550: Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds) SPCS Interpretation < 200 Hit 200 to 300 Hit or Flash 300 to 1100 Flash 1100 to 1550 Flash or Disconnect >1550 Disconnect To better meet the Bellcore specs requirements, the following modification of the MIB Object's range is proposed: pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE SYNTAX Unsigned32 (20..1550) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the maximum time a line needs to be on hook for a valid hook flash. The value of pktcNcsEndPntConfigMaxHookFlash MUST be greater than pktcNcsEndPntConfigMinHookFlash. This object MUST only be set via the configuration file during the provisioning process." DEFVAL { 800 } ::= { pktcNcsEndPntConfigEntry 33 } . -----Original Message----- From: Sumanth Channabasappa [mailto:[email protected]] Sent: Friday, August 26, 2005 7:24 AM To: Jean-Francois Mule Cc: [email protected]; Freyman Phillip-FPF300; Eugene Nechamkin; David De Reu; T, Shivakumar; [email protected]; Satish Kumar at Texas Instruments; Beacham Gordon-CGB005 Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of conference call Jean-Francois, I concur. Unless there are objections, I will be presenting the final proposal to this group in the next week. Regards Sumanth -----Original Message----- From: Jean-Francois Mule Sent: Friday, August 26, 2005 7:18 AM To: Sumanth Channabasappa Cc: [email protected]; 'Freyman Phillip-FPF300'; 'Eugene Nechamkin'; 'David De Reu'; 'T, Shivakumar'; '[email protected]'; Satish Kumar at Texas Instruments; 'Beacham Gordon-CGB005' Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of conference call Sumanth, Thanks for inviting anyone from IETF ipcdn to attend the discussion and for the notes. We have not seen one comment on your posting in 15 days so the proposal should be good enough. Per the IETF#63 meeting, the action item on the signaling MIB was: # AI: authors to close one open issue on tone table by August 20. # Ask Randy to review final proposal. Can you put out the proposed changes in the form of updated object definitions to the list so we can see all the aggregated changes? Based on our discussions, we are getting close to the end on this one and I would like to set the date of next Friday, September 2nd to have a consensus on the technical changes to allow a draft09 publication by mid-September at the latest. Thanks, Jean-François > -----Original Message----- > From: Sumanth Channabasappa > Sent: Wednesday, August 10, 2005 10:09 AM > To: [email protected] > Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result > of conference call > > Folks, > > As per the discussion on the conference call today (thanks to the > attendees), the proposal from Phil seems to be reasonable. > > Further, there was a suggestion to include the following examples in > the draft for clarity and ease of implementation. Note: Example B was > also the cause for the latest suggestion. > > > Example A: Call waiting tone defined per ITU-T E.180: > 1) 400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm > 2) 400 Hz AM modulated by 16 Hz, off for 400ms > 3) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 4) 400 Hz not AM modulated, off for 450 ms > 5) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 6) 400 Hz not AM modulated, off for 3450 ms > 7) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 8) 400 Hz not AM modulated, off for 450 ms > 9) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 10) 400 Hz not AM modulated, off for 3450 ms > 11) not repeated, not continuous > > Assume userDefined1(17) is assigned to this tone: > > ToneType|Freq-1|Freq-2|Freq-3|Freq- > 4|FreqMode|ModePrtg|DbLevel|OnDur|Off > Dur|Rep-Count > ====================================================================== > == > ============= > 17 400 16 0 0 1 90 -40 500 > 400 0 > 17 400 0 0 0 2 0 -40 50 > 450 0 > 17 400 0 0 0 2 0 -40 50 > 3450 0 > 17 400 0 0 0 2 0 -40 50 > 450 0 > 17 400 0 0 0 2 0 -40 50 > 3450 0 > > > pktcSigDevToneTable: > ToneType|ToneRep-Count|Steady > ================================ > 17 0 false(2) > > > ---------------------------------------------------------------------- > -- > --------------- > > Example B - Congestion Tone - congestion(17): > > This example of an embedded cadence is based on an operator variation. > 1) 400Hz on for 400ms -10 dBm > 2) 400Hz off for 350ms > 3) 400Hz on for 225ms -4 dBm > 4) 400Hz off for 525ms > 5) repeat (1) through (4) 5000 times or T0 timeout (which ever is > shortest period) > > ToneType|Freq-1|Freq-2|Freq-3|Freq- > 4|FreqMode|ModePrtg|DbLevel|OnDur|Off > Dur|Rep-Count > ====================================================================== > == > ============= > 17 400 0 0 0 2 0 -100 400 > 350 0 > 17 400 0 0 0 2 0 -40 225 > 525 0 > > > pktcSigDevToneTable: > ToneType|ToneRep-Count|Steady > ================================= > 17 5000 false(0) > > > Please feel free to provide any comments. > > Regards > Sumanth > > -----Original Message----- > From: Sumanth Channabasappa > Sent: Tuesday, August 09, 2005 2:37 PM > To: '[email protected]' > Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; > conference call > > Folks, > > There has been a suggestion (from Phillip Freyman, Motorola) to move > the 'dBm level', currently under 'PktcSigDevToneTable' to > 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that > require this structure. > > > > _______________________________________________ > IPCDN mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ipcdn ------------------------------ _______________________________________________ IPCDN mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipcdn End of IPCDN Digest, Vol 15, Issue 16 ************************************* _______________________________________________ IPCDN mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipcdn ------------------------------ _______________________________________________ IPCDN mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipcdn End of IPCDN Digest, Vol 16, Issue 2 ************************************