Subject: [MIB-DOCTORS] Fwd: Request to add to the MIB boilperplate for "writeable objects"

From: Benoit Claise <[email-masked]>
Date: Thu, 05 Jun 2014 14:01:34 +0200

Dear MIB-doctors,

Here is a proposal from Adrian on updating the MIB boilerplate.
This looks good to me. Any feedback?

Regards, Benoit

-------- Original Message --------
Subject: 	Request to add to the MIB boilperplate for "writeable objects"
Date: 	Wed, 4 Jun 2014 17:06:16 +0100
From: 	Adrian Farrel <[email-masked]>
Reply-To: 	<[email-masked]>
To: 	<[email-masked]>

Hi Benoit,

After the work on the BFD MIB modules and considering the IESG statement on
writeability, would you consider adding to the MIB boilerplate an optional piece
of text that says...

====
The following objects in the MIB modules in this document have write access
either through read-write or read-create MAX-ACCESS clauses. The level of access
to these objects have been discussed by the <xxxx> working group and it was
concluded that write access was beneficial for the following reasons:

- <list of reasons>

- <list of objects>

As with all MIB modules, an attempt to SET or CREATE an object to a value that
is not supported by the implementation will result in a failure using a return
code that indicates that the value is not supported.

====

I think this would help to contain and control work on MIB documents in the
future, and would give the Doctors something to review against.

Please wordsmith to your heart's content.

Ciao,
Adrian

.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Jun 2014 12:20:34 +0000

See in-line.

Regards,

Dan

From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Thursday, June 05, 2014 3:02 PM
To: MIB Doctors (E-mail)
Cc: Adrian Farrel
Subject: [MIB-DOCTORS] Fwd: Request to add to the MIB boilperplate for "writeable objects"

Dear MIB-doctors,

Regards, Benoit

-------- Original Message --------
Subject:

Request to add to the MIB boilperplate for "writeable objects"

Date:

Wed, 4 Jun 2014 17:06:16 +0100

From:

Adrian Farrel <[email-masked]><mailto:[email-masked]>

Reply-To:

<[email-masked]><mailto:[email-masked]>

To:

<[email-masked]><mailto:[email-masked]>

Hi Benoit,

of text that says...

n

n  Where is this text planned to be added? - Security considerations?

====

- <list of reasons>

- <list of objects>

n     I am not sure that we need this paragraph. A compliant implementation will do what is supposed to do. Moreover, this is not about 'value not supported' but about trying to write objects that are not writeable - the error codes are different.

====

Ciao,

Adrian

.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 14:35:54 +0200

> concluded that write access was beneficial for the following reasons:

I wonder why this belongs into the security considerations
section. This is a design decision, only marginally related to
security considerations.

> As with all MIB modules, an attempt to SET or CREATE an object to a
> value that is not supported by the implementation will result in a
> failure using a return code that indicates that the value is not
> supported.

This is all regulated in RFC 3416. I fail to see why this now have to
repeat this in security considerations (12 years after RFC 3416 got
published and lots of MIB modules got published).

> future, and would give the Doctors something to review against.

Security considerations are IMHO the wrong place to document IETF
policies. I do not think the security properties of SNMP have changed
and I also believe the recent IESG statement was not motivated by
security concerns.

/js

-- 
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: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 5 Jun 2014 11:30:33 -0400

I agree. This is just swimming around the drain. We need to just emphatically stop r-w and be done with this issue. 

	--Tom

> Adrian Farrel <[email-masked]>
> Reply-To:
> <[email-masked]>
> To:
> <[email-masked]>
>  
> 
> Hi Benoit,
>  
> n     I am not sure that we need this paragraph. A compliant implementation will do what is supposed to do. Moreover, this is not about ‘value not supported’ but about trying to write objects that are not writeable – the error codes are different. 
>  
> ====
>  
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 17:49:18 +0200

> 	I agree. This is just swimming around the drain. We need to just emphatically stop r-w and be done with this issue. 

And I disagree with that. There are legitimate reasons for r-w and the
IESG statement is not generally banning r-w either.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Jun 2014 15:55:01 +0000

+1 to what Juergen says. The boilerplate change should reflect what the IESG stated. It's just that the text has some words that are not necessary (last paragraph) and it does not seem to belong to Security Considerations, so we need to find it another place ('Read-Write Considerations' section?)

Dan

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, June 05, 2014 6:49 PM
> To: Thomas D. Nadeau
> Cc: Romascanu, Dan (Dan); MIB Doctors (E-mail); Farrel Adrian
> Subject: Re: [MIB-DOCTORS] Fwd: Request to add to the MIB boilperplate for
> "writeable objects"
> 
> > 	I agree. This is just swimming around the drain. We need to just
> emphatically stop r-w and be done with this issue.
> >
> 
> And I disagree with that. There are legitimate reasons for r-w and the IESG
> statement is not generally banning r-w either.
> 
> /js
> 
> --

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 5 Jun 2014 08:55:09 -0700

+1. What Juergen said.

> with all MIB modules, an attempt to SET or CREATE an object to a value that

>code that indicates that the value is not supported.

No kidding? Sometimes agent even crash. This is tutorial material.

Mike

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jun 2014 09:21:48 -0700

Hi,

Getting back to the original question:

  s/attempt to SET or CREATE/attempt to SET/

SNMP does not have a CREATE PDU AFAIK.

On your new thread: +1 for no statement on read-write use.

Somebody implementing the SMIv2 to YANG translation (RFC 6643)
asked me this week how to deal with read-write in YANG.
The mapping is read-only, so I told him out-of-scope ;-)
There is no mapping in YANG. IMO a bug, not a feature.
We have an extension statement to provide read-write semantics in YANG.
IMO SMIv2 read-write closely describes the semantics YANG needs
for 'system-owned' config data.

Andy

On Thu, Jun 5, 2014 at 8:55 AM, Michael MacFaden <[email-masked]> wrote:

>> > either through read-write or read-create MAX-ACCESS clauses. The level
>> of
>> > access

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 18:34:32 +0200

> for 'system-owned' config data.

This is getting off topic but the reasons why this is read-only are
explained in Section 11 of RFC 6643.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jun 2014 09:44:25 -0700

> explained in Section 11 of RFC 6643.

fair enough, but...

The IESG is saying use NETCONF for new stuff and it's OK to
keep using SNMP read-create and read-only when there is good cause.
But there is no transition strategy to move from row-based SNMP to
datastore-based NETCONF, for writable objects.

The fact that a large vendor is attempting to implement the
translation for writable objects suggests a migration strategy is needed.

Andy

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 5 Jun 2014 12:45:06 -0400

Of course, which is why this statement is not very useful. *)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 18:55:27 +0200

> translation for writable objects suggests a migration strategy is needed.

For the configuration of an SNMP agent, the NETMOD WG has written a
data model.  Perhaps someone needs to sit down and look at how many
other IETF SNMP configuration MIB modules are widely implemented and
need a similar action. I assume this is a rather small set - but I may
be wrong. I assume the problem would be much harder for say the IEEE.

For vendors with vendor specific MIB modules, the situation is likely
a bit different (hopefully simpler) because a vendor presumable
understands how their writable SNMP agents deal with persistency. The
problem is harder for IETF MIB modules since implementations can use
very different persistency models (and this is what SNMP allows).

/js

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 16 Jun 2014 16:04:36 -0400

+1

David Harrington
[email-masked]
+1-603-828-1401

> From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of
> Juergen Schoenwaelder
> Sent: Thursday, June 05, 2014 11:49 AM
> To: Thomas D. Nadeau
> Cc: Farrel Adrian; MIB Doctors (E-mail)