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
