Hi Tom, I'm not sure to parse your comments.
SAPs are defined in the abstract, but also in the first sentence of the intro: 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. A VPN network access (RFC9182) is an example of a SAP. VRFs are another example of SAPs. Both are called out in the draft. Cheers, Med > -----Message d'origine----- > De : OPSAWG <[email protected]> De la part de tom petch > Envoyé : mercredi 27 avril 2022 11:21 > À : Joe Clarke (jclarke) <[email protected]>; > [email protected] > Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap > > From: OPSAWG <[email protected]> on behalf of Joe Clarke > (jclarke) <[email protected]> > Sent: 22 April 2022 20:00 > > 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. > > <tp> > I think that the problem with this I-D is that it does not know > what a SAP is. I have been using 'SAP' for decades, as in e.g. > IEEE802, and this I-D is clearly nothing to do with a SAP, nothing > to do with a service even. Defining the role of a SAP as NNI or > UNI tells me that whatever this I-D is about it is not any kind of > S(ervice)... in any shape or form. > > Reverse engineering the details does not help 'its reference to a > termination point' TP is well defined, but having an (undefined) > reference to it tells me nothing 'SAP is not a TTP nor a link' > that still leaves a lot of scope! > and much of the later text talks of binding a SAP to an interface, > a parent interface, an attachment interface and so on so clearly a > SAP as used here (but not elsewhere) is closely associated with > interfaces 'sap-id uniquely a SAP within a node' so the namespace > is local to a node which limits what it might be used for > > Yup, I do not know what this I-D is meant to be about. It is a > YANG module of a something but what that something is (clearly not > a SAP), what use it is to have the concept of such a something in > a network, I cannot tell. > > Tom Petch > > > 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 _________________________________________________________________________________________________________________________ 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
