Given the comments and -07 draft, I will close LC and move this towards the IESG for further review. While we didn't get a GEN early review, we will certainly get that perspective during IETF LC.
Thanks. Joe On 5/23/22 05:23, [email protected] wrote: > Hi Tom, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : tom petch <[email protected]> >> Envoyé : lundi 23 mai 2022 10:56 >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; >> Joe Clarke (jclarke) <[email protected]>; Joe Clarke (jclarke) >> <[email protected]>; [email protected] >> Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap >> >> From: [email protected] <[email protected]> >> Sent: 20 May 2022 11:55 >> >> Hi Tom, >> >> OK, let's then state the obvious. >> >> Please check: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg- >> sap-07 >> >> I hope this is better. >> >> <tp> >> >> Weelll I think it is time for executive action by Rob and see how >> the IESG, Genart and co get on. >> >> I made three changes which you have not. One was that I stressed >> the fact that a service, in this context, is about connectivity. > [Med] This is because I think that "network services" is self-explanatory and > that I don't see a value in calling out a specific aspect of such services. > I'm caring about long term usage of RFCs. > >> To me a VPN e.g. is not a service in the same sense as when the >> word is used in 'SAP' . Indeed, you later list service types and >> VPN is one of them so you do differentiate the usage in places. >> Using the same word for the entirety of a VPN and for the >> connectivity muddies the waters IMHO. There will be documents >> where service is used for concepts such as VPN, SDWAN, CDN and >> such like but not here. >> >> Second, I put it a reference to RFC8776. I believe that unless >> the reader is immersed in TEAS, which most of the IESG is not, >> then they will not understand a termination point and a reference >> is needed. > [Med] Sure, but there is no mention of termination point in the introduction. > I don't want to overload much the introduction. > >> Third, I stated that the SAP is part of the operator's network. > [Med] I'm not fun of being redundant in a document. We do already have that > information in the abstract: > > This document defines a YANG data model for representing an abstract > view of the provider network topology that contains the points from > ^^^^^^^^^^^^^^^^^^^^^^^^ > which its services can be attached > > I can cite other parts in the intro that already conveys that message. > >> This is stated explicitly later on and for me needs stating before >> you get into PE, CE, AC, UNI, NNI and suchlike. >> >> Tom Petch >> >> Cheers, >> Med >> >> PS: Also, added Olga to the ACK section. Many thanks to her, >> Benoît, and Oscar for the discussion we had this morning on the >> draft. >> > > _________________________________________________________________________________________________________________________ > > 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
