Subject: RE: Trunk MIB (RFC 2495/6)

From: "Faye Ly" <[email-masked]>
Date: Wed, 12 Sep 2001 11:10:11 -0700

Hi,

Here are the latest with RFC 2495/6:

- Dave Fowler is too busy so Orly has kindly stepped up to take on 
  the task of being the editor for both RFCs.  
- A list of bugs/requests will be posted by Orly to this list for
  RFC 2495/6.  
- There has been some thoughts on how to advance RFC 2495/6.  Please 
  see attached emails.  The alternatives are:

  - Publish new RFCs that obsolete RFC 2495/6.  Wait for
    6 months and then advance them to draft standard.
  - Move current RFC (2495/6) to Draft Standard and work on supplemental
    DS1 MIBs.
  
This largely depends on the scope of the change that is being proposed.
Please see Orly's coming email.

-faye

-----Original Message-----
From: Kaj Tesink [mailto:[email-masked]]
Sent: Wednesday, September 12, 2001 7:21 AM
To: Orly Nicklass; [email-masked]; Erik Nordmark; Faye Ly
Cc: [email-masked]
Subject: RE: Trunk MIB (RFC 2495/6) 

At 12:10 PM 9/12/01 +0200, Erik Nordmark wrote:

>Do take the discussion to the list.
>
>In general the set of changes when going from PS to DS is
>limited to removing things from the protocol. Of course, clarifying
>the specification is ok, since that is part of the purpose of
>advancing the specification.
>
>However, adding new things often mean that the document can not move
>to DS immediately but instead needs to be reissued as PS, wait for 6
months,
>and then put forth the implementation report and ask it to be moved to
DS.
>
>This is at least true when the additions either cause interoperability
>issues between old and new implementations, and when the additions
place
>new requirements on implementations.
>If there are minor additions that don't require that all
implementations 
>change
>it might be possible to do those when moving to DS.

just to add to this and considering the list of issues:
- if the syntax of an object is changed then that is a clear candidate
   for an interoperability problem along erik's note
- adding code points to an enumerated list in the past has often been
   considered as an enhancement or clarification (esp if one of the
   original values was already something like 'other')
- adding new objects  - this is probably a matter of judgement. i'd
   certainly argue that adding a whole bunch of objects would require
   recycling at PS. a single object? hmmm. note that i'm not a fan of
   slippery language in the conformance clause to get around this
problem.
   a possibility may be to write a supplemental ds1 mib as has
   been proposed in the past.
- lastly, the scope of the orginal ds1 mib was build around
   ansi t1.231 & friends. widening the scope beyond that e.g., through 
additional
   objects, would change the document and also merit recycling at PS in
my mind

my own take on all this, without having studied the change proposals in
detail,
is that we should make any effort to get this spec moved to DS; note
that
this spec goes back all the way to rfc1231. if substantial additions are

merited
as determined by the list then lets do a supplemental mib.

kaj

>   Erik
>
> >----- Begin Included Message -----<
>
>Date: Tue, 11 Sep 2001 15:21:30 -0700
>From: "Faye Ly" <[email-masked]>
>Subject: RE: Trunk  MIB (RFC 2495/6)
>To: "Orly Nicklass" <[email-masked]>
>Cc: [email-masked], [email-masked], [email-masked]
>
>Orly,
>
>That is probably because I don't have a definite answer.  Hopefully
>Erik and Kaj know the answer.  Here is my suggestion:
>
>We are moving RFC 2495/6 towards the next stage of the standardization,
>we can incooperate any implementation experience caused changes in the
>new draft.  Post it to the list and once it has no more open issues.
>Along with the implementation experience report, we can push it to
>"Draft standard".  From what I understood it, this will be a new
>RFC that obsolete 2495/6.
>
>(This suggestion is based on the fact that all requests/changes are
>addition, not deletion or replacement)
>
>Erik?  Your thoughts?
>
>-faye
>
>-----Original Message-----
>From: Orly Nicklass [mailto:[email-masked]]
>Sent: Monday, September 10, 2001 10:18 PM
>To: Faye Ly
>Subject: RE: Trunk MIB (RFC 2495/6)
>
>
>Hi Faye,
>
>I notice you did not reply to my strange question regarding
continuation
>from a draft  to draft, or RFC to draft. Please see below.
>
>Orly
>-----------------------
>Orly Nicklass, Ph.D
>Associate VP, R&D
>RAD Data Communications, Ltd.
>
>[email-masked]
>
>
>-----Original Message-----
>From: Faye Ly [mailto:[email-masked]]
>Sent: Monday, September 10, 2001 11:35 PM
>To: Orly Nicklass
>Cc: [email-masked]; [email-masked]
>Subject: RE: Trunk MIB (RFC 2495/6)
>
>
>Looks good to me.  I am forwarding it to Nathan and Erik
>to get their OK. -faye
>
>-----Original Message-----
>From: Orly Nicklass [mailto:[email-masked]]
>Sent: Sunday, September 09, 2001 11:49 PM
>To: Faye Ly
>Subject: Trunk MIB (RFC 2495/6)
>
>
>Hi Faye,
>
>It took me sometime to get  started and I am heading towards few
>holidays
>and vacation in the coming month, but in between I hope to get some
>progress
>here.
>
>So, I plan to send the following mail to the list as a starting point
>and
>then, after some reactions (or none), I will edit the draft.
>Please review, and let me know if you are ok with it.
>By the way, the draft I got dated as 1998, I suppose is the last copy
>before
>it became RFC.  Since I only have experience with writing new draft in
>the
>past, do we continue from the draft copy or from the RFC copy? there
are
>sections that are not the same at the two states.
>
>So here is the mail to the list:
>-----------------------------------------------------------------------
-
>----
>
>
>In order to proceed with the next draft of trunk MIB towards moving it
>up in
>the standard truck, there are few open issues that need to be closed.
>Please
>review the list of issues, and comment according to issue number. Draft
>will
>be posted soon.
>
>
>
>Issue 1.
>initiator: Ken Chapman from unispherenetworks
>
>Problem:
>In both the DS1 and the DS3 MIBs, the dsx1FracIfIndex/dsx3FracIfIndex
>have  a   SYNTAX of INTEGER (1..'7fffffff'h);
>however, the DESCRIPTIONs state "If no interface is currently using a
>channel, the value should be zero."
>So, the SYNTAX should be INTEGER (0..'7fffffff'h).
>
>Status:
>Will be fixed in the next draft, however, please notice, the items are
>deprecated by now .
>
>Issue 2.
>Initiator: Subrahmanya Hedge from Cisco
>
>Problem:
>  2.1. Request to add the following enums in  dsx3LineType object
>      ds3cbitadm
>      ds3cbitplcp
>      e3g832adm
>      e3g751adm
>      e3g751plcp
>      ds3m23adm
>      ds3m23plcp
>
>Status::Needs specification reference from the source standard to
>justify
>the addition, and/or comments from the list.
>
>  2.2. Request to add the  following object
>
>      dsx3InternalEqualizer OBJECT-TYPE
>       SYNTAX  INTEGER {
>                   use(1),
>                   byPass(2)
>               }
>       MAX-ACCESS  read-write
>       STATUS  current
>       DESCRIPTION
>         "This variable indicates whether the internal  equalizer is
>being
>           used or bypassed. Set this value depending on the line
>equipment
>           to which the receiver is attached. Possible values are :
>           use(1)         : Use the internal equalizer
>           byPass(2)   : bypass internal equalizer(use external
>equalizer).
>           This option allows easy interfacing of the device into
systems
>already utilizing the
>           external qualizers."
>      DEFVAL { use }
>
>Status:
>Needs comments from the list.
>
>Issue 3.
>Initiator: Orly Nicklass from  RAD
>
>.
>Problems:
>3.1. Request to add an additional value  of clock source to the object
>dsx1TransitClockSource.
>The new value is "ADAPTIVE" .  It is used to recover the clock
>based on the data flow rate  and not based on locking as done at the
>physical layer.
>
>Status:
>Since the value requested based on field implementation, need comments
>from
>the list.
>
>3.2. Request to add additional objects to the performance tables,
>current
>and interval:
>        dsx1CurrentLOS                 PerfCurrentCount,
>         dsx1CurrentLOF                PerfCurrentCount,
>         dsx1CurrentAIS                PerfCurrentCount,
>         dsx1CurrentRAI                PerfCurrentCount,
>         dsx1CurrentLOMF               PerfCurrentCount,
>         dsx1CurrentFEBE               PerfCurrentCount,
>          dsx1CurrentBPV               PerfCurrentCount
>
>
>The above result from field implementation where customers were not
>happy
>with the standard
>statistics that is being collected and asked to get more accurate
>numbers
>of each indication separately.   Some errors are presently counted
>together
>in other objects that currently exist.
>Explanation of each exist in the current RFC.
>
>Status:
>Needs comments from the list.
>
>Issue 4.
>Initiator: Subrahmanya Hedge from Cisco again
>
>Problem:
>Request to  add two enums in dsx1LineType object'
>dsx1E1Q50
>dsx1E1Q50CRC
>
>Justification:
>dsx1E1Q50: These are taken from ITU-T G.704 with TS16 bits 5,7,8 set to
>101.
>In all
>the other cases TS16 bits 5,7,8 set to 111(Table 14)
>dsx1E1Q50CRC : dsx1E1Q50 with CRC
>
>Status: Will be added to the next draft.
>
>Issue 5.
>Initiator: Ron Camona / Accelarated networks
>
>Problem:
>5.1. Request to add object regarding Line BuildOut for T1.
>"The configuration of the Line   BuildOut circuitry is expressed
>(defined)
>in meters as
>dsx1LineLength.  But the T1 chipsets that I have worked with (both here
>at Accelerated Networks and previously at Nortel) contain a
"transceiver
>mode" setting.  This setting puts the T1 framer into either a "long
>haul" or a "short haul" mode.  For Long Haul, the Line BuildOut is
>accepted by the chipset as a CSU dB attenuation setting.  For Short
>Haul, the length setting (in feet) is accepted by the chipset.
>...So, in my MIB views (both Accelerated and Nortel), I have had to add
>a proprietary extension MIB table definition to allow configuration for
>either transceiver mode setting and a lineBuildOut object enumerated
>with units corresponding to dB attenuation values.
>
>Status:
>Ron, Please provide detail definition for the new object so we can
>properly
>consider it in the list. It sound like a proper request.
>
>5.2. Request for uniformity:
>"Also, at this time, I'm not keeping all 96 15-min statistics
>intervals...I wish that all RFC MIBs would define keeping the interval
>stats in the same way.  They all are philosophically trying to achieve
>the same thing, but each standard (RFC2495/2496, RFC2662 (ADSL), ATMF
>IMA MIB, etc.) seems to have some particular idiosyncrasies that keep a
>MIB developer up late at night..."
>
>Status: Sound reasonable, will check on that towards the next draft.
>
> >----- End Included Message -----<

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
        Red Bank, NJ 07701
        USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Orly Nicklass <[email-masked]>
Date: Wed, 12 Sep 2001 21:35:49 +0300

Hi all,

My original mail is at the bottom of the mail sent by Faye, but to ease the
reading of you all, I reattached it here as an independent mail.

-------------------------------
In order to proceed with the next draft of trunk MIB towards moving it
up in the standard truck, there are few open issues that need to be closed.
Please review the list of issues, and comment according to issue number.
Draft
will be posted soon.

Issue 1. 

Problem:

Status:

Issue 2.

Problem:

          This option allows easy interfacing of the device into systems
already utilizing the
          external qualizers."
     DEFVAL { use }

Status:

Issue 3. 

.
Problems:

Status:

Status:

Issue 4. 

Problem:

Justification:

Issue 5.

Problem:
at Accelerated Networks and previously at Nortel) contain a "transceiver

Status:

Status: Sound reasonable, will check on that towards the next draft, but any
change in here might enforce recycle to propose.

---

From: "Faye Ly" <[email-masked]>
Date: Thu, 13 Sep 2001 17:13:28 -0700

Orly,
 
Terribly sorry about publishing your email without letting you know
first.  The truth
is that I failed to double check on the attached email.  Should make a
note not to
do that from now on.
 
-faye

	-----Original Message----- 
	From: Orly Nicklass 
	Sent: Wed 9/12/2001 11:35 AM 
	To: Faye Ly; Kaj Tesink; [email-masked]; Erik Nordmark 
	Cc: [email-masked] 
	Subject: RE: Trunk MIB (RFC 2495/6) 

	Hi all,
	
	My original mail is at the bottom of the mail sent by Faye, but
to ease the
	reading of you all, I reattached it here as an independent mail.
	
	-------------------------------
	In order to proceed with the next draft of trunk MIB towards
moving it
	up in the standard truck, there are few open issues that need to
be closed.
	Please review the list of issues, and comment according to issue
number.
	Draft
	will be posted soon.

	Issue 1.
	
	Problem:
	In both the DS1 and the DS3 MIBs, the
dsx1FracIfIndex/dsx3FracIfIndex
	have  a   SYNTAX of INTEGER (1..'7fffffff'h);
	however, the DESCRIPTIONs state "If no interface is currently
using a
	channel, the value should be zero."
	So, the SYNTAX should be INTEGER (0..'7fffffff'h).
	
	Status:
	Will be fixed in the next draft, however, please notice, the
items are
	deprecated by now .
	
	Issue 2.
	
	Problem:
	
	Status::Needs specification reference from the source standard
to
	justify
	the addition, and/or comments from the list.

	     dsx3InternalEqualizer OBJECT-TYPE
	      SYNTAX  INTEGER {
	                  use(1),
	                  byPass(2)
	              }
	      MAX-ACCESS  read-write
	      STATUS  current
	      DESCRIPTION
	        "This variable indicates whether the internal  equalizer
is
	being
	          used or bypassed. Set this value depending on the line
	equipment
	          to which the receiver is attached. Possible values are
:
	          use(1)         : Use the internal equalizer
	          byPass(2)   : bypass internal equalizer(use external
	equalizer).
	          This option allows easy interfacing of the device into
systems
	already utilizing the
	          external qualizers."
	     DEFVAL { use }
	
	Status:
	
	Issue 3.
	
	.
	Problems:
	3.1. Request to add an additional value  of clock source to the
object
	dsx1TransitClockSource.
	The new value is "ADAPTIVE" .  It is used to recover the clock
	based on the data flow rate  and not based on locking as done at
the
	physical layer.
	
	Status:
	Since the value requested based on field implementation, need
comments
	from
	the list.
	
	3.2. Request to add additional objects to the performance
tables,
	current
	and interval:

	The above result from field implementation where customers were
not
	happy
	with the standard
	statistics that is being collected and asked to get more
accurate
	numbers
	of each indication separately.   Some errors are presently
counted
	together
	in other objects that currently exist.
	Explanation of each exist in the current RFC.
	
	Status:
	
	Issue 4.
	
	Problem:
	
	Justification:
	dsx1E1Q50: These are taken from ITU-T G.704 with TS16 bits 5,7,8
set to
	101.
	In all
	the other cases TS16 bits 5,7,8 set to 111(Table 14)
	dsx1E1Q50CRC : dsx1E1Q50 with CRC

	Issue 5.
	
	Problem:
	5.1. Request to add object regarding Line BuildOut for T1.
	"The configuration of the Line   BuildOut circuitry is expressed
	(defined)
	in meters as
	dsx1LineLength.  But the T1 chipsets that I have worked with
(both here
	at Accelerated Networks and previously at Nortel) contain a
"transceiver
	mode" setting.  This setting puts the T1 framer into either a
"long
	haul" or a "short haul" mode.  For Long Haul, the Line BuildOut
is
	accepted by the chipset as a CSU dB attenuation setting.  For
Short
	Haul, the length setting (in feet) is accepted by the chipset.
	...So, in my MIB views (both Accelerated and Nortel), I have had
to add
	a proprietary extension MIB table definition to allow
configuration for
	either transceiver mode setting and a lineBuildOut object
enumerated
	with units corresponding to dB attenuation values.
	
	Status:
	Ron, Please provide detail definition for the new object so we
can
	properly
	consider it in the list. It sound like a proper request.
	
	5.2. Request for uniformity:
	"Also, at this time, I'm not keeping all 96 15-min statistics
	intervals...I wish that all RFC MIBs would define keeping the
interval
	stats in the same way.  They all are philosophically trying to
achieve
	the same thing, but each standard (RFC2495/2496, RFC2662 (ADSL),
ATMF
	IMA MIB, etc.) seems to have some particular idiosyncrasies that
keep a
	MIB developer up late at night..."
	
	Status: Sound reasonable, will check on that towards the next
draft, but any
	change in here might enforce recycle to propose.