At 09:45 PM 4/24/00 +0200, Anthony Atkielski wrote:
I agree! Why create a finite anything when an infinite
possibility exists?
Exactly. If you designed an open-ended protocol, you're far less likely to
ever have to rewrite it.
You just have to redeploy new implementations when you add new
All,
Yes ... the announcement in question should have read recharter,
not new working group.
- Ralph
At 09:30 AM 2/27/2003 +0200, Pekka Savola wrote:
On Wed, 26 Feb 2003, The IESG wrote:
A new working group has been formed in the Internet Area of the IETF.
For additional information, contact
that in the case that DDNS is in use and we are triggering off lease
expiration, the process needs to take the concepts and issues of
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-02.txt
into account.
I have added Ralph Droms to this. Ralph, your suggestion?
So it would obviously
wrote:
On 11/22/2004 4:04 PM, Ralph Droms wrote:
DHCPv6 PD (prefix delegation; RFC 3633) to obtain a prefix
Yeah, that's what I was thinking about. So now we just need implementors
to provide it and for service providers to offer it before declaring the
problem as solved.
--
Eric A. Hall
Would someone with first-hand knowledge of the reasons several major
corporations publicly indicate that they intend to use NAT with IPv6 be
willing to compare those reasons with the reasons listed in
draft-vandevelde-v6ops-nap-01, and identify any reasons that might be
missing from Gunter's
And I've had much *worse* experiences with the IESG requiring changes to
documents ... including receiving suggested text (after many months of
the document disappearing into a black hole) that actually *reversed*
text inserted earlier at the request of an AD.
- Ralph
On Thu, 2005-04-28 at 15:12
Comments in line...
- Ralph
On Thu, 2005-04-28 at 18:28 -0400, Keith Moore wrote:
The case John outlines is the one I am concerned about as well.
[...]
And, FWIW, when the AD suggests specific text changes, it's often
enough the desire of that AD rather than based on feedback from some
Let me restate for clarity - ADs aren't necessarily more technically
astute than *all* the rest of us. That is, we need to be careful that
technical input from ADs isn't automatically assigned extra weight or
control (veto power).
Which is why I suggest ADs provide technical input in open
On Fri, 2005-04-29 at 19:56 -0400, Keith Moore wrote:
Let me suggest that the rules be quite simple:
1. A Discuss may be asserted only when it pertains to a normative
concern that
involves the viability of the specification.
not reasonable. even merely informative text can cause
On Sat, 2005-04-30 at 11:12 -0700, Dave Crocker wrote:
1. A Discuss may be asserted only when it pertains to a normative
concern that involves the viability of the specification.
As a practical matter, the line between normative and informative is
likely grey enough to make this
On Fri, 2005-04-29 at 12:19 -0400, Keith Moore wrote:
Let me also restate for clarity:
Let me restate for clarity - ADs aren't necessarily more technically
astute than *all* the rest of us. That is, we need to be careful that
technical input from ADs isn't automatically assigned extra
Steve - Final decision is made as it is today; proposed change is timing
and context for review...
- Ralph
On Wed, 2005-05-04 at 16:28 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Ralph Droms writes
:
So, without meaning any offense to the ADs, I suggest we lump random
Keith - thanks for the pointer to Harrison Bergeron. Coincidentally,
I was trying to recall this story in a conversation recently and had
forgotten the details and the author...
But, I don't see how it applies here. I'm not claiming Nobody was
smarter than anybody else. Yakov explained it
John - editing to get directly to your questions:
On Mon, 2005-05-02 at 18:45 -0400, John C Klensin wrote:
(1) What would it take to convince you that putting in a term or
two as AD --not a life sentence, but a term or two-- was an
obligation you, as long-term participants and contributors,
Comments in line...
On Thu, 2005-05-05 at 18:48 +0300, Pekka Savola wrote:
On Thu, 5 May 2005, Ralph Droms wrote:
But, I don't see how it applies here. I'm not claiming Nobody was
smarter than anybody else. Yakov explained it better than I have: for
each AD there is more than one person
Ah, but the candidates know who they are, and can arrange their own
positive input.
If the list were open, might the nomcom receive more and better balanced
input?
- Ralph
On Mon, 2005-05-09 at 13:49 -0400, Melinda Shore wrote:
On May 9, 2005, at 1:42 PM, Scott W Brim wrote:
I don't
Better yet would be late binding: INSERT LATEST IETF STANDARD FIXED
BOILERPLATE.
- Ralph
On Mon, 2005-06-13 at 15:28 -0700, Bob Hinden wrote:
Dave,
Here's my own take:
It is empty bureaucracy. It is form, without content. It is additional
effort, with no benefit.
It is reasonable
Brian...
On Sun, 2005-06-26 at 17:50 +0200, Brian E Carpenter wrote:
Ralph,
Ralph Droms wrote:
I'd like to understand the process through which Dr. Roberts' request
was reviewed. The first reference I can find to Dr. Roberts' request is
in the 2005-04-14 minutes of the IESG
(https
Ralph Droms wrote:
Brian...
On Sun, 2005-06-26 at 17:50 +0200, Brian E Carpenter wrote:
Ralph,
Ralph Droms wrote:
I'd like to understand the process through which Dr. Roberts' request
was reviewed. The first reference I can find to Dr. Roberts' request is
in the 2005-04-14
John - as a concrete example of the problem you describe, the dhc WG
perceived that there was a looming problem with exhaustion of the DHCP
option code space. So, we wrote up a procedure (RFC 2939) requiring
documentation of new options in an RFC, implying technical review by the
dhc WG. Now, we
Allison...
On Sun, 2005-06-26 at 10:22 -0700, Allison Mankin wrote:
Ralph,
Under RFC 2780, IPv6 hop-by-hop option numbers are granted
either with an approved IETF document, or an IESG review.
It seems that neither the reference to IESG review in RFC 2780, nor the
definition of IESG review
Bill...
On Tue, 2005-06-28 at 10:23 -0400, Bill Sommerfeld wrote:
On Tue, 2005-06-28 at 00:15, Scott W Brim wrote:
In SG13 there was considerable debate, and at the end the
group *allowed* exploration of the topic through development through a
new draft recommendation.
assuming, for
Allison - in pervious e-mail to you, I made the statement blaming the
tools is a pretty lame excuse, which makes several unwarranted
assumptions about motivations and the constraints within which the IESG
works. I could have expressed my frustration with the lack of clarity
and detail in the
Sounds like a great idea. I'm looking forward to additional detail
about how decisions are reached as well as more clarity in the
description of those decisions.
Thanks, Brian...
- Ralph
On Thu, 2005-07-14 at 15:19 +0200, Brian E Carpenter wrote:
The IESG is interested in carrrying out an
Brian - while I haven't thought through all of the implications of the
process in draft-klensin-nomcom-term-00.txt, I don't think the two-stage
process will necessarily significantly length then process. The
proposed process would require re-shuffling of of specific tasks, but I
don't think it
will be assumed
to be 0.
The NomCom voting members will start their term on October 14, 2005,
after
the IETF community has had a chance to review the random selection
process.
Please volunteer.
Thank you,
Ralph Droms
[EMAIL PROTECTED]
STOCKS USED IN THE NOMCOM SELECTION PROCESS:
Exxon Mobil
It's a design choice. We've already had some spam and unexpected
subscription attempts against the nomcom05 mailing list.
The messages are being approved within 12 hours.
- Ralph
On Fri, 2005-11-11 at 08:08 -0800, Eric Rescorla wrote:
Recent nominations to [EMAIL PROTECTED] have prompted
at 22:26 +0100, Frank Ellermann wrote:
Ralph Droms wrote:
The messages are being approved within 12 hours.
12 is less than 150, should I just send it again ?
Bye, Frank
___
Ietf mailing list
Ietf@ietf.org
https
position to [EMAIL PROTECTED]
- Ralph Droms
Chair, NomCom05
Under the Nominations Committee procedures defined in RFC 3777,
the IESG is responsible for providing a summary of the expertise
desired of the candidates selected for open IESG positions. This
information is included below
position to [EMAIL PROTECTED]
- Ralph Droms
Chair, NomCom05
+++
Under the Nominations Committee procedures defined in RFC 3777,
the IESG is responsible for providing a summary of the expertise
desired of the candidates selected for open IESG positions. This
information is included below
Brian - you've hit on an important point here. It strikes me that the
process for defining our own document standards has no fundamental
differences from the process for defining any other standard. Why shouldn't
this archival document standard be developed and adopted as a Standard in
the same
to everyone who took the time to participate in the
process through nominations, interviews and input on the candidates
under review.
- Ralph Droms (chair), for the 2005-2006 IESG Nominating Committee
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org
-mail
address and telephone number (if available) to [EMAIL PROTECTED]
- Ralph Droms
Chair, NomCom 2005-2006
-
Transport Area:
The technical areas covered by the Transport area are those with data
transport goals or with transport design issues and impact on
congestion in Internet
. Please send nominations, including the nominee's name, e-mail
address and telephone number (if available) to [EMAIL PROTECTED]
- Ralph Droms
Chair, NomCom 2005-2006
-
Transport Area:
The technical areas covered by the Transport area are those with data
transport goals or with transport design
will
close at 1700EST on Tuesday, March 21.
Please send nominations, including the nominee's name, e-mail address and
telephone number (if available) to [EMAIL PROTECTED]
- Ralph Droms
Chair, 2005-2006 IETF Nominating Committee
___
Ietf mailing list
Ietf
nominated for a seat on the IAB during the previous nomination
process, please contact me at [EMAIL PROTECTED] to renominate
yourself for this new search.
- Ralph Droms
Chair, 2005-2006 IETF Nominating Committee
___
Ietf mailing list
Ietf@ietf.org
https
in the process through providing input to the NomCom on the
candidates under review.
- Ralph Droms (chair), for the 2005-2006 IESG Nominating Committee
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
nominated for a seat on the IAB during the previous nomination
process, please contact me at [EMAIL PROTECTED] to renominate
yourself for this new search.
- Ralph Droms
Chair, 2005-2006 IETF Nominating Committee
___
Ietf mailing list
Ietf@ietf.org
https
on the
candidates under review.
Finally, I thank, once again, all the members of the NomCom for their
continuing engagement, careful review and significant contribution to the
Internet community through their work on the NomCom.
- Ralph Droms (chair), for the 2005-2006 IESG Nominating Committee
What is the current state of the nea WG? I don't see it listed at
http://ietf.org/html.charters/wg-dir.html
- Ralph
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Sam - I see where the nea BOF was more-or-less associated with the Internet
Area at IETF 65. Do you expect that nea would (if eventually chartered)
land in Internet or Security?
- Ralph
On 5/26/06 10:58 AM, Sam Hartman [EMAIL PROTECTED] wrote:
Ralph == Ralph Droms [EMAIL PROTECTED] writes
Dave - one quick follow on to your observation about will not work that
falls somewhere between will not work and don't like it. There is
another possibility: works, but there's a much simpler way to meet the same
requirements...
- Ralph
On 5/26/06 11:34 AM, Dave Crocker [EMAIL PROTECTED]
/06 11:50 AM, Antonio F. Gómez Skarmeta [EMAIL PROTECTED] wrote:
Ralph Droms escribió:
Dave - one quick follow on to your observation about will not work that
falls somewhere between will not work and don't like it. There is
another possibility: works, but there's a much simpler way to meet
Perhaps we could avoid similar delays in generating the final list of
volunteers in the future:
Secretariat generates a list of eligible volunteers as early as possible
(As far as I know, eligibility data is available well before call for
volunteers is posted)
List is used to verify
OK, now I have to step in with a response and to correct a couple of
misconceptions.
On 9/28/06 12:27 PM, John C Klensin [EMAIL PROTECTED] wrote:
Issue 1: Even if the option is desirable and the motivation for
it is clear, the specification is inadequate in definitions and
specificity in
Bob - depends on the meaning of straw poll. Any vote that results in an
action should be restricted to the 10 voting members. My understanding of
straw poll is an opinion poll that results in no direct action.
But I'm speculating and don't know what straw poll means in the context
we're
Here are my comments on draft-ietf-ipv6-2461bis-09.txt. In general, I think
the document is ready for publication. Included below are a few substantive
comments that I would like to see addressed before publication, and some
editorial corrections/suggestions/comments.
- Ralph
-
I read Dave's words clear statement of what actions must be taken to clear
the Discuss not as requiring the specification of a complete fix, but
rather as an indication of what needs to happen to the draft.
Implementation details of meeting those requirements are left to the WG.
I agree with Dave
Following up on that, I suggest a requirement that any DISCUSSes be posted
to that mailing list, along with conversation/resolution of the DISCUSSes.
I would very much like to see those last steps out in the open.
Only drawback to separate mailing list is that it requires active
involvement to
I visited Prague about two years ago and had the same experience as Ed. I
traveled via the Metro and on foot, visited all the tourist traps; had no
problems and never felt unsafe.
- Ralph
On 3/7/07 10:54 AM, Edward Lewis [EMAIL PROTECTED] wrote:
I will attest to Prague being survivable. I
Huh? DHCP is carried in UDP and IP. There is a little funkiness in the
DHCPv4 transport, which we wouldn't have need if IPv4 link-local addresses
had been defined when RFC 2131 was published. DHCPv6 uses link-local
addresses and garden-variety IPv6.
- Ralph
On 4/20/07 1:48 PM, Hallam-Baker,
.
-Original Message-
From: Ralph Droms [mailto:[EMAIL PROTECTED]
Sent: Friday, April 20, 2007 1:57 PM
To: Hallam-Baker, Phillip; David W. Hankins; ietf@ietf.org
Cc: GEOPRIV WG
Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68
Working Group Hums
Huh? DHCP is carried in UDP
Can we please leave the specific opinions about DHCP out of this discussion?
The dhc WG has done its due diligence, with review and support from the IETF
and the IESG, to put into place processes to govern assignment of extensions
to DHCP and to accommodate future extensions to both DHCPv4 and
DHCP is also a frequently-used building block (some would say
attractive nuisance). Stig, Jari and I are trying to identify drafts
from outside the dhc WG that extend DHCP or use DHCP in novel ways,
so we can provide guidance to the authors of those drafts as early as
possible. Jari and
I seem to remember that the idea of a postmortem was discussed at
some point. I don't know that anything came of that discussion.
Having some facts and data to examine probably beats anecdotal
observations about network behavior.
I think David is wise to observe that experience like DHCP
Hear, hear. We're making binary claims in a grey-scale world of
economics.
Put the costs on the table and let the enterprises and ISPs fight out
PI/PA.
- Ralph
On Sep 13, 2007, at Sep 13, 2007,5:27 AM, Jun-ichiro itojun Hagino
wrote:
my persistent question to the enterprise
Regarding transition:
On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:
Unless I've missed something rather basic, in the case of IPv6,
very little
attention was paid to facilitating transition by maximizing
interoperability
with the IPv4 installed base.
Dave, I have to agree
Typo: should read IPv6 ~= IPv4+more_bits...
- Ralph
On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:
Regarding transition:
On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:
Unless I've missed something rather basic, in the case of IPv6,
very little
attention
left the station...
- Ralph
On Oct 6, 2007, at Oct 6, 2007,4:14 PM, Brian E Carpenter wrote:
On 2007-10-05 09:12, Ralph Droms wrote:
Typo: should read IPv6 ~= IPv4+more_bits...
- Ralph
On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:
Regarding transition:
On Sep 14, 2007, at Sep 14
issues.
- Ralph
On Oct 6, 2007, at Oct 6, 2007,4:14 PM, Brian E Carpenter wrote:
On 2007-10-05 09:12, Ralph Droms wrote:
Typo: should read IPv6 ~= IPv4+more_bits...
- Ralph
On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:
Regarding transition:
On Sep 14, 2007, at Sep 14, 2007,3:43 PM
Seems to me we need ensure some formality in the experiment if we
expect to get anything out of it. Asking everyone to send in notes
from their experience won't be enough - especially, as some have
predicted, if many participants get exactly 0% Internet connectivity
while IPv4 is off.
Fred - to be clear, that DHCPv6 interop testing was not associated in
any way with the dhc WG. I'll let the organizers comment on any more
general sponsorship arrangement or other association of the event with
the IETF.
- Ralph
On Dec 17, 2007, at Dec 17, 2007,12:23 PM, Fred Baker wrote:
Iljitsch raises an interesting point that I'll generalize: can we
maximize the learning by identifying specific applications to target
for IPv6 compatibility during the IPv4 eclipse?
- Ralph
On Feb 29, 2008, at Feb 29, 2008,9:34 AM, Iljitsch van Beijnum wrote:
What's going on with the
Lakshminath - thanks a lot for publishing this report. We all
appreciate and applaud the work you and the Nomcom put into this
year's I* selections, and I especially appreciate that you invested
the time and effort - after all that earlier hard work - to produce
this report. It will be
On Mar 6, 2008, at Mar 6, 2008,8:55 PM, Brian E Carpenter wrote:
On 2008-03-07 14:06, Lakshminath Dondeti wrote:
Brian,
A small clarification below on the reference to the interpretation
problems related to 3777:
On 3/6/2008 4:10 PM, Brian E Carpenter wrote:
Dave,
On 2008-03-07 12:34,
On Sun, 16 Mar 2008, Michael StJohns wrote:
[...]
Put another way, the Nomcom is a search committee, but the hiring
authority resides in the confirming bodies.
Mike - I fundamentally and strongly disagree. In my opinoin, the Nomcom
is the hiring committee; the confirming body is the
nominaions. As Brian writes,
the IAB can ask for specific additional information in those cases where
it finds that information is necessary to complete its due diligence.
- Ralph
On Mon, 17 Mar 2008, Brian E Carpenter wrote:
On 2008-03-17 14:16, Ralph Droms wrote:
On Sun, 16 Mar 2008, Michael
Without some way to choose which rule to use and when to use it, how
can a recommendation that has conditional rule usage be implemented?
- Ralph
On Jun 3, 2008, at Jun 3, 2008,8:50 AM, Simon Josefsson wrote:
Thomas Narten [EMAIL PROTECTED] writes:
Longest match in 3484 is a hack, ant it
No, you're not the only one seeing insanity.
- Ralph
On Jun 18, 2008, at Jun 18, 2008,12:44 PM, Bob Hinden wrote:
Hi,
Let me see if I understand this.
- This is the specification for SMTP. It's was first used on the
Arpanet.
- It is probably as widely deployed as IP and TCP. Maybe
Would a reasonable BCP for future docs looks something like:
terms defined in RFC 2119 are to be capitalized for clarity;
alternatives for RFC 2119 terms, such as ought and can are to be
used in
non-normative text to avoid confusion
- Ralph
On Jun 30, 2008, at Jun 30, 2008,10:08 AM,
Iljitsch - I understand the theory behind what you're describing...in
practice, it's a hard problem to know where all the prefixes are that
should be changed; worse yet, it's hard to know which prefixes in
which parts of the configuration should be replaced with new prefixes,
and which
Sam - I think most of the issues in your review of draft-raj-dhc-tftp-
addr-option-04 can be resolved by reviewing the purposes of RFC 3942
and publishing Informational RFCs describing DHCP option codes.
Fundamentally, the reason to publish RFCs under the process described
in RFC 3942 is
(and, in fact, mostly
unimplemented).
- Ralph
On Dec 2, 2008, at Dec 2, 2008,3:53 PM, John C Klensin wrote:
--On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms
[EMAIL PROTECTED] wrote:
Sam - I think most of the issues in your review of
draft-raj-dhc-tftp-addr-option-04 can be resolved
Jari - I agree that mentioning security issues, pointing to the
Security Considerations in RFC 2131 and citing RFC 3118, is appropriate.
Responding to Richard...
On Dec 2, 2008, at Dec 2, 2008,5:35 PM, Richard Johnson wrote:
Ok, maybe I'm not understanding what's being suggested or maybe I'm
Scott raises an interesting point about identifying the source of
options when delivered to clients.
BTW, Scott - what is DHS?
The usual case - almost the only case today - is that there is a
single upstream service provider and a single source of DHCP options
to be passed along to the
- or does the device need to differentiate
between Verizon Wireless and Starbucks if I'm away from home? Or
differentiate between my ATT femtocell and my home WiFi network?
- Ralph
On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote:
Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM
s...@employees.org:
Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:
Scott raises an interesting point about identifying the source of
options when delivered to clients.
BTW, Scott - what is DHS?
Sorry, DHCP server
The usual case - almost the only case today
in, but does this or could this interact with
the options specified in RFC3046 in an unexpected way?
At 01:41 PM 4/11/2009, Ralph Droms wrote:
Scott - even knowing which interface which DHCP information came
from may not be enough for a device with multiple interfaces. Can
policies for merging
Ted - I think it's just as likely for the RG to get different
information from different interfaces (or different administrative
domains) as it is for a host to get get different information
directly. Traffic from the host, which is then forwarded by the RG to
one of more than one
Ralph Droms rdr...@cisco.com wrote:
For example, would a host process
information received from a Starbucks network over its 802.11
interface differently from information received a home network over
the 802.11 interface?
It's even more fun than that. How do we reliably know that we
I agree with Christian that there are two orthogonal issues. Comments
in line...
- Ralph
On Apr 22, 2009, at 1:19 AM 4/22/09, Christian Vogt wrote:
Folks -
It seems that folks are considering two related, yet still orthogonal
topics for inclusion in the MIF charter:
- Conflicts between
Christian - I think address selection is part but not all of the
problem.
I would be happy to see a summary of current practice in dealing with
simultaneous attachment to multiple networks. How does an iPhone
decide between its WiFi and dell interfaces? How does an RG that can
reach
I propose $40 for a seat at the table in the front of the meeting
rooms, $20 for a seat toward the front with extra legroom and $100 for
an exit row.
- Ralph
On Mar 22, 2010, at 5:46 PM 3/22/10, Dave CROCKER wrote:
Ever had a dot on your badge? Well this is your chance.
...
You
So, with all this discussion, I'm still not clear what to expect.
When I walk up to a train ticket kiosk in Schiphol, should I expect to
be able to use my US-issued, non-chip credit card (AMEX, VISA - I
don't care as long as *one* of them works), or should I have a fistful
of Euros handy?
One of the contributors, in my opinion, to the evolution of an ad hoc meeting
in a bar to Bar Bof as Fred defines it has been a series of small actions,
intended to facilitate the organization ad hoc meetings, that have had the
unintended consequence of increasing the apparent close
My recollection is that they were a gift from Craig Partridge...
- Ralph
On Aug 17, 2010, at 2:23 PM 8/17/10, Patrik Fältström wrote:
On 17 aug 2010, at 19.43, Fred Baker wrote:
I actually really appreciated Marshall Rose's shirt from Danbury -
Internet Staff
+1
Patrik
Bernard - this text is, in my opinion, intended to sync the internal data
structures if the RA advertises different prefixes than the last time the host
was attached to this link:
On reception of a Router Advertisement the host MUST go through the
SDAT and mark all the addresses
I am OK with publication of the document if Bernard's comments are addressed.
- Ralph
On Aug 18, 2010, at 6:19 PM 8/18/10, Bernard Aboba wrote:
Overall, I think the document the document looks good. Some comments:
Section 2.4
The host uses a combination of unicast
Neighbor
:
In that scenario, it makes sense to me.
However, if the RA advertises the same prefixes would there be a reason to
mark all addresses as inoperable?
-Original Message-
From: Ralph Droms [mailto:rdroms.i...@gmail.com]
Sent: Thursday, August 19, 2010 2:50 PM
To: Bernard Aboba
Cc: IETF
Combining an excellent suggestion from Donald and Avygdor's clarification as to
the official status of this document, I suggest an RFC Editor note to add the
following text as a new last paragraph in the Introduction:
This document was created by technical experts of the ANSI C12.22
and
of the C12 Standards and the manner in which
they are implemented.
Avygdor Moise
- Original Message - From: Michael StJohns mstjo...@comcast.net
To: Ralph Droms rdroms.i...@gmail.com; Avygdor Moise a...@fdos.ca
Cc: Ralph Droms rdroms.i...@gmail.com; Jonathan Brodkin
jonathan.brod
Time for another contrarion position...
Tony, why do you say the most pressing problem is getting past the IESG, and
what evidence do you have that we are going to be attacking I-Ds.
- Ralph
On Oct 26, 2010, at 4:54 PM 10/26/10, Tony Hain wrote:
[...]As many others have said, the most
I'll take the contrarian position.
Demonstrate to me that the barriers for PS really are higher than they used to
be.
- Ralph
On Oct 26, 2010, at 10:39 AM 10/26/10, Julian Reschke wrote:
On 26.10.2010 16:31, Dave CROCKER wrote:
...
This seems to be the core idea driving support for this
technical advice and recommendations to improve the Draft
Recommendation itself.
Please respond with any comments on the Draft Recommendation to ietf@ietf.org.
Thanks in advance for your review of the Draft Recommendation.
- Ralph Droms, Internet Area Director
for the IESG
to be any impact or relevance.
Regards
Brian Carpenter
On 2011-06-08 08:27, Ralph Droms wrote:
The IETF has recently received a liaison from ITU-T Q5/SG-11 regarding a
Draft Recommendation. That liaison is available as
https://datatracker.ietf.org/liaison/1054/. The official liaison
Wow. An absolute tour de force from someone who *clearly* has too much time on
his hands.
Thanks; made my day. Well, except for now I've got that long-forgotten tune
stuck in my head...
- Ralph
On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre wrote:
A bit of levity about migration
/21/11 4:14 PM, Ralph Droms wrote:
Wow. An absolute tour de force from someone who *clearly* has too much time
on his hands.
Thanks; made my day. Well, except for now I've got that long-forgotten tune
stuck in my head...
- Ralph
On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre
On Jun 30, 2011, at 12:51 AM, Melinda Shore melinda.sh...@gmail.com wrote:
On 6/29/11 8:32 PM, Keith Moore wrote:
However it does not follow that home networks need NAT or private address
space. Those are hacks of the 1990s. They always were shortsighted, and
they turned out to be an
On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote:
Daryl,
The problem described in the draft is that CPEs use 1918 space *and that many
of them can't deal with the fact that there might be addresses on the outside
interface that are the same as on the inside interface*. The claim
was gathered and what conclusions are drawn.
- Ralph
Report suggested that all three RFC1918 blocks are well utilized.
Regards,
Victor K
On 11-11-30 9:19 PM, Ralph Droms rdroms.i...@gmail.com wrote:
On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote:
Daryl,
The problem
1 - 100 of 157 matches
Mail list logo
