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

[tom petch <[e-mail]>]

From: [e-mail] <[e-mail]>
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 <[e-mail]> De la part de tom petch
> Envoyé : jeudi 19 mai 2022 10:21
> À : Joe Clarke (jclarke) <[e-mail]>; Joe Clarke (jclarke)
> <jclarke=[e-mail]>; [e-mail]
> Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap
>
> From: OPSAWG <[e-mail]> on behalf of tom petch
> <[e-mail]>
> Sent: 18 May 2022 16:23
> From: Joe Clarke (jclarke) <[e-mail]>
> Sent: 18 May 2022 14:24
>
> On 5/18/22 06:16, tom petch wrote:
> > From: OPSAWG <[e-mail]> on behalf of Joe Clarke
> > (jclarke) <jclarke=[e-mail]>
> > 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
>
>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> 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.