Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap

From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org>
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg