Re: Changes for next RFI v2 MIB (draft 10)

Hi -

Thanks Edo for the patient response!  More inline below.

> From: "Eduardo Cardona" <[email protected]>
> To: "Randy Presuhn" <[email protected]>; <[email protected]>
> Sent: Tuesday, April 13, 2004 6:25 PM
> Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)
...
> Options :
> 5..8 a) as proposed (explicit vendor specific, not interoperable, with
> the precendent of read-only compliances)
>     b) turn as MUST (new requirement: sent proposal back to IPCDN group
> and DOCSIS groups for approval)
>    c) leave silent as in RFC 2670 (not introduce changes 5..8)
>
> a) or b) will be my options, I started with a) due the b) implications.

I, too,  dislike option (c).
I dislike option (a), particularly if the interoperability difficulties are
not merely theoretical.
I think there are at least three ways of accomplishing (b):
    - using the DESCRIPTION clause to mandate persistence behaviour
    - adding a (potentially read-only) StorageType to the row to
      indicate whether the information there will persist
   - adding a read-only scalar object to the MIB that reports
      whether  the table persists.

...
> <edo>
> (a) and (b);
> Not sure how (a)is put in context,  docsIfCmtsModChannelType is a
> Configuration parameter.

In some environments, SNMP is not the only possible configuration
mechanism.  For example, a CLI or netconf might be used to modify
configuration data.

...
> > CHANGE # 5
...
> (Even so, as a non-expert, it's still unclear to me what
> this sentence is supposed to mean.)
> <edo>
> Agree, Although text current text was discussed discussed in the IPCDN list
> back around October 10 to 15 (eventually closed to experts in the topic)

Since you're dealing with installed base, I'm not suggesting you change the
way it works (if it has in fact proven to be interoperable).  My comment is
just that to the non-expert, this "clone-to" mechanism seems really bizarre.
I could suggest much simpler ways to accomplish the goal, but that would
not help maintain compatibility.

> </edo>
> > 2. A status transition from active(1) to notInService(2)
> > or destroy(6) is not permitted.
>
> ??? So how DOES one get rid of these things???
> <edo>
>
> By definition an entry with status active(1) is the extension if IfTable
> For interfaces ifType 129 or 205 - regular ifTable extension-
> Those are not deleted since are hardware dependant nor created by users,

So, If I understand correctly, these things cannot be provisioned: one must
wait for the hardware to be installed before doing any configuration, rather
than setting up the parameters in advance.

> Only the non-related to ifTable interface entries ( used for clonning)
> are created with CreateAndWait and the rules 4 and 5 apply

I'd be nice if the distinction between these two entry types was made
clearer.

...
> > 3. ifAdminStatus from the Interface MIB RFC 2863 should be used to
> > take an Upstream Channel offline.
>
> I assume you mean "SHOULD".  What other mechanisms
> can take an Upstream Channel offline?
> <edo>
> Should replaced by SHOULD
> No other SNMP mechanism is defined explicitely,
> If I understood your request from the possibility of
> docsIfUpChannelStatus = notInService(2)
> Upstream channels docsIfUpChannelStatus only reports active(1)

It might be better to avoid the question by replacing "should be" with "is".  :-)

...
> The current compliance statement is hard to build since the Flavor (US
> channel interface vs Cloning entry)
> Is the one with different connotation
> IfEntry extension read active(1)
> No ifEntry extension: CreateAndWait(5), destroy(6) write

This explanation was most helpful.  I think your proposed
explanation would be useful, but that it probably should go
into BOTH the OBJECT and OBJECT-TYPE.

...
> In RFC 2670 docsIfUpChannelEntries where read-write with optional
> read-only ( no row status), just simple extension of IfTable which are
> Vendor dependant configured this extension entries are by default
> "always" Active(1)
> </edo>

Oh.  This "clone-to" stuff is new.  I'm sorely tempted to propose a
much tidier (I think) way to do it, but I don't wan't to be unduly disruptive
at the -10- draft stage of work.

...
> Will the proposed text plus  the Object compliance makes that a bit
> clear?

Your patient explanations make the intent much clearer.
Thanks.
That doesn't mean that I like it.  :-)

...
> > 1. Create a temporary row through an SNMP SET using createAndWait(5).
> > Use an ifIndex value outside the operational range of the system.
>
> How is the "operational range" determined?
> <edo>
> Out of scope, as the design was concern, you will point with all reasons
> that is not
> Good for interoperability
> Will be a scalar with a suggested initial value an option?
> it will goes beyond the closed for additions as we stand rigth now.

One of the things one would hope to avoid is that a newly inserted interface
gets a number that a management system is about to use for cloning.  It's
also hard to imagine how one could configure VACM to give different users
access to different interfaces with this sort of scheme.  This scheme also
wouldn't provide any help at all in avoiding collisions (direct or indirect).
(Two managers try to use the same row for clone-to, or worse still, two
managers use different rows to clone-to the same interface.)

The simplest thing that comes to mind, if I understand the requirements
correctly, would be to put all the clone-to stuff into an AUGMENTS table,
with a simple row "update" button to cause changes to be applied.
That way it would be trivial to ensure that the access rights were properly
restricted.  However, I haven't been in on the discussion and the use cases,
so I'm not making a proposal.  For example, a "profile" mechanism might
be a better fit.

...
> > 4. Update the physical row by setting the object docsIfUpChannelUpdate
> > to true(1). This operation fails with error genErr if the adjusted
> > parameters are not compatible with each other.
>
> My reading of RFC 3416 section 4.2.5 (10) is that inconsistentValue
> would be more appropriate.
> <edo>
> I read inconsistenValue as values that in other circumstances will be
> valid,
> e.g setting to a row while active returns inconsistentValue error but if
> the row is set to 'notInService' same set will success (RowStatus
> constrains).
> Here we had the problem that DOCSIS PHY parameters are broad and some
> implementation MAC and or PHY may not support the whole range,
> for that cases the vendor should be able do document the
> AGENT-CAPABILITIES for the implementation version or model
> </edo>

Fine, but I still believe that inconsistentValue would be the correct return.
Beyond what RFC 3416 says, take the example of RowStatus from RFC 2579.
In the state chart and notes on pages 9 and 10, the case most analogous
to this is setting the status to "active" in state "b".  The intent of "genErr"
was as a catch-all for truly pathological cases.  As I see it, this isn't one of them.

> > 5. Delete the temporary row through an SNMP SET using
> > DELETEdestroy(6). Temporary entries need not persist at
> > reinitialization of the managed system."
>
> Optional persistence isn't helpful for interoperability.  In this
> particular case, it sounds like persistence would be inappropriate,
> particularly given RFC 2579's page 16.
> <edo>
> Will be better to mandate non-persistence?

That would be fine with me.

> In any case temporary entries have no operational or configuration
> meaning after the cloning process
> is completed,

All the more reason for them to not persist.

> Perhaps:
>
> "Temporary entries SHOULD NOT persist at
>         reinitialization of the managed system."
> </edo>

I'd prefer MUST.  Otherwise, RowStatus really isn't the right thing
to use here.  (One could argue that it isn't anyway.)

...
> > MIN-ACCESS read-only for docsIfDownstreamChannelTable implies the
> > minimal implementation has no persistent requirement. Persistence
> > makes sense only in the case of MAX-ACCESS read-write support.
>
> I don't understand how you come to this conclusion.
>
> <edo>
> docsIfDownstreamChannelTable are configuration parameters, if SNMP is
> read-only by compliance,
> persistente IMHO is not a feature, Either the system uses defaults upon
> reboot or the system
> gather the parameters from a config file. (which is persistent but
> outside the scope of SNMP)

I disagree with this reasoning.  It is perfectly reasonable for read-only
management information to be persistent.  An example would be a
log entry.  It is also perfectly reasonable for read-only information to
be ephemeral.  A time-of-day clock would be an example.

> Requiring persisntece now will be a new requirement, for DOCSIS not in
> RFC 2670 nor DOCSIS spec.
> which should be considered for further work or send back the draft to
> IPCDN group discussions for approval.
> </edo>

My comment is simply that the document needs to be clear, and that
preventing a management system from being able to predict whether
a managed device will be able to remember a configuration is probably
not good for interoperability.  Presumably the members of the WG
know whether:
   - there has been any consistency among implementations here
   - whether interoperability has been impaired by this degree of freedom

...
> > CHANGE # 7
> > docsIfDownstreamChannelEntry OBJECT-TYPE
> ...
> > The CMTS ability to retain SNMP SETs for read-write values after
> > system reinitialization is implementation dependant."
>
> This is what StorageType is for.
> <edo>
> There is no read-create object for this table, it is also a ifTable
> extension (for downstream interfaces ifType 128)
> </edo>

There is no need for there to be any writeable objects in a table
with a StorageType object.  One could also use a "capabilities"
object outside the table to report whether this information can be retained.
For an example of total over-engineering, one could have a single read-only
BITS object with one bit for each of these tables, reporting whether the
implementation maintains the data persistently.

...

Randy