Subject: [Adslmib] RE: Adslmib Digest, Vol 19, Issue 3

From: [email-masked]
Date: Fri, 4 Nov 2005 09:56:51 +0100

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-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, November 04, 2005 4:46 AM
To: [email-masked]
Subject: Adslmib Digest, Vol 19, Issue 3

Send Adslmib mailing list submissions to
	[email-masked]

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-masked]

You can reach the person managing the list at
	[email-masked]

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-masked])
   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-masked]
Subject: Re: [Adslmib] ADSL MIB Working Group Goals and Milestones
To: [email-masked]
Cc: [email-masked], [email-masked]
Message-ID:
	
<[email-masked]>
	
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-masked]>                                         
                      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-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

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

Message: 2
Date: Thu, 3 Nov 2005 11:24:21 -0600
From: "Ray, Robert" <[email-masked]>
Subject: [Adslmib] RE: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64
	bit	counter when valid value is 0 .. 899
To: "Ambiga Karthikeyan" <[email-masked]>,
	<[email-masked]>
Cc: [email-masked]
Message-ID:
	<[email-masked]>
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-masked]]
Sent: Thursday, November 03, 2005 11:04 AM
To: [email-masked]
Cc: Ray, Robert; [email-masked]
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/515e1522/att
achment.htm

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

Message: 3
Date: Fri, 4 Nov 2005 11:44:54 +1100
From: "Umberto Bonollo" <[email-masked]>
Subject: RE: [Adslmib] ADSL MIB Working Group Goals and Milestones
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
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-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Friday, 4 November 2005 4:21 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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-masked]>
                      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-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

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

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

Message: 4
Date: Thu, 3 Nov 2005 19:48:18 -0800
From: "Randy Presuhn" <[email-masked]>
Subject: Re: [Adslmib] RE: RFC3728: vdslPerfDataCurr15MinLofs etc -
	why 64	bitcounter when valid value is 0 .. 899
To: <[email-masked]>
Message-ID: <003301c5e0f2$986b3f40$7f1afea9@oemcomputer>
Content-Type: text/plain;	charset="iso-8859-1"

Hi -

> From: "Ray, Robert" <[email-masked]>
> To: "Ambiga Karthikeyan" <[email-masked]>;
<[email-masked]>
> Cc: <[email-masked]>
> 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-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

End of Adslmib Digest, Vol 19, Issue 3
**************************************

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

---

From: "Miguel Peeters" <[email-masked]>
Date: Fri, 4 Nov 2005 01:04:07 -0800

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 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, November 04, 2005 9:57 AM
> To: [email-masked]
> 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    
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> 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,
> 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
> 
> 
> 
> 
> 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
> for your counters, simply encode them for transmission that 
> way.  Hope this helps.  
>  
> Regards,
> Bob Ray
>  
> 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 
> 
> 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
> 
>  
> 
> 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,
> 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
> 
> 
> 
> 
> 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
> 
> 
> 
>