Reviewer: Linda Dunbar
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more
Hi Benoit!
Thanks for the explanations below and the revised draft to address my telechat
review. I've cleared my position on the document.
Roman
> -Original Message-
> From: Benoit Claise
> Sent: Tuesday, January 3, 2023 1:12 PM
> To: Jean Quilbeuf ; Roman
> Danyliw ; The IESG
>
Hi Paul,
Your comments should be addressed in the published version:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-service-assurance-yang-11
Best,
Jean
> -Original Message-
> From: Paul Wouters via Datatracker [mailto:nore...@ietf.org]
> Sent: Thursday 15 December 2022
Hi Eric,
Thanks again for your comments, I tried to address them, the diff is here:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-service-assurance-yang-11
Best and happy new year !
Jean
> -Original Message-
> From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]
>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group
WG of the IETF.
Title : YANG Modules for Service Assurance
Authors : Benoit Claise
Hi Lars,
Thanks for your review.
We addressed all your comments in the newly posted version v13.
Regards, Benoit
On 12/12/2022 12:55 PM, Lars Eggert via Datatracker wrote:
Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-service-assurance-architecture-12: No
Hi Eric,
Thanks for your review.
We addressed all your comments in the newly posted version v13.
Regards, Benoit
On 12/12/2022 6:22 PM, Éric Vyncke via Datatracker wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-service-assurance-architecture-12: No
Thanks Christian.
Regards, Benoit
On 12/20/2022 8:01 PM, Christian Huitema via Datatracker wrote:
Reviewer: Christian Huitema
Review result: Ready
My review of version 11 of this draft was making a number of suggestions. These
suggestions have largely been addressed in the version 12 of the
Hi Roman,
The new IETF draft version v13 has been posted with the changes
discussed below.
Thanks for your review.
Regards, Benoit
On 12/15/2022 2:14 AM, Jean Quilbeuf wrote:
Hi Roman,
Thanks for your review,
You will find our answer below.
Best,
Jean
-Original Message-
From:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group
WG of the IETF.
Title : Service Assurance for Intent-based Networking
Architecture
Authors : Benoit
Dear Zhenqiang,
Thanks a lot for your feedback.
I presume with gRPC you are referring to YANG push (RFC 8639, RFC 8641,
draft-ietf-netconf-udp-notif, draft-ietf-netconf-https-notif). gNMI (gRPC is
the transport of gNMI) has been proposed (draft-openconfig-rtgwg-gnmi-spec) in
2018 but not
Dear Zhenqiang,
Thanks a lot for your feedback.
I presume with gRPC you are referring to YANG push (RFC 8639, RFC 8641,
draft-ietf-netconf-udp-notif, draft-ietf-netconf-https-notif). gNMI (gRPC is
the transport of gNMI) has been proposed (draft-openconfig-rtgwg-gnmi-spec) in
2018 but not
Hi Tianran and all,
Why not use one protocol, such as grpc, to export all the iOAM metrics? It is
ok to export one way delay in IPFIX. If other metrics, such as queue depth,
buffer occupancy, etc, have to be exported in grpc, it is not necessory to
export one way delay in IPFIX.
Best
Hello all,
Why not use the grpc to export all the iOAM metrics measured by the device?
Only one way delay is expoeted by IPFIX in this doc, how about others? I prefer
using one protocol to export all the iOAM metrics if possible because this is
convinent for both the device and the collector.
Hi Rob,
Thanks for the review.
Candidate changes to address this review can be tracked at:
https://tinyurl.com/opsawg-add-latest
Please find inline some inputs in addition to the replies from Alan.
Cheers,
Med
> -Message d'origine-
> De : Rob Wilton (rwilton)
> Envoyé : lundi 19
Hi Tom, all,
We already have the following in the Introduction:
A network may support multiple services, potentially of different
types. Whether a SAP topology is dedicated to services of a specific
service type, an individual service, or shared among many services of
different
16 matches
Mail list logo