Subject: RE: [ipcdn] RFMIBv2 ID-nits: references

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 5 Dec 2003 10:50:15 -0700

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-masked]] 
Sent: Friday, December 05, 2003 12:12 AM
To: Jean-Francois Mule; Matthew Schmitt; [email-masked]; Eduardo Cardona
Cc: [email-masked]
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-masked]>
To: "Matthew Schmitt" <[email-masked]>; <[email-masked]>; "Eduardo Cardona" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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-masked]; Eduardo Cardona; 
> [email-masked]
> Cc: [email-masked]
> 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-masked]; Eduardo Cardona; 
> [email-masked]
> Cc: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Wim De Ketelaere" <[email-masked]>
Date: Fri, 5 Dec 2003 19:42:33 +0100

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-masked]>
To: "Wim De Ketelaere" <[email-masked]>; "Jean-Francois Mule"
<[email-masked]>; "Matthew Schmitt" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
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

Original (draft 02-08):

Proposed for draft 09

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:

NEW:

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

------------
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).

---------------

-----Original Message-----
From: Wim De Ketelaere [mailto:[email-masked]]
Sent: Friday, December 05, 2003 12:12 AM
To: Jean-Francois Mule; Matthew Schmitt; [email-masked]; Eduardo
Cardona
Cc: [email-masked]

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-masked]>
To: "Matthew Schmitt" <[email-masked]>; <[email-masked]>;
"Eduardo Cardona" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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