Subject: [MIB-DOCTORS] DEVAL for scalar object (was: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT))

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Oct 2012 11:26:41 +0200

MIB doctors,

Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your 
numerous review of this MIB, which I fully support.

Now, we received some push back from Anil, the author, on the required 
DEFVAL for scalar.
As I wrote below, I always considered the DEFVAL for scalar to be useful 
information, but I understand both arguments.
Read the email exchange below.

Which advice do we want to give in the future on this topic?

I'm in favor of telling:
- DEFVAL for scalar objects are nice-to-have, and it's good practice to 
have them
     This is in line with

    RFC 2578, section 7.9 says:
        Note that with this definition of the DEFVAL clause, it is
        appropriate to use it for any columnar object of a read-create
    table.
        It is also permitted to use it for scalar objects dynamically
    created
        by an agent, or for columnar objects of a read-write table
        dynamically created by an agent.

- If you don't put DEFVAL for scalar objects, then insert in the 
description a pointer on where to find the information

Regards, Benoit.

-------- Original Message --------
Subject: 	Re: Benoit Claise's Discuss on 
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Date: 	Thu, 11 Oct 2012 11:11:30 +0200
From: 	Benoit Claise <[email-masked]>
To: 	Anil Rijhsinghani <[email-masked]>
CC: 	Romascanu, Dan (Dan) <[email-masked]>, Donald Eastlake 
<[email-masked]>, Erik Nordmark <[email-masked]>, Ralph Droms 
<[email-masked]>, Bert Wijnen (IETF) <[email-masked]>, 
[email-masked], Joan Cucchiara <[email-masked]>, me 
<[email-masked]>

Anil, Dan,

I understand both arguments for and against DEFVAL for scalar.

I've been in favor of DEFVAL for scalar, and considered it a nice-to-have.

1. If you are the implementor, you must know the spec by heart, and 
obviously, these scalar DEFVAL's are not useful to you.
2. If you are the SNMP agent, it's true that the SNMPset contains the 
value to be set, so you don't need the DEFVAL.
3. If you are the network operator using the NMS GUI , it's pretty 
useful information to have default values. It's pretty nice when a NMS 
GUI contains the DEVAL value. Sure you can tell that, by looking at the 
specifications, someone will be able to get this value. In practice, is 
it done? So if the GUI developers could directly get the information 
from the DEFVAL, that's a plus.
I've seen to many GUIs where the first config page allows to enter 
almost anything. And the network operator just puts random values in 
there. In the world of NetFlow, inserting non-sense timeout values 
produced some funny results.
4. If you are none of the above... Once upon a time, I was a NMS 
customer support engineer, and I read many MIB modules.
And the DEFVAL always helped getting the default values. If nothing 
else, for troubleshooting.
And no, I didn't know (and didn't want to know) all the protocol 
specification details of the feature/protocol to be managed.

You see, there are multiple actors dealing with MIB modules.

How to more forward?
 > By the way I have included a REFERENCE clause in most objects, 
guiding an implementor to the section of the protocol RFC where he can 
find more information about the object and its default, if applicable.
That's good information already, and I could leave with that. It's 
actually just a (*) level of indirection

(*) time consuming if I take the case 4 above, i.e. my customer support 
engineer.

I want to publicly thanks Joan for the time spent on her review. Much 
appreciated.
Now, I would like to have some consistency from the MIB doctors in terms 
of guidelines on this topic. Let me discuss with them.

Regards, Benoit.

> Dan,
>
> An SNMP set operation is used to change the value of a read-write 
> object, or to create a new row in a table. There is a distinct 
> difference between the applicability of DEFVAL in these two cases, 
> hence the "appropriate" versus "permitted" language in the definition 
> of the DEFVAL clause for these two cases.
>
> When a set operation is performed on a scalar object, it comes with a 
> value to write into it. The SNMP agent need not guess what that value 
> might be,  nor does it need to rely on the MIB to tell it what to do.
>
> When a set operation is performed to create a new row in a table, it 
> may specify the value of one or more columns in that row. If the SNMP 
> agent is going to create a row, and not all column objects have been 
> specified, it is left with a dilemma: what should it set as the values 
> of those column objects? This is what the DEFVAL clause allows you to 
> do: give the agent a default value for unspecified column objects. 
> Such a dilemma does not occur for setting of scalar objects.
>
> If what you were saying is true, then every read-write object in every 
> MIB would need a DEFVAL clause. Clearly that is not the case.
>
> By the way I have included a REFERENCE clause in most objects, guiding 
> an implementor to the section of the protocol RFC where he can find 
> more information about the object and its default, if applicable.
>
> If this doesn't convince you, we will have to agree to disagree on this.
>
> Regards,
> Anil
>
>
> On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote:
>
> Hi Anil,
> I need to disagree with you on this. The DEFVAL function is the same 
> for a scalar and for a columnar object – as you well put it  ‘the 
> agent can deduce the missing value from the MIB syntax’.
> I do not understand your argument that the implementor should look at 
> the protocol specifications to in the case of scalar objects. We are 
> talking about writeable objects. Whatever the agent initializes with 
> will be sent to the instrumentation. In the absence of a DEFVAL value 
> anything can be written there. The same as in the case of a columnar 
> object the DEFVAL will indicate the value the agent initializes with 
> which will be the first value to be sent to the instrumentation until 
> a setRequest command changes it. Why should the agent implementor need 
> to look in the protocol specifications and not help him defining 
> DEFVAL clauses?
> Regards,
> Dan
> *From: *Anil R [mailto:[email-masked]]
> *Sent: *Wednesday, October 10, 2012 3:33 PM
> *To: *Romascanu, Dan (Dan)
> *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; Bert 
> Wijnen (IETF); [email-masked]; Joan Cucchiara
> *Subject: *Re: Benoit Claise's Discuss on 
> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
> Dan,
> From the description:
> - as a columnar object, it is "appropriate" to use DEFVAL
> - as a scalar object, it is "permitted" to use DEFVAL.
> Sure I know it is permitted for scalar objects, as that will not cause 
> a compile error.
> For columnar objects, it is actually useful, because a manager may 
> create an instance without specifying a columnar object. So it is 
> syntactically and practically useful to do so in such cases, because 
> the agent can deduce the missing value from the MIB syntax. It makes 
> the protocol more efficient. I know this is why we added DEFVAL, based 
> on my interaction at the time with the original SNMP authors (Jeff 
> Case, et al).
> My point is that not only is specifying DEFVAL for a scalar useless 
> from an SNMP syntactical point of view - because an agent cannot 
> actually use it, other than an implementor reading the RFC text - but 
> it is actually dangerous to do so. An implementor TRILL should be 
> looking to the protocol specification (RFC6325 in this case) to 
> determine how the protocol works and what the needed defaults are.
> We don't to define defaults in two different RFCs if we can help it.
> If the protocol decides to change a default, we shouldn't have to go 
> update the MIB.
> Regards,
> Anil
> On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote:
>
>
>
> Hi Anil,
> I believe that you are wrong stating that DEFVAL clauses should not be 
> present in the definitions of scalar objects, or at least I could not 
> find such a recommendations in the RFCs that define the SMI. On the 
> contrary, RFC 2578, section 7.9 says:
>    Note that with this definition of the DEFVAL clause, it is
>    appropriate to use it for any columnar object of a read-create table.
>    It is also permitted to use it for scalar objects dynamically created
>    by an agent, or for columnar objects of a read-write table
>    dynamically created by an agent.
> So when an agent is initialized it is good practice to define default 
> values for writeable objects (scalar or columnar) unless we do not 
> care what value the agent starts operating with.
> Regards,
> Dan
> *From: *  Anil R [ _mailto:[email-masked] 
> <javascript:parent.wgMail.openComposeWindow([email-masked]')>]
> *Sent: * Wednesday, October 10, 2012 2:40 PM
> *To: *  Benoit Claise
> *Cc: *  Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen 
> (IETF); [email-masked] 
> <javascript:parent.wgMail.openComposeWindow([email-masked]')>; 
> Romascanu, Dan (Dan); Joan Cucchiara
> *Subject: * Re: Benoit Claise's Discuss on 
> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
> Benoit,
> I will make a good faith attempt at responding to these comments yet 
> again, although I have already responded to many of them (other than 
> new ones that just showed up in the latest round).
> The DEFVAL comment is one which keeps coming back, disregarding my 
> many responses that this is not a useful construct for scalar objects 
> and its chief purpose is to give a default value to tables objects 
> missing in the creation of a table instance, as described in its 
> definition "The DEFVAL clause, which need not be present, defines an 
> acceptable default value which may be used when an object instance is 
> created."
> DEFVAL need not be present even in table objects, but definitely 
> should not be present in scalar objects - but the latter is what 
> several of these comments are insisting upon. It is the protocol 
> specification that defines default values for protocol objects, not MIBs.
> Regards,
> Anil
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Oct 2012 13:13:52 +0200

Hi,

I think the issue boils down to the question whether the scalars are
dynamically created by an agent or not. e.e., they come into existance
as a side effect of setting some other object. In such situations,
DEFVALs are useful to document which value a management system may
expect to be held in the newly established scalar (but note also that
the DEFVAL clause is not binding; the value is used "at the discretion
of an agent when an object instance is created" - a conservative
management application will thus check the value anyway if it is
important).

/js

On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote:
> Now, we received some push back from Anil, the author, on the
> required DEFVAL for scalar.
> As I wrote below, I always considered the DEFVAL for scalar to be
> useful information, but I understand both arguments.
> - DEFVAL for scalar objects are nice-to-have, and it's good practice
> to have them
>     This is in line with
> 
> 2. If you are the SNMP agent, it's true that the SNMPset contains
> the value to be set, so you don't need the DEFVAL.
> useful information to have default values. It's pretty nice when a
> NMS GUI contains the DEVAL value. Sure you can tell that, by looking
> at the specifications, someone will be able to get this value. In
> practice, is it done? So if the GUI developers could directly get
> the information from the DEFVAL, that's a plus.
> guiding an implementor to the section of the protocol RFC where he
> can find more information about the object and its default, if
> applicable.
> (*) time consuming if I take the case 4 above, i.e. my customer
> support engineer.
> 
> I want to publicly thanks Joan for the time spent on her review.
> Much appreciated.
> Now, I would like to have some consistency from the MIB doctors in
> terms of guidelines on this topic. Let me discuss with them.
> 
> 
> Regards, Benoit.
> 
> >Dan,
> >
> >hence the "appropriate" versus "permitted" language in the
> >definition of the DEFVAL clause for these two cases.
> >
> >When a set operation is performed on a scalar object, it comes
> >with a value to write into it. The SNMP agent need not guess what
> >that value might be,  nor does it need to rely on the MIB to tell
> >it what to do.
> >
> >When a set operation is performed to create a new row in a table,
> >it may specify the value of one or more columns in that row. If
> >the SNMP agent is going to create a row, and not all column
> >objects have been specified, it is left with a dilemma: what
> >should it set as the values of those column objects? This is what
> >the DEFVAL clause allows you to do: give the agent a default value
> >for unspecified column objects. Such a dilemma does not occur for
> >setting of scalar objects.
> >
> >If what you were saying is true, then every read-write object in
> >every MIB would need a DEFVAL clause. Clearly that is not the
> >case.
> >
> >guiding an implementor to the section of the protocol RFC where he
> >can find more information about the object and its default, if
> >applicable.
> >
> >I need to disagree with you on this. The DEFVAL function is the
> >same for a scalar and for a columnar object – as you well put it
> >‘the agent can deduce the missing value from the MIB syntax’.
> >I do not understand your argument that the implementor should look
> >at the protocol specifications to in the case of scalar objects.
> >We are talking about writeable objects. Whatever the agent
> >initializes with will be sent to the instrumentation. In the
> >absence of a DEFVAL value anything can be written there. The same
> >as in the case of a columnar object the DEFVAL will indicate the
> >value the agent initializes with which will be the first value to
> >be sent to the instrumentation until a setRequest command changes
> >it. Why should the agent implementor need to look in the protocol
> >specifications and not help him defining DEFVAL clauses?
> >Regards,
> >Dan
> >*Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms;
> >Bert Wijnen (IETF); [email-masked]; Joan Cucchiara
> >Sure I know it is permitted for scalar objects, as that will not
> >cause a compile error.
> >syntactically and practically useful to do so in such cases,
> >because the agent can deduce the missing value from the MIB
> >syntax. It makes the protocol more efficient. I know this is why
> >we added DEFVAL, based on my interaction at the time with the
> >original SNMP authors (Jeff Case, et al).
> >My point is that not only is specifying DEFVAL for a scalar
> >useless from an SNMP syntactical point of view - because an agent
> >cannot actually use it, other than an implementor reading the RFC
> >text - but it is actually dangerous to do so. An implementor TRILL
> >should be looking to the protocol specification (RFC6325 in this
> >case) to determine how the protocol works and what the needed
> >defaults are.
> >If the protocol decides to change a default, we shouldn't have to
> >go update the MIB.
> >Regards,
> >Anil
> >I believe that you are wrong stating that DEFVAL clauses should
> >not be present in the definitions of scalar objects, or at least I
> >could not find such a recommendations in the RFCs that define the
> >SMI. On the contrary, RFC 2578, section 7.9 says:
> >So when an agent is initialized it is good practice to define
> >default values for writeable objects (scalar or columnar) unless
> >we do not care what value the agent starts operating with.
> >Regards,
> >Dan
> >(IETF); [email-masked] <javascript:parent.wgMail.openComposeWindow([email-masked]')>;
> >I will make a good faith attempt at responding to these comments
> >yet again, although I have already responded to many of them
> >(other than new ones that just showed up in the latest round).
> >many responses that this is not a useful construct for scalar
> >objects and its chief purpose is to give a default value to tables
> >objects missing in the creation of a table instance, as described
> >in its definition "The DEFVAL clause, which need not be present,
> >defines an acceptable default value which may be used when an
> >object instance is created."

> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 11 Oct 2012 13:35:42 +0200

Agree.
I consider it a nice to have for scalars, but we have
approved quite a few MIB modules that did not have it
for (all) scalars. So we betterbe a bit flexible on
this point. We can recommend that they do it where it
makes sense. I would not hold up a MIB module for too
long if they resist/reject (certainly if they have
good arguments).

Bert

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 11 Oct 2012 11:02:28 -0400

For THIS specific review most scalars (one exception is 
rbridgeBaseTrillVersion) have
DEFVALs specified in the protocol (RFC6325).   Not
all protocol specifications do specify default values as clearly as this 
specification does. When default values are specified in the protocol (RFC) 
as is mostly the
situation being discussed here with the scalars, I think DEFVALs SHOULD be 
put
into the MIB.   I would like to say MUST, but believe Bert and Juergen have
pointed out that there is precedence to flexible on this.

Please note, however, if these DEFVALs which have been specified by the 
RFC6325 were
in the MIB, they could be interpreted/compiled by tools which process MIBs
and this reduces error and assists in promoting interoperability.   All in 
all, better for
the MIB's deployment and better for the WG to promote the protocol.

Thanks,
  -Joan

----- Original Message ----- 
From: "Bert Wijnen (IETF)" <[email-masked]>
To: "Benoit Claise" <[email-masked]>; "MIB Doctors (E-mail)" 
<[email-masked]>
Sent: Thursday, October 11, 2012 7:35 AM
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 11 Oct 2012 17:17:43 +0200

That sounds very plausible Joan.
So if it IS the case that it defined in the protocol spec
then WHY the heck is Anil pushing back so much.
After all, it is quite simple/easy to add a DEFVAL line.

Bert

On 10/11/12 5:02 PM, Joan Cucchiara wrote:
>
> For THIS specific review most scalars (one exception is rbridgeBaseTrillVersion) have
> all protocol specifications do specify default values as clearly as this specification does. When default values are specified in
> the protocol (RFC) as is mostly the
> situation being discussed here with the scalars, I think DEFVALs SHOULD be put
> Please note, however, if these DEFVALs which have been specified by the RFC6325 were
> and this reduces error and assists in promoting interoperability.   All in all, better for
> ----- Original Message ----- From: "Bert Wijnen (IETF)" <[email-masked]>
> To: "Benoit Claise" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Oct 2012 17:27:02 +0200

> After all, it is quite simple/easy to add a DEFVAL line.
The time spent arguing is a bigger than just editing the DEFVAL.

If the RFC is now obsolete, the REFERENCE points to an obsoleted 
reference...

Regards, Benoit.
>> all protocol specifications do specify default values as clearly as 
>> this specification does. When default values are specified in

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Oct 2012 10:34:46 -0700

Hi -

> Sent: Thursday, October 11, 2012 4:35 AM

I largely agree, but I think the case for including DEFVALs (because
they're merely advisory) is strongest in the cases where if the
instrumentation implementor (who is not always as familiar with the
stuff being managed as one might like!!!) guesses incorrectly what
value to instantiate, the results might have adverse operational
impact.  If it really doesn't matter what value the implementor picks,
then a DEFVAL has little point.  (Though in that case, one might also
ask why the information is being made visible to management.)  If
the choice of value *does* matter operationally, then a DEFVAL is
a very good idea.    If it's a grey case, better safe than sorry, IMO.

Randy

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 11 Oct 2012 20:27:13 +0000

>From my perspective, using the DEFVALs are orthogonal to being "an expert with the spec" when implementing things; its a matter of convenience and also "fat finger"-proof.  On the NMS side it also gives a great hint for a default value in a provisioning field. I am honestly perplexed as to why Anil is pushing back on the DEFVAL myself. I am with Joan on this one. I'd go further and require it in the description too, so as to explain why its there (or a reference to the spec).

--Tom

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 11, 2012 5:26 AM
To: "MIB Doctors (E-mail)" <[email-masked]<mailto:[email-masked]>>
Subject: [MIB-DOCTORS] DEVAL for scalar object (was: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT))

MIB doctors,

Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your numerous review of this MIB, which I fully support.

Now, we received some push back from Anil, the author, on the required DEFVAL for scalar.
As I wrote below, I always considered the DEFVAL for scalar to be useful information, but I understand both arguments.
Read the email exchange below.

I'm in favor of telling:
- DEFVAL for scalar objects are nice-to-have, and it's good practice to have them
    This is in line with
RFC 2578, section 7.9 says:

- If you don't put DEFVAL for scalar objects, then insert in the description a pointer on where to find the information

Regards, Benoit.

-------- Original Message --------
Subject:        Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Date:   Thu, 11 Oct 2012 11:11:30 +0200
From:   Benoit Claise <[email-masked]><mailto:[email-masked]>
To:     Anil Rijhsinghani <[email-masked]><mailto:[email-masked]>
CC:     Romascanu, Dan (Dan) <[email-masked]><mailto:[email-masked]>, Donald Eastlake <[email-masked]><mailto:[email-masked]>, Erik Nordmark <[email-masked]><mailto:[email-masked]>, Ralph Droms <[email-masked]><mailto:[email-masked]>, Bert Wijnen (IETF) <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, Joan Cucchiara <[email-masked]><mailto:[email-masked]>, me <[email-masked]><mailto:[email-masked]>

Anil, Dan,

1. If you are the implementor, you must know the spec by heart, and obviously, these scalar DEFVAL's are not useful to you.
2. If you are the SNMP agent, it's true that the SNMPset contains the value to be set, so you don't need the DEFVAL.
3. If you are the network operator using the NMS GUI , it's pretty useful information to have default values. It's pretty nice when a NMS GUI contains the DEVAL value. Sure you can tell that, by looking at the specifications, someone will be able to get this value. In practice, is it done? So if the GUI developers could directly get the information from the DEFVAL, that's a plus.
I've seen to many GUIs where the first config page allows to enter almost anything. And the network operator just puts random values in there. In the world of NetFlow, inserting non-sense timeout values produced some funny results.
4. If you are none of the above... Once upon a time, I was a NMS customer support engineer, and I read many MIB modules.
And the DEFVAL always helped getting the default values. If nothing else, for troubleshooting.
And no, I didn't know (and didn't want to know) all the protocol specification details of the feature/protocol to be managed.

How to more forward?
> By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable.
That's good information already, and I could leave with that. It's actually just a (*) level of indirection

(*) time consuming if I take the case 4 above, i.e. my customer support engineer.

I want to publicly thanks Joan for the time spent on her review. Much appreciated.
Now, I would like to have some consistency from the MIB doctors in terms of guidelines on this topic. Let me discuss with them.

Regards, Benoit.

Dan,

An SNMP set operation is used to change the value of a read-write object, or to create a new row in a table. There is a distinct difference between the applicability of DEFVAL in these two cases, hence the "appropriate" versus "permitted" language in the definition of the DEFVAL clause for these two cases.

When a set operation is performed on a scalar object, it comes with a value to write into it. The SNMP agent need not guess what that value might be,  nor does it need to rely on the MIB to tell it what to do.

When a set operation is performed to create a new row in a table, it may specify the value of one or more columns in that row. If the SNMP agent is going to create a row, and not all column objects have been specified, it is left with a dilemma: what should it set as the values of those column objects? This is what the DEFVAL clause allows you to do: give the agent a default value for unspecified column objects. Such a dilemma does not occur for setting of scalar objects.

If what you were saying is true, then every read-write object in every MIB would need a DEFVAL clause. Clearly that is not the case.

By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable.

Regards,
Anil

 Hi Anil,

I need to disagree with you on this. The DEFVAL function is the same for a scalar and for a columnar object – as you well put it  ‘the agent can deduce the missing value from the MIB syntax’.

I do not understand your argument that the implementor should look at the protocol specifications to in the case of scalar objects. We are talking about writeable objects. Whatever the agent initializes with will be sent to the instrumentation. In the absence of a DEFVAL value anything can be written there. The same as in the case of a columnar object the DEFVAL will indicate the value the agent initializes with which will be the first value to be sent to the instrumentation until a setRequest command changes it. Why should the agent implementor need to look in the protocol specifications and not help him defining DEFVAL clauses?

Regards,

Dan

From: Anil R [mailto:[email-masked]]
Sent: Wednesday, October 10, 2012 3:33 PM
To: Romascanu, Dan (Dan)
Cc: Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen (IETF); [email-masked]<mailto:[email-masked]>; Joan Cucchiara
Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)

Dan,

Sure I know it is permitted for scalar objects, as that will not cause a compile error.

For columnar objects, it is actually useful, because a manager may create an instance without specifying a columnar object. So it is syntactically and practically useful to do so in such cases, because the agent can deduce the missing value from the MIB syntax. It makes the protocol more efficient. I know this is why we added DEFVAL, based on my interaction at the time with the original SNMP authors (Jeff Case, et al).

My point is that not only is specifying DEFVAL for a scalar useless from an SNMP syntactical point of view - because an agent cannot actually use it, other than an implementor reading the RFC text - but it is actually dangerous to do so. An implementor TRILL should be looking to the protocol specification (RFC6325 in this case) to determine how the protocol works and what the needed defaults are.

We don't to define defaults in two different RFCs if we can help it.
If the protocol decides to change a default, we shouldn't have to go update the MIB.

Regards,
Anil

Hi Anil,

I believe that you are wrong stating that DEFVAL clauses should not be present in the definitions of scalar objects, or at least I could not find such a recommendations in the RFCs that define the SMI. On the contrary, RFC 2578, section 7.9 says:

So when an agent is initialized it is good practice to define default values for writeable objects (scalar or columnar) unless we do not care what value the agent starts operating with.

Regards,

Dan

From:   Anil R [ mailto:[email-masked]<javascript:parent.wgMail.openComposeWindow([email-masked]')>]
Sent:   Wednesday, October 10, 2012 2:40 PM
To:   Benoit Claise
Cc:   Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen (IETF);   [email-masked]<javascript:parent.wgMail.openComposeWindow([email-masked]')>; Romascanu, Dan (Dan); Joan Cucchiara
Subject:   Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)

Benoit,

I will make a good faith attempt at responding to these comments yet again, although I have already responded to many of them (other than new ones that just showed up in the latest round).

The DEFVAL comment is one which keeps coming back, disregarding my many responses that this is not a useful construct for scalar objects and its chief purpose is to give a default value to tables objects missing in the creation of a table instance, as described in its definition "The DEFVAL clause, which need not be present, defines an acceptable default value which may be used when an object instance is created."

DEFVAL need not be present even in table objects, but definitely should not be present in scalar objects - but the latter is what several of these comments are insisting upon. It is the protocol specification that defines default values for protocol objects, not MIBs.

Regards,
Anil

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 11 Oct 2012 20:32:00 +0000

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 11, 2012 11:27 AM
To: "Bert Wijnen (IETF)" <[email-masked]<mailto:[email-masked]>>
Cc: "MIB Doctors (E-mail)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object

> By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if appl…

If the RFC is now obsolete, the REFERENCE points to an obsoleted reference...

If the RFC in question is obsolete, then what protocol(s) is/are the MIB managing?!

--Tom

Regards, Benoit.
Bert

Thanks,
  -Joan

----- Original Message ----- From: "Bert Wijnen (IETF)" <[email-masked]><mailto:[email-masked]>
To: "Benoit Claise" <[email-masked]><mailto:[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]><mailto:[email-masked]>
Sent: Thursday, October 11, 2012 7:35 AM
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object

Agree.

Bert

/js

I'm in favor of telling:

Regards, Benoit.

-------- Original Message --------
Subject: Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Date: Thu, 11 Oct 2012 11:11:30 +0200
From: Benoit Claise <[email-masked]><mailto:[email-masked]>
To: Anil Rijhsinghani <[email-masked]><mailto:[email-masked]>
CC: Romascanu, Dan (Dan) <[email-masked]><mailto:[email-masked]>, Donald Eastlake
<[email-masked]><mailto:[email-masked]>, Erik Nordmark <[email-masked]><mailto:[email-masked]>, Ralph Droms
<[email-masked]><mailto:[email-masked]>, Bert Wijnen (IETF) <[email-masked]><mailto:[email-masked]>,
[email-masked]<mailto:[email-masked]>, Joan Cucchiara <[email-masked]><mailto:[email-masked]>, me
<[email-masked]><mailto:[email-masked]>

Anil, Dan,

How to more forward?

Regards, Benoit.

Dan,

Regards,
Anil

Hi Anil,
Bert Wijnen (IETF); [email-masked]<mailto:[email-masked]>; Joan Cucchiara

Hi Anil,
<javascript:parent.wgMail.openComposeWindow([email-masked]')><javascript:parent.wgMail.openComposeWindow([email-masked]')>]
(IETF); [email-masked]<mailto:[email-masked]> <javascript:parent.wgMail.openComposeWindow([email-masked]')><javascript:parent.wgMail.openComposeWindow([email-masked]')>;
specification that defines default values for protocol objects,
not MIBs.
Regards,
Anil

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mib-doctors

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 12 Oct 2012 07:52:15 +0900

I agree that the DEFVAL in in this case will make the document
better.

 > On (2012/10/12 0:17), Bert Wijnen (IETF) wrote:
Right. With no hard feelings, Anil and/or the WG should explain
that. Procedural issues like "You did not do say it before" or
"there are precedences" do not count as good reasons. The focus
is on producing a better document. The MIB-Doctor is trying to
help make the document better.
> Bert
Glenn

---

From: Benoit Claise <[email-masked]>
Date: Sun, 14 Oct 2012 23:32:01 +0200

On 11/10/2012 22:32, Thomas Nadeau wrote:
>
>
> From: Benoit Claise <[email-masked] <mailto:[email-masked]>>
Point taken ;-)

Regards, Benoit
>>>     all protocol specifications do specify default values as clearly
>>>     as this specification does. When default values are specified in
>>>>>>>     <mailto:[email-masked]>

---

From: Benoit Claise <[email-masked]>
Date: Sun, 14 Oct 2012 22:50:52 -0700

Tom,
> If the RFC in question is obsolete, then what protocol(s) is/are the 
Point taken ;-)
I was more thinking about the second maturity level fro, RFC6410

Regards, Benoit