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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.