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 <marka@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 <fischerdouglas@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.lists@gmail.com> escreveu:
> On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer
> <fischerdouglas@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: marka@isc.org



--
Douglas Fernando Fischer
Engº de Controle e Automação