Hi Bert, See in-line. Thank you again for the feedback and the continuation of the dialog.
Regards, Dan > -----Original Message----- > From: Bert Greevenbosch [mailto:[email protected]] > Sent: יום ב 10 פברואר 2014 05:20 > To: Romascanu, Dan (Dan); [email protected] > Subject: RE: [OPSAWG] comments resolution for draft-ietf-opsawg-coman- > probstate-reqs-00 > > Hi Dan, > > Thanks for addressing my comments. > > I think most of your proposed resolutions are OK, so below I only give > feedback on those that need more discussion from my point of view. If I > don't give feedback to a proposed resolution, it means I agree with that > resolution (including rejection). > > Best regards, > Bert > > > > (BG13) Section 3.3, req 4.3.003: the description should be more > > verbose and explicit. > > > > PROPOSED RESOLUTION: reject – what is missing? > > The related requirement currently has the following wording: > > "Provide configuration management with asynchronous transaction support. > Configuration operations must support a transactional model, with > asynchronous indications that the transaction was completed." > > I guess my main issue with this is, that I don't really know what exactly is > meant by an "asynchronous transaction" (as it could be quite broad). Is it > just > a delayed response/acknowledgement? Or is it something like a trap, which > sends feedback whenever an event happens? > It is the later. Would it help if we clarify by making s/asynchronous transaction/asynchronous (event-driven) transaction/ ? > > (BG14) Section 3.3, req 4.3.003: why does the requirement not apply to > > C0 devices? They may be sleepy and thus require asynchronous > > transactions. > > > > PROPOSED RESOLUTION: reject – we do not believe rollback can be > > implemented on C0 devices > > Related to BG13. This would be more evident when "asynchronous > transactions" were properly defined. > > > (BG16) Section 3.4, req 4.4.004 is marked as "low priority". Isn't > > network status monitoring a major use-case? > > > > PROPOSED RESOLUTION: reject – we are talking about the computed > > network status > > The description currently is as follows: > > "Provide a monitoring function to collect and expose information related to > the status of a network or network segments connected to the interface of > the device." > > I understand that you mean that the information of the network is > processed, and exposing information does not concern just the raw > information? As an example: a counter that counts the incoming and > outgoing UDP packets seems simple enough for C0 devices. But collecting > these counters from several devices and then calculate some statistics may > indeed be more complicated. > > If this is what is meant, maybe the description could reflect this, e.g. by > adding "analyse" as follows: > > NEW: > > "Provide a monitoring function to collect, analyse and expose information > related to the status of a network or network segments connected to the > interface of the device." Fine with me with the exception that my speller asks to write analyze with an 'z'. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
