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

["Joe Clarke (jclarke)" <[e-mail]>]

Given the comments and -07 draft, I will close LC and move this towards
the IESG for further review.  While we didn't get a GEN early review, we
will certainly get that perspective during IETF LC.

Thanks.

Joe

On 5/23/22 05:23, [e-mail] wrote:
> Hi Tom,
>
> Please see inline. 
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : tom petch <[e-mail]>
>> Envoyé : lundi 23 mai 2022 10:56
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
>> Joe Clarke (jclarke) <[e-mail]>; Joe Clarke (jclarke)
>> <jclarke=[e-mail]>; [e-mail]
>> Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap
>>
>> From: [e-mail] <[e-mail]>
>> Sent: 20 May 2022 11:55
>>
>> Hi Tom,
>>
>> OK, let's then state the obvious.
>>
>> Please check: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-
>> sap-07
>>
>> I hope this is better.
>>
>> <tp>
>>
>> Weelll I think it is time for executive action by Rob and see how
>> the IESG, Genart and co get on.
>>
>> I made three changes which you have not.  One was that I stressed
>> the fact that a service, in this context, is about connectivity.
> [Med] This is because I think that "network services" is self-explanatory and that I don't see a value in calling out a specific aspect of such services. I'm caring about long term usage of RFCs.
>
>> To me a VPN e.g. is not a service in the same sense as when the
>> word is used in 'SAP' .  Indeed, you later list service types and
>> VPN is one of them so you do differentiate the usage in places.
>> Using the same word for the entirety of a VPN and for the
>> connectivity muddies the waters  IMHO.  There will be documents
>> where service is used for concepts such as VPN, SDWAN, CDN and
>> such like but not here.
>>
>> Second, I put it a reference to RFC8776.  I believe that unless
>> the reader is immersed in TEAS, which most of the IESG is not,
>> then they will not understand a termination point and a reference
>> is needed.
> [Med] Sure, but there is no mention of termination point in the introduction. I don't want to overload much the introduction. 
>
>> Third, I stated that the SAP is part of the operator's network.
> [Med] I'm not fun of being redundant in a document. We do already have that information in the abstract: 
>
>    This document defines a YANG data model for representing an abstract
>    view of the provider network topology that contains the points from
>                ^^^^^^^^^^^^^^^^^^^^^^^^
>    which its services can be attached
>
> I can cite other parts in the intro that already conveys that message. 
>
>> This is stated explicitly later on and for me needs stating before
>> you get into PE, CE, AC, UNI, NNI and suchlike.
>>
>> Tom Petch
>>
>> Cheers,
>> Med
>>
>> PS: Also, added Olga to the ACK section. Many thanks to her,
>> Benoît, and Oscar for the discussion we had this morning on the
>> draft.
>>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>