RE: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1

["Eduardo Cardona" <[e-mail]>]

Juergen, 
Thanks for the detail responses, Please find some extra comments inline

Thanks

Eduardo

-----Original Message-----
From: Juergen Quittek [mailto:[e-mail]] 
Sent: Monday, July 05, 2004 3:51 AM
To: Eduardo Cardona; Randy Presuhn; [e-mail]
Cc: [e-mail]
Subject: RE: [ipcdn] Re: [Disman] WG last
callondraft-ietf-disman-remops-mib-v2-01.txt Part1


Eduardo,

Many thanks for your comments.
Please find some replies inline.

--On 22.06.2004 11:42 Uhr -0600 Eduardo Cardona wrote:

> Thanks Jurgen for adding the Minimal compliance in the new draft
>
> Few comments:
>
> Draft is not indicating in upper header that is obsoleting RFC 2925

I think the RFC editor will take care of this issue.  I did not dare yet
using an "Obsoletes:" entry in the header while having an "Expires:"
entry in the line below :-)

- OK 


> DISMAN-PING-MIB
>
> Since the objects are carried from a previous RFC, The extra comments
> I got for objects are not critical, although I went to the exercise of

> understanding and may worth for direct clarifications to me if I 
> misunderstood them
>
> Please pay special attention to the new minimum compliance modules
> comments (under ****)
>
>
> pingCtlTrapGeneration
> I see a lot of overlapping in between probeFailures and TestFailures
> because both are within a ping Test. Making that very punctual for 
> notification stand point
>
> One approach (two layers) could be that TestFailure notification is
> only sent after multiple Test Failures

Exactly this is the case, see pingCtlTrapTestFailureFilter.
Or did I get something wrong?

 - See next comment

> ( based on the Frequency object may
> indicate reasonable periods of hosts disconnection) so you can avoid
> getting ProbeFailure notification but use this counter for accumulate 
> Test failures, then collect notifications only for Test failures 
> periods
> -probeFailure(0) set to '0'. In the other hand setting probeFailure(0)
> to '1' will get the time details of the probe failures that constitute
a
> Test failure.

I don't really get this.  We have a counter for probe failures and a
counter for test failures.  Both can be switched on and off
independently by setting the corresponding bits in
pingCtlTrapGeneration.

- I agree that this should be the intention; probably some terms are not
used exactly
pingCtlTrapTestFailureFilter says 
                      "...a pingTestFailed NOTIFICATION is
           generated only when the number of ping failures
           within a test exceed the value of
           pingCtlTrapTestFailureFilter."

pingCtlFrequency  says:
           "...
           A value of 0 for this object implies that the test
           as defined by the corresponding entry will not be
           repeated."

"within a test" above seems to be associated to a "test" (a set of ping
probes) not a consecutive number of tests as per CtlFrequency > 0 will
imply

Another variant will be that instead of saying
ProbeFailures =  3
TestFailures = 4 
Japanesse notation:  O ok X fail ( with your assumption below that all
probes in test means failure ? )
Test 1: probe1: O, probe2: X, probe3: X
Test 2: probe1: X, -> TestFailure NOTIFICATION

Test1: O
Test2: X
Test3: X
Test4: X
Test5: X -> TestFailure NOTIFICATION

I think will be more interested if consecutive N Test Failed:
 It also remove the otherwise required constrain that TestFailure >
probeFailure

                      "...a pingTestFailed NOTIFICATION is
           generated only when a number of consecutive 
           test failures exceed the value of
           pingCtlTrapTestFailureFilter. After a NOTIFICATION
           is generated the test failure counter is reinitialized."

  - it is an internal implicit counter with no MIB representation, which
I think is ok

The third alternative is 
# probes per test is very long and all TestFailure and ping Probes are
within a particular test. Which I think
Does not scale well for time intervals flexibility (test vs test
frequency). / different sort of SLA needs.
But if that is the case the definitions are ok but with the hiden
constrain that TestFailure > Ping Probe (within a test)

 
  
> - also does "sucessive" means consecutive?

Let's replace "sucessive" by "consecutive".
Any objection from native English speakers?

> If Filter is set to 3
> 1)timeout, 2)timeout, 3)reply, 4) timeout, 5) timeout, 6) timeout, 7)
> reply Means ProbeFailure happen between  4) and 6)

As far as I understand the current DESCRIPTION clause,
the notification is triggered by 6).

> I think the testFailure(1) BIT  should indicate that a Test Failure is
> reached by the threshold of pingCtlTrapProbeFailure rather than 
> pingCtlTrapTestFailure. Moreover the definitions of 
> pingCtlTrapGeneration and 
> pingCtlTrapProbeFailureFilter/pingCtlTrapTestFailureFilter are 
> overlapping and probably redundant.

The bit testFailure(1) does not indicate that any failure happened, it
indicates that generation of notification in such a case is enabled.

As far as I understood the descriptions so far, a test is failed only if
all probes failed. I must admit that this is not explicitly specified.
Any comment from an implementer?

> A possible wording to illustrate the comment could be:
> "...
> For
> pingCtlTrapGeneration
> DESCRIPTION
>           "The value of this object determines when and if
>            to generate a notification for this entry:
>
>            probeFailure(0)   - Generate a pingProbeFailed
>                notification subject to the value of
>                pingCtlTrapProbeFailureFilter.
>            testFailure(1)    - Generate a pingTestFailed
>                notification. A Test Failure condition is defined
>                if within a test the number of probe failures
>                reaches the value of pingCtlTrapProbeFailureFilter
>            testCompletion(2) - Generate a pingTestCompleted
>                notification.
>
>            By default, no bits are set, indicating that
>            none of the above options are selected."
>
> pingCtlTrapProbeFailureFilter/TestFailureFilter
> the description of  pingCtlTrapProbeFailureFilter is not Clear to me
> if after the # of probe failures of the ProbeFailureFilter object are 
> reached a notification is sent and if the counter is cleared
>
> e.g.
> pingCtlTrapProbeFailureFilter  = 5
> pingCtlProbeCount = 15
> Supposed all ping probes timed out,
> Will it send notification after attempts 5, 10 and 15
> or
> After attempts 5,6,7,....15
> A possible wording could be ( only sending notifications after
> attempts 5, 10 and 15:

You are right. This case is not well specified.

> pingCtlTrapProbeFailureFilter
>            "The value of this object is used to determine when
>            to generate a pingProbeFailed NOTIFICATION.
>
>            Setting pingCtlTrapGeneration BIT probeFailure(0)
>            to '1' implies that a pingProbeFailed

I think we can omit "to '1'".

- but what it mean setting BIT probeFailure(0) setting to '1' or setting
to '0'?
  Both values are valid so I do not see that setting BITs means to UP,
ON or '1'
  eventually I missed that from SMI but I have been see other MIB
MODULES defining setting 
  BIT X to '1' or '0'
   

>            NOTIFICATION is generated only when a number of
>            successive ping probes equal to the value of
>            pingCtlTrapPrbefailureFilter fail within
>            a given ping test. Then a Test failure condition is
>            reached and the probe failure count is
>            reset for the following attempts within the
>            given ping test."

I disagree with the first part of the last sentence "Then a Test failure
condition is reached", but I agree to the rest.

 - Ok, aligned with my other clarifications proposed above

> Similar for pingCtlTrapTestFailureFilter
>            "The value of this object is used to determine when
>            to generate a pingTestFailed NOTIFICATION.
>
>            Setting pingCtlTrapGeneration BIT testFailure(1)
>            to '1' implies that a pingTestFailed NOTIFICATION is
>            generated only when the number of test failures
>            within a test exceed the value of
>            pingCtlTrapTestFailureFilter."

He also need to add a statement on reseeting the test failure counter
when the notification is sent.

- as proposed above .... But still unsure if the intention is to keep
this "within a test" as commented above (alternative 3)

                      "...a pingTestFailed NOTIFICATION is
           generated only when a number of consecutive 
           test failures exceed the value of
           pingCtlTrapTestFailureFilter. After a NOTIFICATION
           is generated the test failure counter is reinitialized."

- See the proposed 
> Above is also included a small wording for the BIT sets
>
> pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to
> conform with RFC3291 bis draft 03

Fine with me.
Any objections from the "Who needs IPv6?" community?

>
> MinimumCompliance
> *****************
>
> PingCtlRowStatus  has a compliance SYNTAX read-only; some
> clarifications in how the minimum compliance default entry All time 
> with value 'active' ? Regularly a 'notReady' entry when filled all the

> minimum object sets becomes 'notInService' and need to be set to 
> 'active'  via SNMP to complete the operation

In read-only mode it has three possible values:
  - 'notReady' as long as pingCtlTargetAddress is not specified.
  - 'notInService' starting when pingCtlTargetAddress specified until
    pingCtlAdminStatus is set to enabled(1).
  - 'active' after pingCtlAdminStatus has been set to enabled(1)
    in state 'notInService'.
  - again 'notInService' after pingCtlAdminStatus has been set to
disabled(1)
    in stat 'active'.

- About 
"'active' after pingCtlAdminStatus has been set to enabled(1)
    in state 'notInService'"

-I do not think that RowStatus TC can transition automatically from
'notInService' to 'active'
>From RowStatus State Diagram 
>From State C "setting other column to some value" -> C

- My view was that because the pre-created entry with zero indexes was
already there
No need to have to set RowStatus to active afterwards, 
I see any way the value of RowStatus as an indicator the the test
configuration is not ready,
Just quite expensive to always have to turn active, 

> a) Will the compliance statement should say that a 'notReady'  is
> automatically set to 'active' when all fields (specially when 
> pingCtlTargetAddress is set?)

No, it will automatically be set to 'notInService'.

Yes, see above 
> would that be valid request? -not included
> in the state diagram of RowStatus TC-

>From 'notInService', transitions to 'active' can only be reached
by setting pingCtlAdminStatus.
(as specified in the DESCRIPTION clause of pingCtlRowStatus). Note, that
setting pingCtlTargetAddress and pingCtlAdminStatus should still be
possible with just a single SNMP PDU.

> Or
> b) more general the pingCtlAdminStatus should indicate an error when
> attempting to start (enabled(1) the test and the entry is notReady(2) 
> /
> notInService(1) ?
>
> And probably the MinumimCompliance may need a SYNTAX clause like

Yes, this is missing.

> SYNTAX RowStatus { notReady(3), active(1)}

It should look like

  SYNTAX RowStatus { active(1), notInService(2), notReady(3)}

Probably it would be a good idea to explain the state transitions (as
described above) in the corresponding DESCRIPTION clause.

Yes, I agree just verify the RFC 2579 transition from notInService' to
active ( I may miss something)

> Object Compliances
> pingCtlFrequency r-o; last sentence "A value zero means... " may not
> be needed any case, the test is not repeated and 0 value already 
> defined In the object description

I agree that the sentence is redundant.  I thought it would help
understanding the compliancy more quickly, but I have no strong feeling
about keeping or removing the sentence.

Any further opinions?
- OK,
>From the comment in the security section redundancy  is less expensive
than ambiguity 

> Normalization of SYNTAX sub-typing as in other objects. -- Just a
> comment Up to MIB doctor for style normalization in the compliances.. 
> pingCtlStorateType can have a SYNTAX clause SYNTAX StorageType { 
> volatile(2)}

I think this is more strict.  I did not intend to exclude. for example,
'permanent' entries.

- OK, no need for that

>> From RFC 2925 the Compliance statement has under pingGroup the
>> objects
> of Ctl, Results, History and the Notification Group
>
> Since the minimal compliance has only Ctl, Results objects I think is
> better to define a MANDATORY-GROUP pingMinGroup including Ctl and 
> Results Objects. So the original group is left intact (unless specific

> compliances are needed as pingComplianceV2 (if there are important 
> differences with the original Compliance)

What about just renaming the new pingGroup to pingMinimumGroup?

- OK with me

> - Will be ok with MIB doctor perception of this compliances
> ramifications
>
>
>
> DISMAN-TRACEROUTE-MIB
>
>
> MinumumCompliance
> *****************
> Same as ping Compliances From RFC 2925 and new draft the
> traceRouteGroup has originally Ctl, Results and Probehistory Objects.
>
> The minimal compliance will just have a traceReouteMinimumGroup with
> Ctl and Results objects and leave the original group (fully compliant)

> intact.
>
>
> Same comments for traceRouteCtlFrequency and traceRouteCtlStorageType
> as for the PING minimum compliance.

OK, however we decide on the PING MIB, I will change the TRACEROUTE MIB
analogously.

Thanks,

    Juergen

>
> DISMAN-NSLOOKUP-MIB
> No issues.
>
>
> Thanks
>
> Eduardo
>
>
> -----Original Message-----
> From: Juergen Quittek [mailto:[e-mail]]
> Sent: Wednesday, June 16, 2004 3:47 PM
> To: Randy Presuhn; [e-mail]
> Cc: [e-mail]
> Subject: [ipcdn] Re: [Disman] WG last call
> ondraft-ietf-disman-remops-mib-v2-01.txt
>
>
> Dear all,
>
> I just posted a new version of the remote operation MIB modules.
> Following Eduardo's suggestion I added Minimum Compliancy statements 
> in addition to the existing full compliancy statements to each of the 
> three MIB modules.
>
> I also had to (syntactically) modify the existing compliancy
> statements. Please have a close look at all six MODULE-COMPLIANCE 
> macros.  Until the document becomes available at the I-D repository, 
> you can preview it at
>
ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib-
> v2-02.txt
>
> There was not much response on my questions on how to define the
> minimum compliance statements.  I preferred leaving read-only objects 
> in place to creating non-consecutive numbering of objects in table 
> entries.  I am not dogmatic about this and suggestions for changes are

> very welcome.
>
> For simplifying the review here is a list of objects and groups for
> which the full and minimum compliance statements differ:
>
> pingHistoryGroup,
> pingNotificationsGroup
> pingCtlDataFill
> pingCtlFrequency
> pingCtlMaxRows
> pingCtlTrapGeneration
> pingCtlProbeFailureFilter
> pingCtlTestFailureFilter
> pingCtlDescr
> pingCtlByPassRouteTable
> pingProbeHistoryTime
>
> traceRouteHistoryGroup
> traceRouteCtlByPassRouteTable
> traceRouteCtlDontFragment
> traceRouteCtlInitialTtl
> traceRouteCtlFrequency
> traceRouteCtlDescr
> traceRouteCtlMaxRows
> traceRouteCtlTrapGeneration
> traceRouteCtlCreateHopsEntries
> traceRouteCtlRowStatus
> traceRouteHopsLastGoodProbe
>
> lookupCtlRowStatus
>
> Beyond the compliance statement I just made two changes to the
> document:
>
> 1. Added new section 3.4 introducing the compliance statement
>
> 2. Extended DESCRIPTION clause of object lookupPurgeTime by one
> sentence:
>
>          "A value of 0 indicates that automatic deletion
>           of entries is disabled."
>
> Thanks,
>
>     Juergen
> --
> Juergen Quittek        [e-mail]        Tel: +49 6221
> 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221
> 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
> http://www.ccrle.nec.de
>
>
> --On 29.04.2004 14:29 h -0700 Randy Presuhn wrote:
>
>> Hi -
>>
>> Are there any objections to proceding as Juergen and Eduardo suggest?
>> I'd like to see comment (pro or contra) on the specific questions 
>> Juergen raised below.
>>
>> Randy, disman WG chair
>>
>>> From: "Juergen Quittek" <[e-mail]>
>>> To: "Eduardo Cardona" <[e-mail]>; "Randy Presuhn"
>>> <[e-mail]>; <[e-mail]>
>>> Cc: "Ipcdn List (E-mail)" <[e-mail]>
>>> Sent: Monday, April 26, 2004 1:11 AM
>>> Subject: RE: [Disman] WG last call on 
>>> draft-ietf-disman-remops-mib-v2-01.txt
>>>
>>
>>> Eduardo,
>>>
>>> Thank you for raising this issue and my apologies for this very late
>>> reply.
>>>
>>> I ran into similar problems several times where a well designed
>>> technology was too mighty or too general for being implemented at 
>>> small devices.
>>>
>>> Your suggestions aim at introducing additional MODULE-COMPLIANCE
>>> clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules 
>>> for allowing simpler implementations with smaller footprints.
>>>
>>> I support your proposal, but have a few comments, see below. I am
>>> willing to make suggestions for minimalCompliance clauses for the 
>>> MIB
>
>>> modules, but first the WG should agree on two issues:
>>>
>>>   - Is it agreed to add such clauses, that definitely require
>>>     less funtionality to be implemented?
>>>
>>>   - what is the preferred procedure for columnar objects that
>>>     are not required for minimal compliancy?  We can either
>>>     allow them to be missing completely.  But this would result
>>>     in non-consecutive numbering of the remaining objects in
>>>     the minimal tables.  Or we require them to be implemented
>>>     as read-only indicating that the feature that they would
>>>     serve in full compliancy is not supported.
>>>
>>> Please find further comments inline.
>>>
>>>     Juergen
>>> --
>>> Juergen Quittek        [e-mail]        Tel: +49 6221
> 90511-15
>>> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221
> 90511-55
>>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
> http://www.ccrle.nec.de
>>>
>>>
>>> --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote:
>>> > Randy,
>>> >
>>> > Few comments,
>>> >
>>> > I review the MIB and appears compelling respect to previous RFC
>>> >
>>> > Just one comment
>>> >
>>> >
>>> > (*) traceRouteCtlMiscOptions
>>> > It appears to me an uncanny object and rather implementations may
>>> > opt to extend the capabilities in the private branch, could leave 
>>> > with that to avoid deprecation, of if there are field 
>>> > implementations.
>>>
>>> Currently, the MODULE-COMPLIANCE clause traceRouteCompliance
>>> requests
>
>>> implementation of this object, but it may be implemented as
>>> read-only
>
>>> and returning always a value of zero, if there is not further
>>> semantics defined for it.  Do you suggest to completely remove the 
>>> object or to state in the MODULE-COMPLIANCE clause that it does not 
>>> need to be implemented?
>>>
>>> > Regardless of the additions to the MIB I apologize for the late
>>> > notice,
>>> >
>>> > Before sending a complete proposal and get your concept of the
>>> > best
>
>>> > approach, below is the proposal  to add a simplified Compliance
>>> > statement for devices not requiring to keep constant status of 
>>> > PING/TRACEROUTE operations, only remote operation per operator 
>>> > request.
>>> >
>>> >
>>> > We are looking at your comments about the clear overlap in
>>> > draft-ietf-disman-remops-mib-v2-01.txt
>>> > With IPCDN draft 
>>> > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-m
>>> > i
>>> > b-00.
>>> > txt ( currently out of date in IETF drafts site) which is clearly
a
>>> > subset of the DISMAN-PING-MIB
>>> > Lectors refer to
>>> >
> http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg0081
> 8.
>>> > html
>>> >
>>> > Should the proposal below being include in the remops MIB or
>>> > should
>
>>> > we update IPCDN cable gateway Tools MIB module to be just the
>>> > compliance statement outlined below?
>>>
>>> I doubt that it is a good idea to replicate large portions of the
>>> PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done 
>>> right now.
>>>
>>> > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null
>>> > named log" default entry for devices not supporting the named log 
>>> > Named log is analog to disman remops draft for "OwnerIndex" and 
>>> > "TestName"  where default entries are created (null owner, null
>>> > TestName) for a manager requested operation of PING/ TRACEROUTE, 
>>> > NSLOOKUP, mostly for small foot-print devices with no network 
>>> > monitoring role at the connectivity level as pretended with this 
>>> > updated RFC.
>>>
>>> I don't think the remops MIB modules forbid null-named entries in
>>> the
>
>>> respective tables.  But currently the support of a read-write
>>> pingCtlRowStatus is mandatory.
>>>
>>> Is your concrete suggestion to add something like
>>>
>>>      OBJECT XXRowStatus
>>>          MIN-ACCESS read-only
>>>          DESCRIPTION
>>>           "Implementations may disallow the creation of named
>>> entries."
>>>
>>> with XX=pingCtl,traceRouteCtl,lookupCtl?
>>>
>>> > In summary A new Compliance Statement for small devices with no
>>> > monitoring capabilities to :
>>> >  1) remove the constant pulling and login information
>>> >  2) remove the test row creation
>>> >      - CTL* Results* tables only default entries (null owner, null
>>> > TestName)
>>> >  3) History* tables not required.
>>> > - New basicGroups to exclude History* objects and other objects 
>>> > which are not relevant to the simplified
>>> >         system.
>>> >       - Create an additional set of Compliance statements to 
>>> > require the new Groups and other objects Compliance
>>> >         requirements MIN-ACCESS clauses mainly
>>> >
>>> > Schema of the content of the new Compliance statement:
>>> >
>>> >  List of objects not to include in basicPingGroupOBJECT-GROUP
>>> > clause qnd/or hints for OBJECT Compliances:
>>> >   pingMaxConcurrentRequests -- remove
>>>
>>> Could also be read-only returning 1.
>>>
>>> >   pingCtlDataFill           -- remove or MIN-ACCESS read-only
> default
>>> > value is OK
>>> >   pingCtlFrequency          -- remove Only one test
>>>
>>> Could also be read-only returning 0.
>>>
>>> >   pingCtlType               -- remove or MIN-ACCESS read-only
>>> >   pingCtlByPassRouteTable   -- remove or MIN-ACCESS read-only
>>> >   pingCtlDSField            -- MIN-ACCESS read-only
>>> >   pingCtlStorageType        -- remove
>>> >   pingCtlRowStatus          -- SYNTAX RowStatus (notReady(2)
>>> > WRITE-SYNTAX RowStatus (active(1), notInService(3)
>>>
>>> Why don't you consider removing this object?
>>>
>>> >   pingCtlIfIndex            -- not to include
>>> >   pingProbeHistory*         -- not to include.
>>> >
>>> >   List of objects not to include in basicTraceRouteGroup
>>> > OBJECT-GROUP clause and/or hints for OBJECT Compliances:
>>> >   traceRouteMaxConcurrentRequests  -- remove
>>> >   traceRouteCtlType             -- remove or MIN-ACCESS read-only
>>> >   traceRouteCtlDSField          -- MIN-ACCESS read-only
>>> >   traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only
>>> >   traceRouteCtlIfIndex          -- not to include
>>> >   traceRouteCtlMiscOptions      -- not to include
>>> >   traceRouteCtlDontFragment     -- remove or MIN-ACCESS read-only
>>> >   traceRouteCtlInitialTtl       -- remove or MIN-ACCESS
>>> >   traceRouteCtlFrequency        -- remove only one test
>>> >   traceRouteCtlDescr            -- remove
>>> >   traceRouteCtlCreateHopsEntries -- remove HopsEntries not
> required.
>>> >   traceRouteCtlRowStatus        -- SYNTAX RowStatus (notReady(2)
>>> > WRITE-SYNTAX RowStatus (active(1), notInService(3)
>>> >   traceRouteCtlStorageType      -- remove
>>> >   traceRouteProbeHistory*         -- not to include.
>>> >
>>> >   List of objects not to include in basicLookupGroup OBJECT-GROUP
>>> > clause and/or hints for OBJECT Compliances:
>>> >   lookupMaxConcurrentRequests   -- remove
>>> >   lookupPurgeTime               -- remove
>>> >   lookupCtlRowStatus            -- SYNTAX RowStatus (notReady(2)
>>> > WRITE-SYNTAX RowStatus (active(1), notInService(3)
>>> >
>>> >
>>> > Best Regards
>>> >
>>> > Eduardo
>>> >
>>> > -----Original Message-----
>>> > From: Randy Presuhn [mailto:[e-mail]]
>>> > Sent: Monday, March 01, 2004 6:44 PM
>>> > To: [e-mail]
>>> > Subject: RE: [Disman] WG last call on
>>> > draft-ietf-disman-remops-mib-v2-01.txt
>>> >
>>> >
>>> >
>>> > Hi -
>>> >
>>> >> From: Eduardo Cardona <[e-mail]>
>>> >> Sent: Mar 2, 2004 9:25 AM
>>> >> To: Randy Presuhn <[e-mail]>, [e-mail]
>>> >> Subject: RE: [Disman] WG last call on
>>> >> draft-ietf-disman-remops-mib-v2-01.txt
>>> > ...
>>> >> One simple note, I tough last call was March 5th
>>> >
>>> > No, it was supposed to end March 2.  However, I'm not going to
>>> > hand
>
>>> > it to our AD until I can be reasonably sure that it has received
>>> > adequate review.
>>> >
>>> >> We at Cablelabs are interested in adding a simplified compliance
>>> >> statement for ad-hoc procedure call instead of a user entry 
>>> >> schecule entry, so an user can do a one time execution e.g PING
>>> >
>>> > It would have been nice to have learned of this earlier, rather
>>> > than during WG last call.
>>> >
>>> >> The draft we had is almost complete,
>>> >> Would be that an opportunity to add that? I can post that
>>> >> tomorrow
>
>>> >> in the list if compeling
>>> > ...
>>> >
>>> > I'd like to have this discussion sooner rather than later, so
>>> > please make your specific proposal as quickly as you can.  My 
>>> > opinion as a technical contributor is that the case for these 
>>> > changes would need to be fairly compelling if they would result in

>>> > the remote operations MIB cycling at proposed rather than 
>>> > advancing
>
>>> > to draft standard.  As working group chair, I want to ensure that
>>> > whatever course we take reflects WG consensus.  So, balancing the 
>>> > need for bringing this to a conclusion with the need to ensure 
>>> > that
>
>>> > the technical issues are properly considered, I'll entertain
>>> > discussion of this issue ("ad hoc procedure call") until Friday 
>>> > noon (Korean Time).  Shortly thereafter I'll make a call on 
>>> > whether
>
>>> > there is consensus to modify the draft regarding this specific
>>> > proposal.
>>> >
>>> > Randy
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
>
> _______________________________________________
> IPCDN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>
>







_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn