Subject: [i2rs] draft-ietf-i2rs-pub-sub-requirements-01 review

From: Benoit Claise <[email-masked]>
Date: Thu, 19 Mar 2015 14:54:06 +0100

Dear all,

-  Arguably the biggest shortcoming
    of SNMP for those applications concerns the need to rely on periodic
    polling, because it introduces additional load on the network and
    devices, is brittle in case polling cycles are missed, and is hard to
    synchronize and calibrate across a network, making data obtained from
    multiple devices less comparable.

The DISMAN WG produced in the past the RFC 2981 and RFC 2982 to avoid the polling issue,
but the event and expression MIBs never took off. These were hard to configure

-
    A Subscription Request for one or more YANG subtrees made by the
    Subscriber of a Publisher and targeted to a Receiver.  A Subscription
    MAY include constraints which dictates how often or under what
    conditions YANG subtree updates might be sent.
    ...
    An Update provides object changes which have occurred within
    subscribed YANG subtree(s).

Is this always a subtree? Could it a single leaf?

- You should have requirements in the terminology section, specifically as you have a requirement section.

    A Subscription Request for one or more YANG subtrees made by the
    Subscriber of a Publisher and targeted to a Receiver.  A Subscription
    MAY include constraints which dictates how often or under what
    conditions YANG subtree updates might be sent.

- On the use of MUST, SHOULD, etc. keywords in requirements document, it's preferable to use lower case because these are not RFC 2119 keywords.
The alternative is to stress the specific meaning of those keywords in this document.

-
    A Subscriber MAY provide QoS criteria to the Subscription Service
    such that if the Subscription Service is unable to meet those
    criteria, the Subscription should not be established.

    A Subscription Service SHOULD be able to interpret Subscription
    Requests QoS Policy requests, and only establish a Subscription if it
    is possible to meet the QoS those QoS Policy requests.

At first glance, I thought you wanted to have a one-way delay type of end to end QoS metric
(between the subscriber and publisher). This is complex.
Then I saw:
    A Subscription Service SHOULD be able to negotiate QoS criteria for a
    Subscription.  Examples of QoS criteria MAY include reliability of
    the Subscription Service, reaction time between a monitored YANG
    subtree/object change and a corresponding notification push, and the
    Subscription Service's ability to support certain levels of object
    liveliness.

You want to be precise with the QoS definition scope in this document.
It's only when I read section 4.2.6 that I understood your QoS definition.
In the end, I believe a forward pointer is all that is needd

- What about the notion of time in pub/sub?

One typical problem with SNMP polling is polling different variables at the same time (interface counter, QoS counter, for example).

This is solved in SNMP by combining those OID in a single PDU. How is it done with pub/sub? Actually, the right question is: what is the requirement?

-

    If on-change updates were
    requested with a dampening period, the minimum acceptable dampening
    period SHOULD be included,

What if the dampening period is different per subscriber?
Aren't we adding extra states to the device?

-

    A Subscription Service SHOULD support different transports.

    A Subscription Service SHOULD support different encodings of payload.

Don't you want to start with a single one, for interoperability reasons? At least for the encoding?

For the transport, I could agree with the reliability aspects in section 4.2.6.3

Regards, Benoit

A few editorial comments below.

- capitalize NETCONF, RESTCONF

- OLD:

     These refinements include: periodicity of object updates, filtering
     out of objects underneath a requested a subtree, and delivery QoS
     guarantee

   NEW:

     These refinements include: periodicity of object updates, filtering
     out of objects underneath a requested subtree, and delivery QoS
     guarantee

-

    YANG has gained acceptance as the data definition language of choice
    for control and management related information.
=> as the data modeling language of choice

- what is OMG/DDS in:
    With the support of standards bodies such as OMG (DDS),
    XMPP.org standard

Please a reference

-
    "HoweverRFC5277  <http://tools.ietf.org/html/rfc5277>
    does not follow the Pub/Sub paradigm, does not allow the explicit
    deletion of subscriptions, and predates YANG."

You might want to expand on "predates YANG", expressing that RFC 5277 doesn't allow the monitoring of YANG objects

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Mar 2015 15:26:07 +0000

Thanks for the comments Benoit.  Some thoughts in-line…

From: i2rs, March 19, 2015 9:54 AM

Dear all,

<Eric> Configuration ease will be something we need to continually keep in mind.   Pub/Sub is one technology where we can make too many knobs.

-

   ...

<Eric> Yes, it can be a leaf.

<Eric> will fix next version.

<Eric> will stop shouting in upper case in the next version.

-

Then I saw:

   liveliness.

<Eric> I will put a reference to the specific definition of QoS when QoS is first mentioned in the document.

<Eric> We have a start time and a period associated with a subscription upon certain objects.   From there the ending period timestamp for info collection should be established.  It is possible that other objects might also be subscribed on the same device, and might have the same ending period timestamp.  There are no requirements in the document right now which talk about how multiple subscription updates might be bundled.  We could certainly add requirements/mechanisms for this bundling if there is need.

-

<Eric> How many extra states is up to the implementation within the device.  As the dampening period is negotiable, the network element does not have to accept the subscription terms initially requested by a subscriber.  Therefore it can refuse subscriptions with unsupportable minimum acceptable dampening periods.  A best practice might be that a network element only offer the same dampening period for all subscribers of an object.

-

<Eric> Agree.

One of the things about this document is that it is supposed to include YANG Pub/Sub requirements from various sources.   Building a requirements document which doesn’t have the minimal requirements for a first specific implementation exposes options which are not desired for the first implementations.

/Eric

Regards, Benoit

- OLD:

    guarantee

  NEW:

    guarantee

-

- what is OMG/DDS in:

   XMPP.org standard

Please a reference

-

   "However RFC5277<http://tools.ietf.org/html/rfc5277>