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

Hi Mach, 

Thank you for checking. All the changes are available in -05.

BTW, it seems that your review is not tracked (still displayed as incomplete): https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/reviewrequest/15831/ 

Cheers,
Med

> -----Message d'origine-----
> De : Mach Chen <mach.chen@huawei.com>
> Envoyé : mardi 17 mai 2022 08:43
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> rtg-dir@ietf.org
> Cc : draft-ietf-opsawg-sap.all@ietf.org; opsawg@ietf.org; last-
> call@ietf.org
> Objet : RE: RtgDir Last Call review: draft-ietf-opsawg-sap-04
> 
> Hi Med,
> 
> Thanks for considering my comments, I am OK with your resolution.
> 
> Best regards,
> Mach
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>
> > Sent: Thursday, May 12, 2022 8:21 PM
> > To: Mach Chen <mach.chen@huawei.com>; rtg-dir@ietf.org
> > Cc: draft-ietf-opsawg-sap.all@ietf.org; opsawg@ietf.org;
> > last-call@ietf.org
> > 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 <last-call-bounces@ietf.org> De la part de Mach
> Chen
> > > Envoyé : jeudi 12 mai 2022 11:11 À : rtg-dir@ietf.org Cc :
> > > draft-ietf-opsawg-sap.all@ietf.org; opsawg@ietf.org; last-
> > > call@ietf.org 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
> > > last-call@ietf.org
> > > 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.

_________________________________________________________________________________________________________________________

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.