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

The patient merit is all yours
More inline

Thanks

Eduardo

-----Original Message-----
From: Randy Presuhn [mailto:[email protected]] 
Sent: Tuesday, April 13, 2004 10:13 PM
To: [email protected]
Subject: Re: [ipcdn] 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.
<edo1>
Perhaps that will be a good compromise, a read only scalar on relevant
tables, 
will propose the objects for relevant cases 5..8.


-- From an SMI implementation POV I would rather prefer defining most of

   this 'capabilities' in the context of templates via device/model 
   AGENT-CAPABILITIES. What I recall is thatt this toolkit is not being
used 
   intensively by vendors and Management applications (maybe I am
wrong), 
   to top it off, there is no a VARIATION clause for objects persistence
regardless of SWYNTAX, 
   then I gave up.... 
</edo1>
...
> <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.

<edo1>
Totally agree, didn't want to say that explicitely, due the lack of
normalization model for configuration tools
Coexistence. e.g spinlocks work for SNMP users collitions but are not
extended to CLI or future netconf .

Visualizing SNMP not as the facto core internal/storage data model
implementation, and rather closed to CLI high level, I do not see
relevance in dig a lot in updated values due CLI simultaneous
operations. I believe from vendors POV CLI can override SNMP but not
always the inverse, that's why try to avoid a) in the context of other
management tools like CLI.

I say stay with option b) as indicate in the alternatives previously 

"An alternative: 

1. If a modulation profile is being referenced by one or more
   upstream channels, an attempt to set the value of 
   docsIfCmtsModChannelType returns 'inconsistentValue' error.

2. If a modulation profile is being referenced by one or more
   upstream channels, an attempt to set docsIfCmtsModControl
   to destroy(6) or notInService(2) returns 'inconsistentValue'
   error.
"

</edo1>

...
> > 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.

<edo1>
Yes, it was introduced in draft 02 published almost two years ago.
Perhaps having a set of scalars ( or a user profile (following one of
your comments below) replicating the docsIfUpstreamChannelTable entries
plus the cloneFrom and Update objects will look more sanitized, I guess
the decision was taken back in that way.
</edo1>

> </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.

<edo>
Correct... 
</edo1>

> 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.

<edo>
Will have another iteration today
</edo>

...
> > 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".  :-)
<edo1>
sounds better, will do
</edo>
...
> 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.

<edo1>
Will replicate that
</edo>
...
> 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.
<edo1>
See above, same reasons it is since draft 02, with clarified language in
draft 09
</edo1>
...
> 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.  :-)
<edo>
Your rights....
</edo1>
...
> > 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.)

<edo1>
I do not imagine an IfIndex VACM schema, being ifIndex an unique
sub-oid. Or have to be done on an entry basis 
</edo1>

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.

<edo1>
Yes a profile mechanism would be cleanest way -see above- 
Although, I will not consider the collision something will ever happen
from an operator policy perspective, rather a centralized policy manager
to allow Upstream/downstream changes due the fact that may cause serious
service disruption. Therefore, the MIB simplicity allows simple
centralized poilicies, sort of Deny-all-/Allow-exclusive- 

I know this is not the best architecture, but is reasonable as far as
the IPDCN group concens.
Perhaps a topic for a next MIB version. 
  
</edo1>
...
> > 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.

<edo1>
I see your point, lately I am more confused if follow RFC 3416 or other
examples that may not concur with that.
We took the aproach of catch all to leave the MAC/PHY layers implements
freely their verification algorithms which may varies.
'InconsistentValue' can be used if no other outstanding opinion is
presented. 
</edo1>

> > 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.

<edo1>
Will propose the change
</edo1>

> 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.

<edo1>
Not disagree, as I said configuration parameters, logs, and time-of-day
are status objects not configuration parameters. For the benefit of flat
SNMP MIB introspection for persistence sa I said I can try to propose
other storage Type objects for cases 5..8 as noted above
</edo1>

> 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

<edo1>
   Any operator voice?
</edo1>

...
> > 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.
<edo1>
Any example or I assume all new MIB designs consider the StorageType by
default.

</edo1>
...

Randy



_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn