RE: RFMIBv2 ID-nits: references
"Eduardo Cardona" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Thanks Wim, Jean-Francois also pointed that to me, It will be corrected Eduardo -----Original Message----- From: Wim De Ketelaere [mailto:[email protected]] Sent: Friday, December 05, 2003 11:43 AM To: Eduardo Cardona; Jean-Francois Mule; Matthew Schmitt; [email protected] Cc: [email protected] Subject: Re: [ipcdn] RFMIBv2 ID-nits: references Hi all, Just one comment: We always use Euro-DOCSIS instead of EuroDOCSIS as this was the agreed upon name within the certification board,... Thanks, Best regards, Wim ----- Original Message ----- From: "Eduardo Cardona" <[email protected]> To: "Wim De Ketelaere" <[email protected]>; "Jean-Francois Mule" <[email protected]>; "Matthew Schmitt" <[email protected]>; <[email protected]> Cc: <[email protected]> Sent: Friday, December 05, 2003 6:50 PM Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Hi all, I am agree with Wim, Moreover, the current pre-draft 9 ( not available publicly yet) includes "EuroDOCSIS" in the glossary and references Annex F of DOCSIS 2.0 RFI spec. (back as originally in RFIv2 MIB early drafts 00 and 01). The reference [9] was before (since draft 02 which rferences DOCSIS 2.0 RFI W04 to hold the requirement of docsIfDownChannelInterleave and docsIfDownChannelAnnex, At that time Annex F did not have those requirements. As Wim said, with pretty much all EuroDocsis requirements in RFI spec, the EuroDOCSIS keyword would be enough to refer to the European requirements. Following all your suggestions would remove reference [9] and put to the ipcdn consideration - Redefines docsIfDownChannelInterleave definition as : Original (draft 02-08): docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec taps12increment17 is implemented in conformance with EuroDOCSIS document 'Adapted MIB-definitions - and a clarification for MPEG-related issues - for EuroDOCSIS cable modem systems' by tComLabs and should only be used for a EuroDOCSIS MAC interface. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Table 6-13." ::= { docsIfDownstreamChannelEntry 5 } Proposed for draft 09 docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec The value 'taps12increment17' is supported by EuroDOCSIS cable systems only and the others by DOCSIS cable systems. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Table 6-15." ::= { docsIfDownstreamChannelEntry 5 } Note in the coming draft 09 references will be updated to the current RFIv2.0 I04 spec e.g 6-13 in previous drafts is now 6-15. In this particular case the Annex F table F-11 is the equivalent to table 6-15 but in the references I am inclined to leave only the DOCSIS references. The RFI spec is clear in how to implement euroDOCSIS based on the DOCSIS spec and Annex F "overrides". For docsIfDownChannelAnnex, I got input from greg White and the propose text would be : Plass adding normative references to ITU-J83 and EN 300 429 OLD: docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-J83 is used, annexB : Annex B from ITU-J83 is used. annexC : Annex C from ITU-J83 is used. AnnexB is used for DOCSIS implementations" REFERENCE "Document Adapted MIB-definitions and a clarification for MPEG-related issues for EuroDOCSIS cable modem systems v1.01, tComLabs, May 2000, Section 2.2" ::= { docsIfDownstreamChannelEntry 7 } NEW: docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-J83 is used. equivalent to EN 300 429 annexB : Annex B from ITU-J83 is used. annexC : Annex C from ITU-J83 is used." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Sections 6.3.1, H.3.1." ::= { docsIfDownstreamChannelEntry 7 } New References: [EN 300 429] ETSI Standard EN 300 429, Version 1.2.1: Digital Video Broadcasting (DVB), Framing structure, channel coding and modulation for cable systems, April 1998. [ITU-T J.83] ITU-T Recommendation J.83 (4/97), Digital multi-programme systems for television sound and data services for cable distribution. Let me know any comments Eduardo Below are the section texts for convenience: ------------ H.3.1 Downstream Data The Downstream Data Interface carries data from the MAC to the PHY for transmission on the Downstream. All signals on the interface are synchronous with respect to a clock driven by the PHY and received by the MAC. Four bits of data are transferred on each clock. The frequency of this clock is proportional to the Downstream bit rate. Its precise frequency is a function of the Downstream Symbol Rate, the modulation type (64QAM or 256QAM), and the physical layer framing in use (ITU-T Recommendations J.83 Annex A or ITU-T Recommendations J.83 Annex B). -------------- 6.3.1 Downstream Protocol The downstream PMD sublayer MUST conform to ITU-T Recommendations J.83, Annex B for Low-Delay Video Applications [ITU-T J.83-B], with the exceptions called out in Section 6.3.2. Note: Any reference in this document to the transmission of television in the forward channel that is not consistent with [EN 300 429] is outside the normative scope as only [EN 300 429] is used for digital multi-program TV distribution by cable in European applications. See Section 1 (1.1 Scope). --------------- F.6.3.1 Downstream protocol The downstream PMD sublayer MUST conform to [EN 300 429]. -----Original Message----- From: Wim De Ketelaere [mailto:[email protected]] Sent: Friday, December 05, 2003 12:12 AM To: Jean-Francois Mule; Matthew Schmitt; [email protected]; Eduardo Cardona Cc: [email protected] Subject: Re: [ipcdn] RFMIBv2 ID-nits: references Hi all, I have no problem removing the MIBs from the document on our website if the final Euro-DOCSIS specifics are present in the MIB-RFC ! I believe you can reference to appendix N (1.0/1.1) and F (2.0), or just reference to the "European Specific Implementation" (cfr. language used in beginning 1.1 RFI-specification). Just let me know ! Thanks, Best regards, Wim ----- Original Message ----- From: "Jean-Francois Mule" <[email protected]> To: "Matthew Schmitt" <[email protected]>; <[email protected]>; "Eduardo Cardona" <[email protected]>; <[email protected]> Cc: <[email protected]> Sent: Friday, December 05, 2003 12:49 AM Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Ok thanks Matt. But now that I read the tComLabs document, I still have a pb with keeping this reference (and by now, I have found it in the text in the REFERENCE clause of some objects). When you look at the document, it overwrites mib definitions for rfc2670.docsIfDownChannelInterleave and rfc2670.docsIfDownChannelAnnex (2 object defs from the old RFC 2670). The object definitions contained in RF MIB v2 draft 08 are correct. => so what we need in the RF MIB v2 is actually a normative reference to the Euro-DOCSIS specification that mandates the interleaving formats or ITU-T J83. Comments? Jean-François > -----Original Message----- > From: Matthew Schmitt > Sent: Thursday, December 04, 2003 3:40 PM > To: Jean-Francois Mule; [email protected]; Eduardo Cardona; > [email protected] > Cc: [email protected] > Subject: RE: [ipcdn] RFMIBv2 ID-nits: references > > > FYI, I did manage to locate the referenced document on > www.tcomlabs.com. The direct link is > http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_ > spec.pdf. Via their website, you can get to the file by first > clicking on the Euro-DOCSIS link, then clicking on the Euro-DOCSIS 1.0 > link (the link to that page is > www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm). On that page, it's > the document listed as "Additional document: .pdf". > > Matt > > -----Original Message----- > From: Jean-Francois Mule > Sent: Thursday, December 04, 2003 3:12 PM > To: [email protected]; Eduardo Cardona; > [email protected] > Cc: [email protected] > Subject: [ipcdn] RFMIBv2 ID-nits: references > > > > Check ID nits and other comments made by mib doctors in other drafts. > http://www.ietf.org/ID-nits.html > > There are normative references that are not even mentioned once and > not used as IMPORTs in the document: > [1] Woundy, R., "Baseline Privacy Interface Management > Information Base for DOCSIS Compliant Cable Modems > and Cable Modem Termination Systems", RFC3083, March 2001. > [9] "Adapted MIB-definitions and a clarification for MPEG-related > issues for EuroDOCSIS cable modem systems v1.01", tComLabs, > May 2000., available at http://www.tcomlabs.com. > Suggestions: > - call this reference in the text or just remove it; > - I cannot find the named reference under http://www.tcomlabs.com ; > if you keep it, then > we need a better link, especially if it remains > normative. > > > Also, should [6] be made informative instead of normative? > (a) it's a book > (b) the DOCSIS specs are referenced normatively and that's where a > normative reference on QPSK should be. > [6] Proakis, John G., "Digital Communications, 3rd Edition", > McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6 > > Thanks, > Jean-François > PS: also, CableLabs is working on a stable HTTP URL for our > specifications so the http://www.cablemodem.com URL will most likely > have to be updated. More on the actual URL soon. > > > _______________________________________________ > IPCDN mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ipcdn >