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 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
>
> =
> 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.But
> =
>
>
> > On 23 Feb 2021, at 04:03, Douglas Fischer
> 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
> > 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
