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

Hi Menachem,

There is a working text available, MG-R19.zip, on the following ITU-T
FTP web site:

http://ties.itu.int/u/tsg15/sg15/xchange/wp1/q4/Meetings/2005-12-Munich/
00_doc_list.html

You must be an ITU-T member to access it.

Best regards,

Miguel

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Thursday, December 08, 2005 11:24 AM
> To: Miguel Peeters
> Cc: [email protected]; [email protected]
> Subject: RE: [Adslmib] RE: Adslmib Digest, Vol 19, Issue 3
> 
> Hi Miguel,
> 
>       Do you mean that the revision of G.997.1 to support 
> VDSL2 will be completed in February 2006, in which case are 
> there any early drafts available?
> 
> Best Regards,
> 
> Menachem Dodge
> ECI Telecom Ltd.
> Broadband Access Division
> 
> Tel:      +972-3-9268421
> Mobile: +972-54-5788421
> Fax:      +972-3-9287342
> 
> 
>                                                               
>              
>              "Miguel Peeters"                                 
>              
>              <Miguel.Peeters@b                                
>              
>              roadcom.com>                                     
>           To 
>              Sent by:                  [email protected]       
>              
>              adslmib-bounces@i                                
>           cc 
>              etf.org                                          
>              
>                                                               
>      Subject 
>                                        RE: [Adslmib] RE: 
> Adslmib Digest,   
>              04/11/2005 11:04          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
> >
> >
> 
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
> 
> 
> 
>