RE: RE: Adslmib Digest, Vol 19, Issue 3

For those interested, ITU-T SG15/Q4 has decided to consent a revision of G.997.1 to support VDSL2 in February 2006.

Best regards,

Miguel Peeters
Broadcom / Editor G.997.1 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of [email protected]
> Sent: Friday, November 04, 2005 9:57 AM
> To: [email protected]
> Subject: [Adslmib] RE: Adslmib Digest, Vol 19, Issue 3
> 
> Infineon also has a strong interest in working on the 
> development of a MIB for VDSL2. We are prepared to contribute 
> towards this by reviewing, comments or co-authorship, as appropriate. 
> 
> Regards,
> Neal J. King
> Infineon Technologies    
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: Friday, November 04, 2005 4:46 AM
> To: [email protected]
> Subject: Adslmib Digest, Vol 19, Issue 3
> 
> Send Adslmib mailing list submissions to
> 	[email protected]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/adslmib
> 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 Adslmib digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: ADSL MIB Working Group Goals and Milestones
>       ([email protected])
>    2. RE: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64 bit
>       counter when valid value is 0 .. 899 (Ray, Robert)
>    3. RE: ADSL MIB Working Group Goals and Milestones 
> (Umberto Bonollo)
>    4. Re: RE: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64
>       bitcounter when valid value is 0 .. 899 (Randy Presuhn)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 3 Nov 2005 19:21:23 +0200
> From: [email protected]
> Subject: Re: [Adslmib] ADSL MIB Working Group Goals and Milestones
> To: [email protected]
> Cc: [email protected], [email protected]
> Message-ID:
> 	
> <OF1E3ECBBC.EE101223-ONC22570AE.005D81A1-C22570AE.005F4BCE@eci
tele.com>
> 	
> Content-Type: text/plain; charset=US-ASCII
> 
> Hi Bob,
> 
> The IETF NG xDSL MIB we just developed can be relatively 
> easily modified in order to support VDSL2. Once there is 
> enough consensus in ITU-T regarding to the VDSL2 management 
> model and the re-charter process is completed, it will be 
> possible to finalize that MIB.
> 
> We have an interest in VDSL2 and are prepared to continue on 
> as co-authors.
> 
> Best regards,
> M. Morgenstern and M. Dodge
> 
> 
>  
> 
>                       Robert Ray
> 
>                       <RobertRay@pesa.         To:      "ADSL MIB
> (E-mail)" <[email protected]>                                         
>                       com>                     cc:
> 
>                       Sent by:                 Subject: [Adslmib] ADSL
> MIB Working Group Goals and Milestones                          
>                       adslmib-bounces@
> 
>                       ietf.org
> 
>  
> 
>  
> 
>                       03/11/2005 16:10
> 
>                       Please respond
> 
>                       to RobertRay
> 
>  
> 
>  
> 
> 
> 
> 
> Hi.
> 
> The last remaining item in our charter is:
> 
> Dec 05  Re-charter or close down
> 
> I know there has been some discussion about working on VDSL2. 
>  If enough interest is shown (i.e. volunteers to author, 
> comment, review, etc.), perhaps we can move towards trying to 
> get rechartered to pursue this work.  If you want to go this 
> route, I urge you to speak up soon!
> 
> If not, I suggest we "go dormant" (keep the mail list up but 
> be removed from the list of active working groups) until the 
> current IDs wend their way through the RFC editor queue and 
> then shut down.
> 
> Thoughts?
> 
> Regards,
> Bob Ray
> 
> 
> 
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 3 Nov 2005 11:24:21 -0600
> From: "Ray, Robert" <[email protected]>
> Subject: [Adslmib] RE: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64
> 	bit	counter when valid value is 0 .. 899
> To: "Ambiga Karthikeyan" <[email protected]>,
> 	<[email protected]>
> Cc: [email protected]
> Message-ID:
> 	<[email protected]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi.
>  
> When writing that MIB, I didn't want to mix high-capacity 
> textual conventions with similar though 32-bit textual 
> conventions from RFC3593.
> That is, I'm a big fan of monophyly when writing software 
> (and specifications for same).  In terms of what is "on the 
> wire", the high capacity data types, when encoded in asn.1, 
> require no more bits than their 32-bit equivalents as the 
> significant information is an integer
> value in the range 0..899.   
>  
> >From a programmer's standpoint, you need not store 64 bits internally
> for your counters, simply encode them for transmission that 
> way.  Hope this helps.  
>  
> Regards,
> Bob Ray
>  
> ________________________________
> 
> From: Ambiga Karthikeyan [mailto:[email protected]]
> Sent: Thursday, November 03, 2005 11:04 AM
> To: [email protected]
> Cc: Ray, Robert; [email protected]
> Subject: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64 bit 
> counter when valid value is 0 .. 899
> 
> 
> 
> Dear RFC3728 editors,
> 
>  
> 
>      I am working on implementing Vdsl MIBs and while 
> reviewing RFC 3728, I found that the following mib variables in 
> 
> vdslPerfDataTable and vdslPerfIntervalTable  defined as 
> HCPerfCurrentCount which is 64 bit counter.
> 
>  
> 
>            vdslPerfDataCurr15MinLofs          HCPerfCurrentCount,
> 
>            vdslPerfDataCurr15MinLoss          HCPerfCurrentCount,
> 
>            vdslPerfDataCurr15MinLprs          HCPerfCurrentCount,
> 
>  
> 
>            vdslPerfDataCurr15MinLols          HCPerfCurrentCount,
> 
>            vdslPerfDataCurr15MinESs           HCPerfCurrentCount,
> 
>            vdslPerfDataCurr15MinSESs          HCPerfCurrentCount,
> 
>            vdslPerfDataCurr15MinUASs          HCPerfCurrentCount,
> 
>            vdslPerfDataCurr15MinInits         HCPerfCurrentCount,
> 
>  
> 
>           vdslPerfIntervalLofs               HCPerfIntervalCount,
> 
>           vdslPerfIntervalLoss               HCPerfIntervalCount,
> 
>           vdslPerfIntervalLprs               HCPerfIntervalCount,
> 
>           vdslPerfIntervalLols               HCPerfIntervalCount,
> 
>           vdslPerfIntervalESs                HCPerfIntervalCount,
> 
>           vdslPerfIntervalSESs               HCPerfIntervalCount,
> 
>           vdslPerfIntervalUASs               HCPerfIntervalCount,
> 
>           vdslPerfIntervalInits              HCPerfIntervalCount
> 
>  
> 
> Here is the definition of one of them:
> 
>    vdslPerfDataCurr15MinLofs OBJECT-TYPE
> 
>        SYNTAX       HCPerfCurrentCount
> 
>        UNITS        "seconds"
> 
>        MAX-ACCESS   read-only
> 
>        STATUS       current
> 
>        DESCRIPTION
> 
>            "Count of seconds during this interval that there
> 
>            was Loss of Framing."
> 
>        REFERENCE    "T1E1.4/2000-009R3, Part 1, common spec"
> 
>        ::= { vdslPerfDataEntry 12 }
> 
>  
> 
> >From the description, it is the number of seconds in the 15 Min
> interval
> which had Loss of Frame event and so it can be from 0 to 899 
> only. So why do we need 64 bit counter value here ?
> 
>  
> 
> Am I missing something?
> 
>  
> 
> Thank you very much,
> 
> Ambiga
> 
>  
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/adslmib/attachments/20051103/51
> 5e1522/att
> achment.htm
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 4 Nov 2005 11:44:54 +1100
> From: "Umberto Bonollo" <[email protected]>
> Subject: RE: [Adslmib] ADSL MIB Working Group Goals and Milestones
> To: <[email protected]>, <[email protected]>
> Cc: [email protected]
> Message-ID: <000c01c5e0d8$f9fb9760$84304c93@miracle>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi Bob, Menachem, Moti,
> 
> We would be happy also to continue on as co-authors for the 
> forthcoming
> VDSL2
> as our interest is similar.
> 
> Regards,
> Umberto Bonollo & Scott Baillie
> NEC Australia
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of [email protected]
> Sent: Friday, 4 November 2005 4:21 AM
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: [Adslmib] ADSL MIB Working Group Goals and Milestones
> 
> 
> Hi Bob,
> 
> The IETF NG xDSL MIB we just developed can be relatively 
> easily modified in order to support VDSL2. Once there is 
> enough consensus in ITU-T regarding to the VDSL2 management 
> model and the re-charter process is completed, it will be 
> possible to finalize that MIB.
> 
> We have an interest in VDSL2 and are prepared to continue on 
> as co-authors.
> 
> Best regards,
> M. Morgenstern and M. Dodge
> 
> 
> 
>                       Robert Ray
>                       <RobertRay@pesa.         To:      "ADSL MIB
> (E-mail)"
> <[email protected]>
>                       com>                     cc:
>                       Sent by:                 Subject: [Adslmib] ADSL
> MIB
> Working Group Goals and Milestones
>                       adslmib-bounces@
>                       ietf.org
> 
> 
>                       03/11/2005 16:10
>                       Please respond
>                       to RobertRay
> 
> 
> 
> 
> 
> Hi.
> 
> The last remaining item in our charter is:
> 
> Dec 05  Re-charter or close down
> 
> I know there has been some discussion about working on VDSL2. 
>  If enough interest is shown (i.e. volunteers to author, 
> comment, review, etc.), perhaps we can move towards trying to 
> get rechartered to pursue this work.  If you want to go this 
> route, I urge you to speak up soon!
> 
> If not, I suggest we "go dormant" (keep the mail list up but 
> be removed from the list of active working groups) until the 
> current IDs wend their way through the RFC editor queue and 
> then shut down.
> 
> Thoughts?
> 
> Regards,
> Bob Ray
> 
> 
> 
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
> 
> 
> 
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 3 Nov 2005 19:48:18 -0800
> From: "Randy Presuhn" <[email protected]>
> Subject: Re: [Adslmib] RE: RFC3728: vdslPerfDataCurr15MinLofs etc -
> 	why 64	bitcounter when valid value is 0 .. 899
> To: <[email protected]>
> Message-ID: <003301c5e0f2$986b3f40$7f1afea9@oemcomputer>
> Content-Type: text/plain;	charset="iso-8859-1"
> 
> Hi -
> 
> > From: "Ray, Robert" <[email protected]>
> > To: "Ambiga Karthikeyan" <[email protected]>;
> <[email protected]>
> > Cc: <[email protected]>
> > Sent: Thursday, November 03, 2005 9:24 AM
> > Subject: [Adslmib] RE: RFC3728: vdslPerfDataCurr15MinLofs 
> etc - why 64
> bitcounter when valid value is 0 .. 899
> ..
> > When writing that MIB, I didn't want to mix high-capacity textual 
> > conventions with similar though 32-bit textual conventions from
> RFC3593.
> > That is, I'm a big fan of monophyly when writing software (and 
> > specifications for same).  In terms of what is "on the 
> wire", the high 
> > capacity data types, when encoded in asn.1, require no more 
> bits than 
> > their 32-bit equivalents as the significant information is 
> an integer
> > value in the range 0..899.   
> >
> > From a programmer's standpoint, you need not store 64 bits 
> internally 
> > for your counters, simply encode them for transmission that 
> way.  Hope 
> > this helps.
> ...
> 
> Though I have some sympathy for this argument, I'm not able 
> to get the MIB review guidelines to support it, no matter how 
> hard I squint.
> 
> Though the review guidelines relax the RFC 2578 "wrap in less 
> than one hour" limitation on the use of Counter64, RFC 4181 
> (page 16) permits them when it "makes sense" to do so.  In 
> this particular case, the semantics of the object strongly 
> suggest that this shouldn't even be a Counter type, much less 
> Counter64.  Page 15 of RFC 4181 suggests that Unsigned32 
> would be the correct type in this case.
> 
> Randy
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
> 
> 
> End of Adslmib Digest, Vol 19, Issue 3
> **************************************
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
> 
>