Re: [RTG-DIR] RtgDir Last Call review: draft-ietf-opsawg-sap-04

[Mach Chen <[e-mail]>]

Hi Med,

Thanks for considering my comments, I am OK with your resolution.

Best regards,
Mach

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, May 12, 2022 8:21 PM
> To: Mach Chen <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: RtgDir Last Call review: draft-ietf-opsawg-sap-04
> 
> Hi Mach,
> 
> Thank you for the review. The changes to address the review can be tracked at:
> https://tinyurl.com/sap-latest
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : last-call <[e-mail]> De la part de Mach Chen
> > Envoyé : jeudi 12 mai 2022 11:11 À : [e-mail] Cc :
> > [e-mail]; [e-mail]; last-
> > [e-mail] Objet : [Last-Call] RtgDir Last Call review:
> > draft-ietf-opsawg-
> > sap-04
> >
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this
> > draft. The Routing Directorate seeks to review all routing or
> > routing-related drafts as they pass through IETF last call and IESG
> > review, and sometimes on special request. The purpose of the review is
> > to provide assistance to the Routing ADs. For more information about
> > the Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> > Although these comments are primarily for the use of the Routing ADs,
> > it would be helpful if you could consider them along with any other
> > IETF Last Call comments that you receive, and strive to resolve them
> > through discussion or by updating the draft.
> >
> > Document: draft-ietf-opsawg-sap-04
> > Reviewer: Mach Chen
> > Review Date: 2022/05/15
> > IETF LC End Date:
> > Intended Status: Standards Track
> >
> > Summary:
> > I have some minor concerns about this document that I think should be
> > resolved before publication.
> >
> > Major Issues:
> > None
> >
> > Minor Issues:
> > 1. Section 2, the definition of Service Attachment Point (SAP) is hard
> > to understand here, the definition depends on the definition of
> > "service's endpoint" and "TP" that is not defined in the document or
> > lack of references(if defined in other documents).
> > More text needed here and it's better to make it consistent with the
> > definition in other places (e.g., Introduction section).
> 
> [Med] Updated the text to:
> 
> NEW:
>    Service Attachment Points (SAPs):  An abstraction of the network
>       reference points (e.g., PE side of an AC) where network services
>       can be delivered and/or being delivered to customers.
> 
> >
> > 2. Section 3,
> > " The
> >    model is also used to retrieve the network points where a service
> > is
> >    being delivered to customers."
> > What's the meaning of the "network points" here? Is it a node, link,
> > interface or something else, some clarification needed here, or using
> > a more specific and well-known term here.
> >
> 
> [Med] An example was added to updated definition provided above.
> 
> > 3. Section 4, " Also, the SAP is not a tunnel termination point
> > (TTP) (Section 3.6 of
> >    [RFC8795]) nor a link." Why need to state this here, maybe it's
> > better to move it to the place of the definition of "SAP".
> 
> [Med] We prefer to maintain it here as this section is about positioning the
> model vs. existing models.
> 
> >
> > 4. identity basic-connectivity {
> >        base vpn-common:service-type;
> >        description
> >          "Basic IP connectivity. This is, for example, a plain
> >           connectivity offered to Enterprises over a dedicated
> >           or shared MPLS infrastructure."; Since it's a "IP
> > connectivity", why emphasize that it is over an "MPLS"
> > infrastructure?
> >
> 
> [Med] That was just an example.
> 
> > Nits:
> > 1. Abstract section, the second sentence of paragraph, s/ The Service
> > Attachment Points/SAPs
> 
> [Med] OK
> 
> 
> 2. Section 1, the last 3rd para,
> > it's better to add references when mention L2VPN and L3VPN
> 
> [Med] Added a pointer to RFC4026.
> 
> 
> 3.
> > Section 3, suggest to add a reference to EVPN.
> 
> [Med] Several EVPN-related are provided in Section 5 with explicit association
> with the EVPN flavor.
> 
> > 4. Section 5, suggest to add the references to LAG, IRB.
> 
> [Med] OK
> 
> > 5. identity virtual-network,  suggest to copy the description of
> > "Virtual Network" from RFC 8453.
> 
> [Med] Went with the following:
> 
> OLD:
>       "Virtual network.";
> NEW:
>       "Virtual network. Refers to a logical network instance
>        that is built over a physical network.";
> 
> > 6. It's better to add more text to the description of identity phy,
> > loopback, lag and irb.
> 
> [Med] These are well-known and well-established. I don't think we need to say
> much here, but will see. Thanks.
> 
> >
> > Best regards,
> > Mach
> >
> > --
> > last-call mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/last-call
> 
> ________________________________________________________________
> _________________________________________________________
> 
> 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.