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

[Bert Greevenbosch <[e-mail]>]

Hi Dan,

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

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

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

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

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?

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

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