Subject: Re: [Rift] Benoit Claise's No Objection on charter-ietf-rift-00-04: (with COMMENT)

From: Benoit Claise <[email-masked]>
Date: Thu, 1 Feb 2018 23:54:24 +0100

Hi Tony,
> Benoit, thanks for review. Agree with your comments. Further comments
>
> 1. I personally think implementation status is kept more handy as a 
> separate document from spec ...
> 2. I think that monitoring YANG discussion is best kept as separate 
> model/topic from configuration Yang.
I advice you to read 
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/, 
in the RFC editor queue.
config and oper data (or intent and applied) are in different datastores.
> Yang is _great_ for configuration but monitoring has its own 
> challenges (based on practical experience ;-). Worthy discussion in 
> the group and possibly a template of things to come in other 
> protocols, i.e. how do we provide good telemetry into a protocol 
> without starting with Yang or any other modelling/transport 
> preconception ...  In fact, I would argue that to do really good 
> monitoring @ certain point in time you fall back on packet encodings 
> themselves, i.e. you read thrift/protobuf packets from something like 
> a streaming medium [which puts you close to e.g. flooding albeit you 
> are willing to "miss things" being on a slower, reliable medium like 
> TCP while still achieving consistency] ...
The YANG objects for configuration and operational data are orthogonal 
to the encoding or the transport, or even if this is used for monitoring 
or streaming telemetry. I should be missing something.

>
> thanks
>
> --- tony
>
> On Thu, Jan 25, 2018 at 5:33 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Benoit Claise has entered the following ballot position for
>     charter-ietf-rift-00-04: No Objection
>
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut
>     this
>     introductory paragraph, however.)
>
>
>
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/charter-ietf-rift/
>     <https://datatracker.ietf.org/doc/charter-ietf-rift/>
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>      - A YANG module focused on configuration of protocol instances
>     I hope that this work item is
>      - A YANG module focused on configuration and monitoring of
>     protocol instances
>
>     Editorial
>      - A Standards Track specification based on draft-przygienda-rift.
>     The document
>      will include:
>        - an Implementation Status section as described in RFC 7942
>        - an Operational Considerations section to explain how the
>     protocol is
>        configured, deployed, and diagnosed - Security and Privacy
>     Considerations,
>        although this material may refer to a separate Threat Analysis
>     document
>        (q.v.)
>
>     The sentence starting with "- Security and Privacy Considerations,
>     ..." should have a new line.
>
>
>     _______________________________________________
>     Rift mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/rift
>     <https://www.ietf.org/mailman/listinfo/rift>
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 2 Feb 2018 08:04:52 +0800

On Fri, Feb 2, 2018 at 6:54 AM, Benoit Claise <[email-masked]> wrote:

> I advice you to read https://datatracker.ietf.org/
> doc/draft-ietf-netmod-revised-datastores/, in the RFC editor queue.

will do, am aware of the split  on the config/applied data.

> Yang is _great_ for configuration but monitoring has its own challenges
> (based on practical experience ;-). Worthy discussion in the group and
> possibly a template of things to come in other protocols, i.e. how do we
> provide good telemetry into a protocol without starting with Yang or any
> other modelling/transport preconception ...  In fact, I would argue that to
> do really good monitoring @ certain point in time you fall back on packet
> encodings themselves, i.e. you read thrift/protobuf packets from something
> like a streaming medium [which puts you close to e.g. flooding albeit you
> are willing to "miss things" being on a slower, reliable medium like TCP
> while still achieving consistency] ...
>
> The YANG objects for configuration and operational data are orthogonal to
> the encoding or the transport, or even if this is used for monitoring or
> streaming telemetry. I should be missing something.
>
>
my observations were purely practical from implementation experience unless
we are assuming that we are thinking by now of sending Yang objects as
protocol encodings ...

thanks

--- tony