You're not the first to tell me that (Warren was). I'd like to say I have some control over Exchange, but I did everything "right". Still, thanks for the second report. I'll see if I can fix that for future OOO stints.
Joe On 3/28/22 11:45, tom petch wrote: > Joe > > My post generated an automatic reply from the e-mail address that you are > using but with no content; I was expecting 'I am out of the office ...' but > no, nothing, > > Tom Petch > > ________________________________________ > From: Joe Clarke (jclarke) <[email protected]> > Sent: 28 March 2022 14:49 > To: [email protected]; tom petch; Benoit Claise; Jean Quilbeuf; > [email protected] > Subject: Re: [OPSAWG] Comments on draft-ietf-opsawg-service-assurance-yang-02 > > Sometimes the threat of WG LC is enough to get some comments :-). > Thanks, Med and Tom for doing this. > > Joe > > On 3/28/22 09:24, [email protected] wrote: >> 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
