[Last-Call] Re: Secdir last call review of draft-ietf-opsawg-teas-attachment-circuit-15

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tero, 

I made changes to follow your suggestion when appropriate. Please use the same diff to track the changes. Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : Tero Kivinen <kivinen@xxxxxx>
> Envoyé : mercredi 4 septembre 2024 02:43
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>
> Cc : secdir@xxxxxxxx; draft-ietf-opsawg-teas-attachment-
> circuit.all@xxxxxxxx; last-call@xxxxxxxx; opsawg@xxxxxxxx
> Objet : RE: Secdir last call review of draft-ietf-opsawg-teas-
> attachment-circuit-15
> 
> 
> mohamed.boucadair@xxxxxxxxxx writes:
> > > 1.1.  Scope and Intended Use
> > >
> > >    Connectivity services are provided by networks to
> customers via
> > >    dedicated terminating points, such as Service Functions
> (SFs)
> > >    [RFC****], Customer Edges (CEs), peer Autonomous System
> Border
> > > ...
> > >    This document adheres to the definition of an Attachment
> Circuit
> > > as
> > >    provided in Section 1.2 of [RFC****], especially:
> > > ...
> > >
> > > For people who are not familiar of all mappings from the
> random RFC
> > > numbers to titles of the RFCs it would be better to make sure
> that
> > > each any RFC number is referenced you also expand the short
> title
> > > for the document.
> >
> > [Med] I still think this is a matter of editing taste. The
> reference
> > list has the full details to cross check if needed.
> 
> But it should be matter of reading test, not for editing taste.
> We should be trying to write the documents to be easy to read and
> understand, not to be easy to edit...
> 
> Google gives also same answers. While reading this draft I had to
> google up the RFC numbers quite a lot of times, and had to do it
> multiple times for some RFCs, as I just do NOT want to learn
> mapping from RFC number to title for all RFCs.
> 
> If you provide the titles for the RFC numbers that makes it much
> easier for the reader who is new to the area, or not completely
> familiar with the area to read and follow the text. People who
> are familiar with the area will simply skip those few words if
> they already have learned that specific RFC number to title
> mapping.
> 
> If this document is one of those documents where it is expected
> that writers of the document are more numerous than readers,
> meaning the editing taste is more important than making it
> readable, then I think we should not bother publishing this as
> RFC at all.
> --
> kivinen@xxxxxx
____________________________________________________________________________________________________________
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
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux