Hmmm... I Don't know why this is happening. Considering my default set-up on the Gmail interface is defined to use Normal size. https://pasteboard.co/JPG2ZoK.png
In fact, I had not even realized that this mail-list forwarded emails in the exact format they were generated. Usually, they set mailman to convert everything to pure-text. But thank you Mama for teaching me good manners. I will try to behave better, a search how to fix the size... P.S.: If you cloud help-me to fix that on Gmail, I can show you the Zoom Function on the Browsers or mail readers. Em seg., 22 de fev. de 2021 às 21:40, Mark Andrews <ma...@isc.org> escreveu: > Really, does anyone here think that it is good form to send email with > font size *SMALL*? > If your MUA does this by default complain to the developers. The default > should be “medium”. > If the font is too big on your screen change the magnification *you* > choose to display to *yourself*, > don’t change the font size you send to everyone else. > > Mark > > <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier > = > new,monospace;font-size:small">Well... I must confess that I had some > diffi= > culty=C2=A0on the first understanding=C2=A0of what is proposed.<br><br>But > = > > > > On 23 Feb 2021, at 04:03, Douglas Fischer <fischerdoug...@gmail.com> > wrote: > > > > Well... I must confess that I had some difficulty on the first > understanding of what is proposed. > > > > But after the 4 reads, I saw that this "spaghetti" thing is more > powerful than I could imagine! > > > > > > Please correct me if I'm no right: > > But it looks like a "crypto sign and publishes" anything related to an > organization. > > > > Yes, I think that with some effort CrossConnect LOAs can be fitted > inside of it... > > I'm not sure if it is the better solution for the scope of LOAs, but > certainly is a valid discussion. > > > > > > What is bubbling in my mind is the standard data model for each type of > different attribute that can exist... > > Who will define that? > > > > > > > > Em seg., 22 de fev. de 2021 às 12:26, Christopher Morrow < > morrowc.li...@gmail.com> escreveu: > > On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer > > <fischerdoug...@gmail.com> wrote: > > > > > > I believe that almost everyone in here knows that LOAs for Cross > Connects in Datacenters and Telecom Rooms can be a pain... > > > > > > I don't know if I'm suggesting something that already exists. > > > Or even if I'm suggesting something that could be unpopular for some > reason. > > > > > > But every time I need to deal with some Cross-Connect LOA, and mostly > when we face some rework on data mistakes, I dream with a "PeeringDB for > Cross Connects". > > > > > > > are you asking about something like this: > > https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ > > > > Which COULD be used to, as an AS holder: > > "sign something to be sent between you and the colo and your intended > peer" > > > > that you could sign (with your rpki stuffs) and your peer could also > > sign with their 'rpki stuffs', and which the colo provider could > > automatically validate and action upon final signature(s) received. > > > > > So, this mail is a question and also a suggestion. > > > > > > > > > There is something like an "online notary's office" exclusive for > Cross-Connect LOAs? > > > - Somewhere Organizations can register information authorizing > connections of Port on their Places (Cages, Racks, etc)... > > > > > > > The RPKI data today doesn't contain information about > > cages/ports/patch-panels, so possibly the spaghetti draft isn't a > > terrific fit? > > > > > If it doesn't exist. What would be necessary for that? > > > Mostly considering the PeeringDB work model. > > > - OpenSource. > > > - Free access to the tool, and sponsors to keep the project alive. > > > - API driven, with some Web-gui. > > > And considering some data-modeling. > > > - Most of the data being Open/Public (Organizations, > Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc). > > > - Access control to Information that can not be public (A-side > organization, Z-Side Organization, PathPanel/Port). > > > And some workflow > > > - Cross Connect Requiremento/Authorization from A-Side > > > - Acceptance/Authorization from Z-side. > > > - Acceptance/Authorization from Facilities involved (could be more > than one) > > > - Execution/Activation notice from Facilities. > > > > > > > > > -- > > > Douglas Fernando Fischer > > > Engº de Controle e Automação > > > > > > -- > > Douglas Fernando Fischer > > Engº de Controle e Automação > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- Douglas Fernando Fischer Engº de Controle e Automação
