Subject: Re: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-00

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 10 Feb 2014 03:20:23 +0000

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?
 
> (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."

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Feb 2014 11:24:57 +0000

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-masked]]
> Sent: יום ב 10 פברואר 2014 05:20
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-
> probstate-reqs-00
> 
> Hi Dan,
> 
> 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.
> >
> "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/ ? 

> > PROPOSED RESOLUTION: reject – we are talking about the computed
> > network status
> 
> "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.
> 
> "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'.

---

From: Bert Greevenbosch <[email-masked]>
Date: Sat, 15 Feb 2014 03:48:41 +0000

Hi Dan,

Thank you for your response. Please find my answers inline.

Best regards,
Bert

> s/asynchronous transaction/asynchronous (event-driven) transaction/ ?

How about adding "(e.g. traps in SNMP)"?

> > > implemented on C0 devices

Hmm, still a bit confused. As far as I can see, the requirement doesn't say anything about rollback. Maybe I am missing that it is implied somewhere?

For traps, I think constrained devices would be well able to do this. In the CoMI draft we provide such functionality using CoAP's observe mechanism.

What do you think?

> > If this is what is meant, maybe the description could reflect this,
> e.g. by
> > adding "analyse" as follows:
> >
> > NEW:
> >

OK, please use the 'z'. :-)