--On Saturday, January 12, 2013 16:19 -0800 David Conrad
d...@virtualized.org wrote:
John,
On Jan 12, 2013, at 2:21 PM, John C Klensin
john-i...@jck.com wrote:
However, I don't think the
section of 2860 that you cite helps very much because there is
another way to read it.
As you
John,
Just to be clear:
On Jan 14, 2013, at 7:19 AM, John C Klensin john-i...@jck.com wrote:
On those general subjects -- that trying to open the question of
2050 is a rat hole and that we should not go down it, we
completely agree.
If the choice is leaving 2050 as is or reopening it to
On 1/14/13 1:18 PM, David Conrad d...@virtualized.org wrote:
John,
Just to be clear:
On Jan 14, 2013, at 7:19 AM, John C Klensin john-i...@jck.com wrote:
On those general subjects -- that trying to open the question of
2050 is a rat hole and that we should not go down it, we
completely
Hi John,
I suggest that, despite stumbling into it,
trying to do biblical-quality exegesis on the specific text and
wording of most RFCs is also a rat hole (or perhaps just a
different edge of the same one).
We have to be reasonable in IETF. I don't understand your reason, do
you mean 2050
I of course agree with Dave Conrad that current practice has changed
since 1996. FWIW I also fully agree with John. I think it is quite
possible to write a quite short update of BCP 12 that keeps the
technical points that are still valid and omits the policy points
that have been delegated to
I agree that RFC2050 is not completely valid with the current state of
the Internet, but making it historic will not solve any problem IMHO.
Before making 2050 historic, we should think what is and what is not
valid according with today's internet, what the technical community
agree with Servin, to update 2050,
AB
+++
On Sun, 13 Jan 2013 12:22:21, Arturo Servin wrote:
I agree that RFC2050 is not completely valid with the current state of
the Internet, but making it historic will not solve any problem IMHO.
Before making 2050 historic, we should think what is and
I object to making RFC 2050 historic without retaining at least the
content of its Section 1 as an IETF BCP.
While the IETF did formally hand over details of address
allocation policy to IANA, we did so knowing that the RIRs
themselves, and IANA, considered themselves bound by RFC 2050
(see the
Hi Moonesamy,
I also think similar with Carpenter, why reclassify to historic.
rfc2050 is still valid, and why limiting the ietf?
AB
At 01:36 12-01-2013, Brian E Carpenter wrote:
I object to making RFC 2050 historic without retaining at least the
content of its Section 1 as an IETF BCP.
From Section 1 of RFC 2050:
Currently there are three regional IRs established;
InterNIC serving North America, RIPE NCC serving
Brian,
On Jan 12, 2013, at 1:36 AM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
I object to making RFC 2050 historic without retaining at least the
content of its Section 1 as an IETF BCP.
Which part of section 1 do you think has any relevance to the IETF as a BCP?
While the IETF
--On Saturday, January 12, 2013 11:36 -0800 David Conrad
d...@virtualized.org wrote:
...
No, since addressing is _explicitly_ declared out of scope of
that MoU, see section 4.3 of RFC 2860:
Two particular assigned spaces present policy issues in
additionto the technical
If Jon were participating in this conversation today, I'm quite sure
that he would be saying that it is much more important for the RIRs
and the IETF to work together to get the best result for the Internet
rather than putting energy into trying to legislate or enforce a
boundary (whether
John,
On Jan 12, 2013, at 2:21 PM, John C Klensin john-i...@jck.com wrote:
However, I don't think the
section of 2860 that you cite helps very much because there is
another way to read it.
As you know, there are many in both high and low places who choose the
interpretation of 2860 that
On 1/12/2013 4:19 PM, David Conrad wrote:
I believe RFC 2050 does (and did) _not_ address technical
specifications of addresses, but rather documented (past tense) the
then best current practice of policies associated with the
operational deployment of those addresses for a short period around
vituperation
I believe RFC 2050 does (and did) _not_ address technical
specifications of addresses, but rather documented (past tense) the
then best current practice of policies associated with the
operational deployment of those addresses for a short period around
1995 or so.
from this
On Jan 12, 2013, at 7:14 PM, Randy Bush ra...@psg.com wrote:
RFC 2050 is outdated and historic and its status should be made to
reflect that truth.
made your bed, sleep in it.
Mea culpa, but it's time to get out of bed.
maybe learn not to do it again? nope.
To be clear, I think RFC
more vituperation
we need bookkeepers. we get wannabe regulators.
+1
and, as a friend pointed out, in sidr, we are arming them. i try hard
to ameliorate this. but that's another subject.
I don't believe moving RFC 2050 to historic implies the operational
community efforts to develop
18 matches
Mail list logo
