Hi Med, Indeed, I just updated the datatracker to reflect the review. Best regards, Mach > -----Original Message----- > From: mohamed.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx> > Sent: Wednesday, May 18, 2022 1:34 PM > To: Mach Chen <mach.chen@xxxxxxxxxx>; rtg-dir@xxxxxxxx > Cc: draft-ietf-opsawg-sap.all@xxxxxxxx; opsawg@xxxxxxxx; last-call@xxxxxxxx > Subject: RE: 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@xxxxxxxxxx> > > Envoyé : mardi 17 mai 2022 08:43 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; > > rtg-dir@xxxxxxxx Cc : draft-ietf-opsawg-sap.all@xxxxxxxx; > > opsawg@xxxxxxxx; last- call@xxxxxxxx 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@xxxxxxxxxx > > <mohamed.boucadair@xxxxxxxxxx> > > > Sent: Thursday, May 12, 2022 8:21 PM > > > To: Mach Chen <mach.chen@xxxxxxxxxx>; rtg-dir@xxxxxxxx > > > Cc: draft-ietf-opsawg-sap.all@xxxxxxxx; opsawg@xxxxxxxx; > > > last-call@xxxxxxxx > > > 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@xxxxxxxx> De la part de Mach > > Chen > > > > Envoyé : jeudi 12 mai 2022 11:11 À : rtg-dir@xxxxxxxx Cc : > > > > draft-ietf-opsawg-sap.all@xxxxxxxx; opsawg@xxxxxxxx; last- > > > > call@xxxxxxxx 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@xxxxxxxx > > > > 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
