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
