Page 1 IPCDN Working Group IETF 62 - IPCDN WG Update Richard Woundy Jean-François Mulé IETF IPCDN Co-Chairs Tuesday March 8, 2005 [email protected]

IPCDN Working GroupPage 1

IETF 62 - IPCDN WG Update

Richard Woundy

Jean-François Mulé

IETF IPCDN Co-Chairs

Tuesday March 8, 2005

[email protected]

[email protected]


Meeting Agenda

• Agenda Bashing• Administration• IPCDN DOCSIS MIB Updates

– DOCSIS Cable Device MIB v2 draft 07– DOCSIS RFI MIB draft 13– Notes on last DOCSIS BPI+ draft 15 update (fyi only)

• IPCablecom/PacketCable MIB Updates– Signaling MIB draft 08– MTA MIB draft 06– Management Event MIB draft04

• CableHome MIB Modules Withdrawal• Next Steps


Note Well & Intro

• Registration included materials referring to RFC 3667 and RFC 3668

• As usual, this IPCDN WG meeting and all IETF contributions are subject to the rules of RFC 3667 and RFC 3668

• Call for:– WG meeting notes takers– Jabber chat room volunteer(s)

[email protected]

• Blue sheets

These slides can be downloaded at:http://www.ipcdn.org/meetings.html


Administration

• IPCDN WG Charter and Updated Milestones – WG Milestones

http://www.ietf.org/html.charters/ipcdn-charter.html– WG milestones completed

» DOCSIS Subscriber Management – RFC Ed Queue» DOCSIS BPI+ MIB» DOCSIS QoS MIB

– Almost completed» DOCSIS Event Notification MIB» DOCSIS RFIv2 MIB

• WG Milestones review– Sept 2004

» Update milestone for DOCSIS Cable Device MIB v2 to June 2005?» Update milestones for PacketCable MIBs to June 2005?

• WG items to be abandoned– All CableHome MIB modules

• Any comments on charter update from WG?


IPCDN DOCSIS MIB Updates


IPCDN DOCSIS MIBs

• QoS MIB– Draft 12 released in Feb 2005, addressed all IESG comments

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-12.txt

– Status: done - in RFC Ed queue

• BPI+– Draft 15 released in Nov 2004– http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-15.txt

– Status: done - in RFC Ed queue

• Event Notification– Draft 04 considered “done” as far as WG is concerned

– Draft 06 released in Jan 2005 to address comments from AD review

– http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-06txt

– Status: AD Follow-up, need to ping Bert when he returns


IPCDN DOCSIS Cable Device MIB v2draft-ietf-ipcdn-device-mibv2-07

Kevin Marez, [email protected]

February 21 2005


Cable Device MIB – draft-07

• Submitted on February 18 2005– draft-ietf-ipcdn-device-mibv2-draft-07.txt

• New Author– Kevin Marez, Motorola

• Changes– Closed issues– Open issues– No Change– Complete enumerated listing of modifications at

http://www.ipcdn.org/meetings/cdmib-07-changes.docorhttp://tools.ietf.org/wg/ipcdn/

andhttp://tools.ietf.org/wg/ipcdn/draft-ietf-ipcdn-device-mibv2/draft-ietf-ipcdn-device-mibv2-07-from-06.diff.html


Closed Issues

• References – updated and included new references• Security Considerations – addressed a number of issues

regarding read-write and read-create objects not being mentioned.

• Persistency of values – Clarification of some objects that did not specify persistency across reboots

• Acronyms – expanded multiple acronyms on first usage• Added IMPORT entries for DiffServ• Error cases – included some error cases that were

ambiguous in some Descriptions• Formatting – a number of issues were addressing

regarding sections and formatting• Structure – added DEFVAL and UNITs clauses to multiple

objects• Added IANA Considerations section


Open Issues (1)

• Issue: Multiple entries in the docsDevGroups are deprecated– ex: docsDevNmAccessGroup, docsDevSoftwareGroup,

etc

• Replaced by docsDevGroupsV2• smilint produces multiple warnings• Resolution: Unknown


Open Issues (2)

• Issue: docsDevEvReporting – Description doesn’t mesh with RFC3413 guidelines

• RFC3413 defines the rules for notifications (when and how)• RFC3014 defines the logging mechanism• Resolution: Statement of conformance to RFC3413 and

RFC3014 in the description?• Do we need to specify differences for SNMPv1/2c vs.

SNMPv3?


Open Issues (3)

• Issue: Relationship needs to be defined between docsDevEventGroup, docsDevEventGroupv2 and RFC3014

• Resolution: Unknown


Open Issues (4)

• Issue: docsDevFilterPolicyObsoleteGroup – what is the purpose of this group?

• Since the objects have been obsoleted, is there a reason to have a separate group calling them out?

• Resolution: Remove the group entirely


No Changes

• SYNTAX clauses – multiple SYNTAX clauses were suggested to be changed, but were not due to backward-compatibility with RFC2669


Cable Device MIB – draft-07

• Comments/Feedback– IPCDN WG Reflector: [email protected]– [email protected]

• Special Thanks– Randy Presuhn for providing continuous feedback


IPCDN DOCSIS RFI MIB v2draft-ietf-ipcdn-docs-rfmibv2-13

Eduardo Cardona, [email protected]

February 22 2005


RFIv2 MIB Draft Status

• Draft 11 considered “done” from WG prospective– Published in July 2004

– Address WGLC comments (StorageType object in docsIfCmtsModulationTable )

– AD Review started with draft 12, current status:AD Evaluation::AD follow up

• Comments received from Bert Wijnen and Randy Presuhn

• List of Changes in draft 13– Next Slides provide details on pending technical comments that are awaiting

resolution (13)» Items 1-4 quick resolution» Items 5-10 Proposed to leave as in ID-12/13» Items 11-13 not in ID-13 but intended to submit as ID-14

– Technical comments Incorporated ID-13 (many)

– Few Administrative comments addressed

• Next steps– Validate Pending comments and final resolution

– Validate Incorporated Comments in ID-13

– Submit ID-14


RFIv2 MIB Technical Comments, pending

1. Clone mechanism – docsIfUpChannelCloneFrom, docsIfUpChannelUpdate and docsIfUpChannelStatus– Comment: Still objections in how that works (?)– Procedure in place in draft 05, refined and Group agreed with text in ID-10

2. docsIfCmtsCmStatusEqualizationData– Comment: Justification of OCTET STRING (SIZE(0..512))– In DOCSIS 1.x (RFC 2670) was left quite open for vendors implementation (no OCTET STRING

constrains). – DOCSIS 2.0 has more deterministic size. Leave as DOCSIS 1.x? (no constrains). Note All

second generation DOCSIS 1.1 supports RFIv2 MIB ID-05 (no constrains)

3. docsIfCmtsCmStatusValueRemoved in ID-13 enumeration value 8Added:“Value 8 is considered reserved and should not be defined in future revisions of this MIB

module to avoid conflict with documented implementations that support value 8”Valid solution ?

4. docsIfCmStatusCode – IDs 6-to-12 were SYNTAX OCTET STRING (SIZE (0..16)), – Comment: Size constrain does not match description– ID-13 is back to RFC 2670 SYNTAX OCTET STRING,

Examples T02.1 or W035.4, Up to 6 characters but may be extended in the futureWhat should be the range? Plus indication of space for future enhancements.



5. docsIfQosProfMaxTransmitBurst– Comment: SYNTAX reads Integer32 (0..65535), instead o Unsigned32.

– Docsis 1.1 and 2.0 implementations supports Integer32 since ID-05,

– Proposed to leave as is

6. docsIfDownChannelPower– Comment: Removed Part of the description (compared to RFC2670)

– After RFC 2670 publication measurement of power level is mandatory for DOCSIS 1.0, 1.1 and 2.0, see ANSI/SCTE 22-3 2002, SP-OSSIv1.1-I07-030730 and SP-OSSIv2.0-I07-041210

– Removed from DESCRIPTION “May be set to zero at the CM if power level measurement is not supported.”

– Proposed to stay with text removed

7. docsIfQosProfileEntry – Comment: Need rewording

– Currently same as RFC 2670. Objects in docsIfQosProfileEntry were not deprecated to support DOCSIS 1.0 mode of operations compatibility. Funcitonality for DOCSIS 1.1 QOS mode of operation is in DOCS-IETF-QOS-MIB

– Proposed to leave as is.

8. docsIfCmStatusLostSyncs – Comment: Needs Units -> UNITS "LostSyncs“ ?

– Proposed leave without UNITS clause



9. docsIfCmtsCmStatusTimingOffset, docsIfUpChannelTxTimingOffset, – Comment: Needs Units

– Objects dimensions are 1/64 of DOCSIS ticks, (ticks = 6.15 usec or 64*1/10240000 Hz )

– UNITS clause value "SixtyFourthOfTicks“ ? DESCRIPTION CLAUSE already describes the units.


10. docsIfCmtsCmStatusHighResolutionTimingOffset– Comment: same as above (9)

– Units are 1/(64*256) of DOCSIS ticks "SixtyFourthOfTwoHundredFiftySixthOfTicks“?




11. DocsisUpstreamType and DocsisUpstreamTypeStatus TCs– Comment: Almost same TCs– Create compliance statement to indicate UpstreamType “minus tdmaAndAtdma” for

docsIfCmStatusModulationType

12. docsIfUpChannelScdmaActiveCodes6. Comment: exclude prime numbers from SYNTAX:

67,71,73,79,83,89,97,101,103,107,109,113,127Syntax will be :SYNTAX Unsigned32

(0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102|104..106|108|110..112|114..126|128)

13. docsIfSigQMicroreflections, docsIfCmtsCmStatusMicroreflections, docsIfSigQMicroreflections

Comment: Is valid to say “SHOULD”? ID-13 says “should” –lowercase-, moreover, “should” could be taken out.

“This object is not assumed to return an absolutely accurate value, but should gives a rough indication

of microreflections received on this interface.


RFIv2 MIB Draft Changes in ID-13 Technical.

• Affects both RFC 2670 defined objects and DOCSIS 2.0 additions.– Back to RFC 2670

» docsIfObsoleteGroup OBJECT-GROUP ::= { docsIfGroups 4 }

– docsIfCmtsModPreambleLen, docsIfCmtsModFECErrorCorrection» Extended ranges (new draft), old range included in RFC2670 compliances

– docsIfCmtsModType » old and new compliances added WRITE-SYNTAX

– docsIfCmtsQosProfilePermissions» Corrected Updated to lower case updateByManagement(1) , createByModems(2)

– docsIfCmtsQosProfilePermissions» Added WRITE-SYNTAX clause (excluded createByModems(2) ) in both new and old

compliances

– docsIfCmtsModControl (RowStatus) » Conditions of writing while a row is active moved from docsIfCmtsModulationEntry object.

– docsIfRangingResp, docsIfCmtsInsertionInterval» Indicated reason for obsolete objects

– Removed extra level of compliances and groups:» docsIfCompliancesV2 OBJECT IDENTIFIER ::= { docsIfConformance 3 }» docsIfGroupsV2 OBJECT IDENTIFIER ::= { docsIfConformance 4 }

– Removed, docsIfCmtsOptionalGroupV2 » ID updated to reflect latest DOCSIS requirements Objects in group are now mandatory



• ID abstract now says Obsoletes RFC 2670• docsIfUpstreamChannelEntry

» docsCableUpstreamInterface(129) fixed to docsCableUpstream(129)

– docsIfCmtsMacStorageType,docsIfDownChannelStorageType, docsIfQosProfStorageType, docsIfQosProfStorageType, docsIfCmtsModStorageType added:

– Entries with this object set to permanent(4) do not require write operations for read-write objects.

• docsIfCmStatusLostSyncs – Added discontinuity statement

• docsIfUpChannelModulationProfile, docsIfUpChannelUpdate– Reads error inconsistentValue instead of genErr

• docsIfUpChannelScdmaHoppingSeed added:– “Setting this value to a value different than zero for non-SCDMA channel types returns

error 'wrongValue‘.“

• Enhanced descriptions of DocsisVersion, DocsisQosVersion, • DocsisUpstreamType, and DocsisUpstreamTypeStatus*

– (*) See item 11 technical changes pending



• UNITS "ThenthdBmV"– docsIfCmtsCmStatusRxPower, docsIfCmStatusTxPower

• UNITS "TenthdB"– docsIfCmtsCmStatusSignalNoise, docsIfSigQSignalNoise

• UNITS "codewords" – docsIfCmtsCmStatus… Unerroreds, Correcteds, Uncorrectables, ExtUnerroreds,

ExtCorrecteds, ExtUncorrectables

• UNITS "messages"– docsIfCmtsStatusInvalidRangeReqs, docsIfCmtsStatusInvalidRegReqs,

docsIfCmtsStatusInvalidDataReqs, docsIfCmStatusInvalidUcds, docsIfCmStatusInvalidRegistrationResponses, docsIfCmStatusInvalidRangingResponses

• UNITS "attempts" – docsIfCmtsStatusRangingAborteds, docsIfCmtsStatusFailedRegReqs,

docsIfCmtsInvitedRangingAttempts, docsIfCmServiceTxRetries, docsIfCmServiceRqRetries, docsIfCmStatusRangingAborteds, docsIfCmStatusUCCs, docsIfCmStatusUCCFails

• UNITS "timeouts"– docsIfCmtsStatusT5Timeouts, docsIfCmStatusT1Timeouts,

docsIfCmStatusT2Timeouts, docsIfCmStatusT3Timeouts, docsIfCmStatusT4Timeouts



• UNITS "PDUs"– docsIfCmServiceTxExceededs, docsIfCmServiceRqExceededs

• UNITS "HundredOfSeconds"– docsIfCmtsInsertInterval, docsIfCmRangingTimeout

• UNITS "SIDs" – docsIfCmtsMaxServiceIds

• UNITS "maps" – docsIfCmStatusInvalidMaps

• UNITS "ticks" – docsIfUpChannelSlotSize

• UNITS "codesperMinislots" – docsIfUpChannelScdmaCodesPerSlot

• UNITS "spreadIntervals" – docsIfUpChannelScdmaFrameSize


RFIv2 MIB Draft Changes in ID-13 Admin.

• Draft moved to XML2RFC ver 1.28 DTD to handle automatically most of the NITS, and RTF document residual binary character inserts.

– ID-12 Checked with levkowetz NITS ver 1.58 and smilint.

– Added References for RFCs 2670, 3291

– IANA considerations,

– Fixed IPR Disclosure Acknowledgement

– Section 3.1.4.5 Reformatted to prevent “weird spacing” by automatic tools.


IPCDN DOCSIS BPI Plus MIBdraft-ietf-ipcdn-bpiplus-mib-14,15

Eduardo Cardona, Editor of drafts [email protected]

November 2004


(FYI) BPI+ MIB Draft Changes

Draft 15• Status RFC Queued:

– Rooted by IANA as OID 126, http://www.iana.org/assignments/smi-numbers

– Agreed text for security section on privacy and confidentiality weakness in the BPI+ MIB Module. (RFC-Editor note)

BPI+ Encryption Algorithms section: The BPI+ Traffic Encryption Keys (TEK) defined in the DOCSIS BPI+

specification [1] use 40-bit or 56-bit DES for encryption (DES CBC mode). There is currently no mechanism or algorithm defined for data integrity. Due to the DES cryptographic weaknesses, future revisions of the DOCSIS BPI+ specification should introduce more advanced encryption algorithms as proposed in the DocsBpkmDataEncryptAlg textual convention to overcome the progress in cheaper and faster hardware or software decryption tools. Future revisions of the DOCSIS BPI+ specification [1] should also adopt authentication algorithms as described in DocsBpkmDataAuthentAlg textual convention. It is important to note that frequent key changes do not necessarily help to mitigate or reduce the risks of a DES attack. Indeed, the traffic encryption keys which are configured on a per cable modem basis and per BPI+ multicast group can be utilized to decrypt old traffic even when they are no longer in active use. Note that not exempt of the same recommendations as above, the CM BPI+ authorization protocol uses triple DES encryption, which offers improved robustness compared to DES for CM authorization and TEK re-key management.


IPCDN IPCablecom/PacketCableMIB Updates


IPCDN MTA MIBdraft-ietf-ipcdn-pktc-mtamib-06

Eugene Nechamkin & Jean-François Mulé, [email protected] – [email protected]

January 25 2005


Status of MTA MIB draft 06• Draft 04 reviewed by MIB doctor Dave Thaler

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01325.html

• Drafts 05 and 06 address all MIB doctor comments• Main Technical Changes in Draft 06

– pktcMtaDevErrorOid table and entry objects:» Clarified what behavior of the agent is when max errors > 1024 per IETF #61 and list consensus» Defined new “TooManyErrorOID” in pktcMtaDevErrorsTooManyErrors to have a mechanism to indicated

that too many errors have been encountered without relying on human readable string (to allow internationalization and easier machine processing of such errors)

– Updated pktcMtaDevProvConfigKey description to be more specific on privacy algorithms

• Open issues in draft 06 raised by preliminary AD review– Objects pktcMtaDevProvUnsolicitedKeyMaxTimeout and

pktcMtaDevProvUnsolicitedKeyNomTimeout are read-only but descriptions invoke setting value

– pktcMtaDevProvKerbRealmName and pktcMtaDevRealmName syntax (also raised by Randy Presuhn) content MUST be uppercase ASCII => change syntax to DisplayString

– Value ranges for { pktcMtaDevRealmAvailSlot, pktcMtaDevRealmIndex} and {pktcMtaDevCmsAvailSlot , pktcMtaDevCmsIndex} are out of sync, is this a problem?

– pktcMtaNotifications object notification OID – pktcMtaBasicCompliance and pktcMtaBasicSmtaCompliance MODULE-COMPLIANCE: contain

object clauses with descriptions to only require ipv4 compliance but the object syntax is still loose => need to strengthen the syntax clauses to match what the description says

– For objects that refer to FQDNs, should we specify when such FQDNs are supposed to be resolved

• Next step: Update draft and complete AD review


IPCDN NCS Signaling MIBdraft-ietf-ipcdn-pktc-signaling-08

Sumanth Channabasappa, [email protected]

February 22 2005


NCS Signaling Draft Changes

• See list of changes in archive at:http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01594.html

• Technical changes

• The MIB table ‘pktcSigDevToneTable’ was reorganized into two different tables for better indexing, and enhanced to accommodate multiple frequencies for each tone

• Ref: pktcSigDevMultiFreqToneTable• New MIB Objects were added to support dynamic gain plan

negotiation, viz. pktcNcsEndPntConfigTxGain and pktcNcsEndPntConfigRxGain

• MIB descriptions and usage of the following MIB Objects were clarified based on comments received by the Working Group: 'pktcNcsEndPntConfigPartialDialTO, pktcNcsEndPntConfigCriticalDialTO, pktcRingCadence , pktcCodecType, pktcSigDevCodecTable

• MIB descriptions for the following MIB Objects were updated based on the comments received by the working group: ‘pktcNcsEndPntConfigTSMax’, ‘pktcNcsEndPntConfigTdinit‘,’ ‘pktcNcsEndPntConfigTdmin’, ‘pktcNcsEndPntConfigMinHookFlash’, ‘pktcNcsEndPntConfigPulseDialMaxMakeTime’, ‘pktcSigDevToneWholeToneRepeatCount’

• Other information

– A patent disclosure was brought to the attention of the WG by Jean-Francois Mule, ipcdn co-chair

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01593.html


Major suggestions not incorporated

• None as of this writing


NCS Signaling MIB Status

• IETF NCS Signaling MIB 8– Posted 2/20

• IPCDN WG Last Call– 7/21-8/10

• Next steps:– New WG Last Call?


IPCDN Management Event MIB for

PacketCable/IPCablecom MTA devicesdraft-ietf-ipcdn-pktc-eventmess-04

Sumanth Channabasappa, [email protected]

February 22 2005


Management Event MIB Draft Changes

• See list of changes in archive at:http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01595.html

• Technical changes• The draft was aligned with the latest changes made to

the PacketCable MEM MIB• The MIB was extended to support ‘Event Classes’ with

the addition of the MIB table ‘pktcDevEventClassReportTable ‘ and the MIB Objects ‘pktcDevEventDescrClass’ and ‘pktcDevEvReportingLevel’

• MAX-ACCESS clause for the auxiliary MIB Objects ‘pktcDevEventDescrEnterprise’ and ‘pktcDevEvLogIndex’ were corrected

• Editorial Changes– Fixed formatting and accommodated boiler-plate

changes– Corrected references– Appropriate terminologies were edited


Major suggestions not incorporated

• None as of this writing


Management Event MIB Draft Changes

• IETF Management Event MIB 4– Posted 2/20

• IPCDN WG Last Call– 7/21-8/10

• Next steps:– Need expert and mib doctor review


IPCDN CableHome MIB Modules


CableHome MIB Modules WithdrawalCurrent IETF IPCDN charter includes:

-- CableHomePublish MIB documents for:• managing attributes of a residential gateway or

home router device,• managing private address-to-public address

mappings for a residential gateway or home router device,

• managing the address lease acquisition client and the address lease server functionality of a residential gateway or home router device,

• managing diagnostic utilities used to remotely test the connectivity between a residential gateway and privately -addressed LAN hosts,

• managing firewall attributes, monitoring firewall attacks, and managing security certificates in a residential gateway or home router device,

• managing QoS configuration in a residential gateway or home router device.

WG work items include 6 IPCDN Internet-Drafts

• draft-ietf-ipcdn-cable-gateway-config-mib-00draft-ietf-ipcdn-cable-gateway-tools-mib-00draft-ietf-ipcdn-cable-gateway-device-mib-00draft-ietf-ipcdn-cable-gateway-addressing-mib-00draft-ietf-ipcdn-cable-gateway-security-mib-00draft-ietf-ipcdn-cable-gateway-qos-mib-00

• IDs Last updated in June 2003

• No updates since Internet-Drafts became IPCDN work items

Lack of WG interest and participants to make progress in IETF ipcdn

WG Chairs Recommendation after consulting with vendors and CableLabs CableHome group:

Abandon all above Internet-Drafts and associated WG items as of IETF #62


IPCDN WG Next Steps

• Finish all DOCSIS MIBs by June 2004– Finish all work on active IDs

• Request publication for– PacketCable/IPCablecom MTA MIB– PacketCable/IPCablecom Signaling MIB

• Advance expert + mib doctor reviews for Management Event MIB for MTAs

• Revise Charter Milestones for– DOCSIS, PacketCable/IPCablecom – Remove CableHome MIBs if WG chairs recommendation is validated by consensus and ADs

Documents

Page 1 IPCDN Working Group IETF 62 - IPCDN WG Update Richard Woundy Jean-François Mulé IETF IPCDN Co-Chairs Tuesday March 8, 2005 [email protected]