[OPSAWG] comments on draft-gray-sampled-streaming-03

[Michael Richardson <[e-mail]>]

I have read through draft-gray-sampled-streaming-03 in more detail since the
WG meeting.

I am not sure that I like the YANG (RESTCONF) mechanisms employed, but that's
probably because I'm not as familiar with using YANG as intended.
There is a number of places where it says:

      MAY not be able

and I think that this is confusing if one thinks of "MAY" as being a weaker
version of SHOULD :-)

I think that it ought to say;
      MAY be unable

When written this way, I'm not sure the MAY is BCP14.
I think that the point is not a requirement on the server, but rather on the
client:
        This client SHOULD be capable of dealing with servers that do not
        offer ...

The first one of those was:
> A Replicator MAY not offer a Point for every interface available on the system.
  ...

which I think was also extra confusing.

I would like to know if there shouldn't be a connection to RFC8519:
  YANG Data Model for Network Access Control Lists

I'm unclear how the various packet format works.
I am understanding that it would be described somewhere (in YANG? If so I
didn't figure out where) to match the capabilities of the ASIC.
I'm concerned that this is overly flexible, and that we won't have good
reading libraries to deal with things... and it will be hard to actually
write or debug the code without access to NDA documentation from the ASIC
vendors.  Maybe I don't understand.

I would like to propose a design-team/virtual-interim on this document and
friends, including the pcap-ng document.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [







--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-