There is one substantive issue I noticed: embedded newlines in the
Base64 string.
Section 2.1 refers to Base64 encoding, defined in RFC4648 Section 4.
RFC4648 Section 3.1 says:
Implementations MUST NOT add line feeds to base-encoded data unless
the specification referring to this document
Andrei,
Thanks for taking the time to read the adverse actions doc. I realize that
it's dense in places, and appreciate feedback to improve it.
In my opinion it'd be useful to have an analysis of implications of
adverse actions with respect to Internet Number Resources (INRs). I
understand tha
So, your argument is that because a mis-declaration of space as unused vs.
can by an ISP cause harm, we should engineer a transfer model that imposes
additional complexity on what seems likely to be the most common case.
(I assume transfer of unused space is or will be the most common case
becau
> - because the entity transferring the space knows whether it is
> is use
as the operators and rirs here keep trying to tell you, this is not a
safe assumption. unlike you, some of us make mistakes.
> - and because asserting that it isn't, when it is, will adversely
>affect users affilia
Session preparation:
Agenda:
I have uploaded a new agenda. The times allotted to each presenter is noted.
If you see errors, particularly if you requested time and do not see a slot,
please inform the chairs as soon as possible.
If you have a new topic to present, please inform the chairs. T
Randy,
What I meant to imply is that:
- because the entity transferring the space knows whether it is is use
- and because asserting that it isn't, when it is, will adversely
affect users
affiliated with that entity
- therefore the entity in question is motivated to get it
Hi,
Sriram, could you please elaborate what the difference is between the
route-leak detection (and action) for customers and peers.
It seems to me that sections 3.2.1. and 3.2.2. propose the same
algorithm (modulo the BGP neighbor is a customer or a peer). The
difference in the "possible actions
