Re: RFMIBv2 ID-nits: references
"Wim De Ketelaere" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <04d801c3bb5f$8bddec10$0605050a@WIMSLAPTOP> |
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
>