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?
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 <[email protected]> De la part de tom petch
> Envoyé : jeudi 19 mai 2022 10:21
> À : Joe Clarke (jclarke) <[email protected]>; Joe Clarke (jclarke)
> <[email protected]>; [email protected]
> Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap
>
> 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
_________________________________________________________________________________________________________________________
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
