Hi all, In addition to the list provided by Tom, here is some additional items to be fixed. Most are easy-to-fix:
* s/This document proposes/This document specifies * I'm still not sure why this is restricted to "Intent-based Networking Architecture" in the abstract. * Move Section I to be positioned right after Section II * fix the validation errors * run "pyang -f yang --yang-canonical" * run "pyang -f tree --tree-line-length 69" for generating the trees. * registered prefixes do not match the ones in the modules. * remove <CODE BEGINS> and <CODE ENDS> from the examples. * not sure what is the rationale for having only one address per device, two devices, why not a name is used to identify a device, etc. (Section 8.1). It seems this about unicast connectivity, and not cover multicast. * Why only IS-IS is covered? I'm not sure this version is ready for WGLC, though. Cheers, Med > -----Message d'origine----- > De : OPSAWG <[email protected]> De la part de tom petch > Envoyé : lundi 28 mars 2022 11:59 > À : Benoit Claise <[email protected]>; Jean > Quilbeuf <[email protected]>; Joe Clarke > (jclarke) <[email protected]>; [email protected] > Objet : Re: [OPSAWG] Comments on draft-ietf-opsawg-service-assurance- > yang-02 > > From: OPSAWG <[email protected]> on behalf of Benoit Claise > <[email protected]> > Sent: 25 March 2022 10:57 > > Dear OPSAWG chairs, > > As discussed during the WG session, the authors believe the two draft- > ietf-opsawg-service-assurance drafts are ready for WGLC. > > <tp> > > May be. > > This is the first module I can recall where the prefix is longer than > any of the identifiers that are prefixed. 'service-assurance- > interface:' does not make for an easy read IMHO. > > Several places have an unfinished look. > - RFC xxxx: Title to be completed > - TO DO - Better type ... > - TLP ood > - YANG import no reference clause > - line length in excess of 100 characters > - NMDA not mentioned > - string with no indication of acceptable characters sometimes attracts > a DISCUSS > - mailto:[email protected] > > Tom Petch > > > Regards, Benoit > > On 3/25/2022 11:48 AM, Jean Quilbeuf wrote: > > Hi Joe, > > Thanks for your comments. > > > > I updated the draft with some more details about the relation between > healt-score and health-score-weight. > > > > I left the counter so far, but changed it to 64 bits. > > > > Best, > > Jean > > > >> -----Original Message----- > >> From: Joe Clarke (jclarke) [mailto:[email protected]] > >> Sent: Thursday 24 March 2022 12:42 > >> To: Benoit Claise <[email protected]>; Jean > >> Quilbeuf <[email protected]>; [email protected] > >> Subject: Re: [OPSAWG] Comments on > >> draft-ietf-opsawg-service-assurance- > >> yang-02 > >> > >> On 3/24/22 08:21, Benoit Claise wrote: > >>> Hi Joe, > >>> > >>> On 3/24/2022 11:48 AM, Joe Clarke (jclarke) wrote: > >>>> On 3/9/22 11:13, Jean Quilbeuf wrote: > >>>>> Hi Joe, > >>>>> Thanks for your comments. > >>>>> > >>>>> > >>>>>> First, what is the purpose of assurance-graph-version? It's a > >>>>>> 32-bit > >> counter that can increment when something goes in and out of > >> maintenance (+2). I can easily see this wrapping fir services with a > >> lot of churn. What is the impact of that? Is this version number > >> required if we have a last modified timestamp? > >>>>> The purpose of assurance-graph-version is to enable a consumer of > >>>>> this > >> module to quickly check if they have the last version. It probably > >> makes sense to use a larger counter. I'll modify it. > >>>> How does it do that. If I get a version of 324523457273456, how do > >>>> I know that's the latest? > >>> MdT on-change. > >> Fair. But then, as a consumer, I know it's the latest because it's > >> the update I just got. And still, the date will be more useful... > >> > >> I know I'm being difficult and bike-sheddy. It doesn't really bother > >> me. Just trying to make sure there's true use for it. > >> > >> Joe > >> > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > . > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
