On 3/13/15 5:14 PM, m...@becknet.com m...@becknet.com wrote:
Lee,
On the contrary, I think RFCs are pretty consistent about always
referring you to any superseding RFCs, and superseding RFCs reference
their predecessors, creating a very useful historical doubly-linked list.
I've served on IEEE
Charles N Wyble char...@thefnf.org writes:
Use a git repository.
Make tagged releases.
This enables far easier distributed editing, translating, mirroring etc. And
A fine idea in theory, but not quite as much traction in reality as bcp38.
Creating a need for a BCP for retrieving BCPs so
Use a git repository.
Make tagged releases.
This enables far easier distributed editing, translating, mirroring etc. And
you can still do whatever release engineering you want.
A wiki is a horrible solution for something like this.
On March 15, 2015 8:24:49 AM CDT, Rob Seastrom
On Sun, Mar 15, 2015 at 11:40:27AM -0400, Lee Howard wrote:
I know, I should really be having this rant in the RFC evolution WG, or
with the RFC editor. It just came up here, and I want BCOP to make
different mistakes on useful documents.
Even if you suppose that the RFC series is arranged
Rob Seastrom writes:
The wiki/living document approach others have suggested seems like a
poor one to me, for the same reason that I dislike the current trend
of there's no release tarball, major release, point release, or
regression testing - just git clone the repository in free software
On Sun, 15 Mar 2015 19:14:05 -0400, Andrew Sullivan said:
I also think that trying to pack more bits of information into the
numbering system is a mistake. But then, I would. I think you look
those sorts of things up (in the DNS, of course ;-) )
DANE? :)
pgpxZQL3U0mjq.pgp
Description: PGP
On 3/12/2015 5:24 PM, Tom Paseka wrote:
Be conservative in what you send, be liberal in what you accept
^http://en.wikipedia.org/wiki/Robustness_principle
As with all terse summaries, the meaning of this is easy to distort.
In the unfortunately not-so-uncommon extreme, it is used to argue for
Hello Everyone,
DYN put out an interesting report on how 14 British telecom routes (167
prefixes) were routed through Ukraine for a good portion of time.
The ASN in question is AS12883 (Vega in Kiev, Ukraine).
Do you think this could be a mistake?
Does anyone have any additional information to
8 matches
Mail list logo
