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