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. 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. Third, I stated that the SAP is part of the operator's network. 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. > -----Message d'origine----- > De : tom petch <[email protected]> > Envoyé : vendredi 20 mai 2022 11:00 > À : 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: 19 May 2022 10:14 > > Hi Tom, > > > It still dives straight in using a SAP with no explanation. > > and > > > A sentence such as that needs to appear in the first paragraph > of > > this I-D. > > Hmm...the first sentence of the document says the following: > > From the perspective of a service provider, the Service > Attachment > Points (SAPs) are abstraction of the network reference points > where > network services can be delivered to customers. > ^^^^^^^^^^^^^^^^ > > How is this "vast" compared to what is in 8309? > > <tp> > I always like documents that state the obvious; it tells me I am > on the same page as the author. Documents that start with > abstractions or with low level detail, do the opposite. Thus I > would start with something like > ======================================= > > A network operator delivers one or more services to a customer. A > service in this context (sometimes called a Network Service) is > some form of connectivity between customer sites and the Internet, > or between customer sites across the network operator's network > and across the Internet. > > A Service Attachment Point is part of the network operator's > network and is the point where the service is delivered to the > customer. (Other SDOs use the term 'reference point' for similar > concepts). A SAP is where services such as Layer 3 VPN Service > Model (L3SM) [RFC8299] or the Layer 2 VPN Service Model (L2SM) > [RFC8466] are delivered to a customer. > > This document defines a YANG network model (Section 6) for > representing, managing, and configuring SAPs. The data model > augments the 'ietf-network' module [RFC8345] by adding the concept > of SAP; name, type, attachment interface, parent termination > point[RFC8776] and such like. > > This document also explains the scope and purpose of a SAP model > and how it relates to other YANG models such as topology models > (Section 4). > ============================== > > Tom Petch > > > > For the rest, the document says: > > This document assumes that the reader is familiar with the > contents > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > of [RFC6241], [RFC7950], [RFC8345], and [RFC8309]. The > document uses > ^^^^^^^^ > terms from those documents. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I'm still puzzled what is not clear here. Really. > > > And sentences such as > > " It can also be used to > > retrieve where services, such as the Layer 3 VPN Network > Model > > (L3NM) > > [RFC9182], and the Layer 2 VPN Network Model (L2NM) > > [I-D.ietf-opsawg-l2nm], are delivered to customers" > > I think plain wrong. > A data model of SAPs can be used to > > retrieve, but you cannot retrieve anything from the SAP per se > (except > > the user data that the service is conveying!). > > Med: I fail to follow the reasoning. The model allows to retrieve > the reference points where a service delivered. There are plenty > of examples in the appendix. > > Cheers, > Med > > > -----Message d'origine----- > > De : OPSAWG <[email protected]> De la part de tom petch > Envoyé : > > jeudi 19 mai 2022 10:21 À : Joe Clarke (jclarke) > <[email protected]>; > > Joe Clarke (jclarke) <[email protected]>; > > [email protected] Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg- > sap > > > > From: OPSAWG <[email protected]> on behalf of tom petch > > <[email protected]> > > Sent: 18 May 2022 16:23 > > From: Joe Clarke (jclarke) <[email protected]> > > Sent: 18 May 2022 14:24 > > > > On 5/18/22 06:16, tom petch wrote: > > > From: OPSAWG <[email protected]> on behalf of Joe Clarke > > > (jclarke) <[email protected]> > > > Sent: 17 May 2022 16:48 > > > > > > I am closing the WG LC for this document. The LC prompted > some > > good > > > comments from DIR reviews and a comprehensive review from > Adrian > > which > > > led to a TEAS cross-review. > > > > > > The biggest discussion came between Tom P and the WG/authors > on > > the > > > definition of what a SAP is in the vein of this doc. While > > some of his > > > suggestions have made it into the latest revision of the > > document, I > > > am not certain this discussion has been fully resolved. > > > > > > The last email I saw was > > > https://mailarchive.ietf.org/arch/msg/opsawg/D- > > z_rGqFl8V47fHlAkwSqiOxEDk/. > > > Is this resolved? > > > > > > <tp> > > > well, look at Mach Chen's Rtgdir review which. for me, covers > > the same ground and suggests that it is unresolved. I am > perhaps more > > familiar than Mach with the terminology of the various TEAS > documents > > and so am not quite so puzzled as he is but would say we both > share > > the same puzzlement. > > > > The authors added some clarifying text to the definition of a > SAP in > > the terminology section based on Mach's and your reviews. It is > a bit > > more descriptive (though I certainly would want Attachment > Circuit > > called out as a term). Have you reviewed -05 to see if it > addresses > > your concerns? > > > > <tp> > > Not yet - I will have a look. > > > > <tp2> > > No it does not address my concerns. I start with the > Introduction and > > that has not changed (apart from clarifying NNI and UNI which I > was ok > > with). > > > > It still dives straight in using a SAP with no explanation. I > went > > back to RFC8309 and was struck by how clear, how well written > that RFC > > is by comparison. Simple things, like " A service in the > context of > > this document (sometimes > > called a Network Service) is some form of connectivity > between > > customer sites and the Internet or between customer sites > across > > the network operator's network and across the Internet" > > make a world of difference in narrowing the scope. This I-D > keeps > > referring to service without qualification which encompasses a > vast > > range. A sentence such as that needs to appear in the first > paragraph > > of this I-D. I do not want to have to refer to definitions - I > want to > > read the Introduction and know where this I-D is taking me and > this > > I-D fails that test. If you do not qualify 'service' then > Service > > Attachment Point (which has been in use for decades with a > different > > meaning of the word 'service') cannot be defined. > > > > And sentences such as > > " It can also be used to > > retrieve where services, such as the Layer 3 VPN Network > Model > > (L3NM) > > [RFC9182], and the Layer 2 VPN Network Model (L2NM) > > [I-D.ietf-opsawg-l2nm], are delivered to customers" > > I think plain wrong. A data model of SAPs can be used to > retrieve, > > but you cannot retrieve anything from the SAP per se (except the > user > > data that the service is conveying!). > > > > Tom Petch > > > > Tom Petch > > > > Joe > > > > > > > > I was looking at another I-D by the author, draft-ietf-opsawg- > > l2nm, and was struck by the use of the term 'service' in that I- > D > > which I again was unclear about the meaning of, but in that I-D. > > it is not such a barrier to my understanding. > > > > > > > > > > Tom Petch > > > > > > Based on that, we can take -05 forward to the IESG once we get > a > > > shepherd. But this point seems important to resolve. > > > > > > Joe > > > > > > On 4/22/22 15:07, Joe Clarke (jclarke) wrote: > > >> Hello, Opsawg. The last round of comments on this draft have > > been > > >> discussed/resolved, and we'd like to kick off a three-week WG > > LC for > > >> this work. Please provide any and all feedback on list > before > > the > > >> end of the day May 13, 2022. > > >> > > >> Authors, if you have suggestions for a good shepherd for this > > >> document, we'd love to hear them. > > >> > > >> I have requested reviews from Ops and Routing on this work. > > >> > > >> Thanks. > > >> > > >> 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 > > > > > > > > > _______________________________________________ > > 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. _________________________________________________________________________________________________________________________ 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
