[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adslmib] DISCUSS and COMMENT: draft-ietf-adslmib-vdsl2

WARNING: contains banned part
--- Begin Message --- 
We usage of "DEFVAL" index for a profile: This is pattern is similar to the
RFC 2662 convention.
Regards,
Umberto

-----Original Message-----
From: adslmib-bounces at ietf.org [mailto:adslmib-bounces at ietf.org]On
Behalf Of Moti Morgenstern
Sent: Sunday, 5 July 2009 10:54 PM
To: Romascanu, Dan (Dan); Menachem Dodge
Cc: adslmib at ietf.org
Subject: Re: [Adslmib] DISCUSS and COMMENT: draft-ietf-adslmib-vdsl2


Hi,

Xdsl2TransmissionModeType 
=========================
We believe that any changes to the modes listed in Xdsl2TransmissionModeType
will probably be involved with changes to other components of the DSL
management model, i.e., will anyhow require a revised RFC. This is perfectly
demonstrated by the changes performed in the model along with adding the
VDSL2 related modes to the Adsl2TransmissionModeType defined RFC 4706.

IANA Considerations 
===================
The "IANA Considerations" paragraph is located in the same place as in RFC
4319 and RFC 4706.
I'm unaware of any guidelines regarding the exact position of this section
within the document.   


xdsl2LineAlarmConfTemplate
==========================
The name of the default template in our model is actually "DEFVAL" and every
DSL line is, by default, associated with that template. It means that in the
MIB table xdsl2LineConfTemplateTable, we require that there will always be a
row with the name (i.e., xdsl2LConfTempTemplateName value) set to "DEFVAL". 
Furthermore, we actually state in the DESCRIPTION clause of
xdsl2LineConfTemplateEntry that "A default template with an index of
'DEFVAL' will always exist".
We use the same default profile name for other profile tables as well. Those
are of course separate profile tables but yet each of them has a row with
the name "DEFVAL".
Is there any reason to avoid using that specific name?

Regards,
Moti


-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca at avaya.com] 
Sent: Thursday, July 02, 2009 3:51 PM
To: Moti Morgenstern; Menachem Dodge
Cc: adslmib at ietf.org
Subject: FW: DISCUSS and COMMENT: draft-ietf-adslmib-vdsl2 

 Moti, Menachem,

Please address the issues raised by AD Adrian Farrel in his DISCUSS and
COMMENT.

Thanks and Regards,

Dan


-----Original Message-----
From: iesg-bounces at ietf.org [mailto:iesg-bounces at ietf.org] On Behalf Of
Adrian Farrel
Sent: Thursday, July 02, 2009 3:28 PM
To: iesg at ietf.org
Cc: adslmib-chairs at tools.ietf.org; fayely at juniper.net;
rray at core3.amsl.com; Greg_Bathrick at pmc-sierra.com; rray at pesa.com
Subject: DISCUSS and COMMENT: draft-ietf-adslmib-vdsl2 

Discuss:
I would like to hear from the Ops ADs whether they think that TCs like
Xdsl2TransmissionModeType should be moved to an IANA MIB module to allow
the definition of new values without requiring to respin this MIB module
as a new RFC.

It is odd (and possibly non-conformant) to place the IANA Considerations
section at 2.2.

Comment:
I don't understand the default value provided in the following object.
Please check that it is appropriate majick.

xdsl2LineAlarmConfTemplate  OBJECT-TYPE
   SYNTAX      SnmpAdminString (SIZE(1..32))
   MAX-ACCESS  read-write
   STATUS      current
   DESCRIPTION
      "The value of this object identifies the row in the xDSL2
       Line Alarm Configuration Template Table,
       xdsl2LineAlarmConfTemplateTable, which applies to this line.

       This object MUST be maintained in a persistent manner."
   REFERENCE    "DSL Forum TR-129, paragraph #5.1"
   DEFVAL       { "DEFVAL" }
   ::= { xdsl2LineEntry 3 }

_______________________________________________
Adslmib mailing list
Adslmib at ietf.org
https://www.ietf.org/mailman/listinfo/adslmib

<<attachment: winmail.dat>>


--- End Message ---