Fred Baker wrote:
On Nov 30, 2006, at 2:29 PM, Sam Hartman wrote:
There was very little support outside of those involved in the ieprep
working group for the ieprep work.
I'd have to say that there wasn't really a clear consensus in either
direction about much of anything.
I guess I'm
Brian,
1. There's a presumption that precedence and preemption are the
mechanisms - but those aren't requirements, they are solutions, and
it isn't clear to me that they can ever be appropriate solutions
in the upper layers of the Internet. The requirement is presumably
that important
Eliot Lear wrote:
Brian,
1. There's a presumption that precedence and preemption are the
mechanisms - but those aren't requirements, they are solutions, and
it isn't clear to me that they can ever be appropriate solutions
in the upper layers of the Internet. The requirement is presumably
that
On Fri, 1 Dec 2006, Brian E Carpenter wrote:
2. There's clearly a need, if the work is to be expanded into new
applications areas, for the experts in those applications to be
deeply involved. That is in fact the main argument why the work
should be done in the IETF if it's done at all. I
Brian E Carpenter [EMAIL PROTECTED] wrote on 12/01/2006 05:20:31 AM:
Speaking only for myself: I'm now reasonably satisfied that if this work
is to be done, it will be done better in the IETF than in the ITU.
However, looking at the last draft of the charter that I've seen, I am
Janet, See inline, Cheers, Martin
Janet wrote:
The mis-perception that the WG is focused on precedence and preemption
is, unfortunately, reinforced by the list of milestones, which focus on
the
military environment.
I would also, as an individual, favor modification to the list of
milestones
Martin,
yes, I agree.
Janet
Dolly, Martin C, ALABS [EMAIL PROTECTED] wrote on 12/01/2006 02:05:54 PM:
Janet, See inline, Cheers, Martin
Janet wrote:
The mis-perception that the WG is focused on precedence and preemption
is, unfortunately, reinforced by the list of milestones, which
Sam,
Back on Nov 1'st, you started this thread with the following:
I'm speaking here as an individual. I'd like to build consensus
for my position both within the IESG and within the community,
but I realize that if I fail to build that consensus, I cannot
make this objection as a single
ken == ken carlberg [EMAIL PROTECTED] writes:
ken Sam, Back on Nov 1'st, you started this thread with the
ken following:
I'm speaking here as an individual. I'd like to build
consensus for my position both within the IESG and within the
community, but I realize that if I
I'm speaking here as an individual. I'd like to build
consensus for my position both within the IESG and within the
community, but I realize that if I fail to build that
consensus, I cannot make this objection as a single IESG
member.
ken Its now been about 2 weeks since the last comment
ken == ken carlberg [EMAIL PROTECTED] writes:
I'm speaking here as an individual. I'd like to build
consensus for my position both within the IESG and within the
community, but I realize that if I fail to build that
consensus, I cannot make this objection as a single IESG
On Nov 30, 2006, at 2:29 PM, Sam Hartman wrote:
There was very little support outside of those involved in the
ieprep working group for the ieprep work.
I'd have to say that there wasn't really a clear consensus in
either direction about much of anything.
I guess I'm confused. Generally,
I'll echo Fred's comments, and just add this...
I'd have to say that there wasn't really a clear consensus in either
direction about much of anything.
your original note asked about consensus of closing the group --
that's the focus of the discussion point you brought to our attention
on
Fred,
Fred Baker wrote:
On Nov 14, 2006, at 8:36 AM, Brian E Carpenter wrote:
2. The notion that solutions such as precedence and preemption are
(a) requirements and (b) applicable to all applications just doesn't
compute for me.
They don't especially compute for me in the sense that
@ietf.org; Scott Bradner
Subject: Re: WG Review: Recharter of Internet Emergency Preparedness
(ieprep)
On Wed, 15 Nov 2006, Fred Baker wrote:
We also specifically addressed their requirements (in tsvwg)
operationally:
http://www.ietf.org/rfc/rfc4594.txt
4594 Configuration Guidelines
Brian E Carpenter [EMAIL PROTECTED] wrote on 11/14/2006 11:36:40 AM:
...
This illustrates some of my concerns about this requirements work being
done outside the IETF.
...
2. The notion that solutions such as precedence and preemption
are (a) requirements and (b) applicable to
But in the IP world, there is a full continuum of states in between.
Some
of these are candidates for a useful service, and some of which aren't.
- Allowing a higher packet drop rate across all the lower priority
calls.
Note that this scenario gives so-called *IMPORTANT* traffic
the
On Nov 14, 2006, at 8:36 AM, Brian E Carpenter wrote:
2. The notion that solutions such as precedence and preemption are
(a) requirements and (b) applicable to all applications just
doesn't compute for me.
They don't especially compute for me in the sense that the terms are
used in the
On Nov 16, 2006, at 4:02 PM, Curtis Villamizar wrote:
Preemption in MPLS can be soft preemption (setting aside
differences of opinion about how signaling of soft preempt should
be done for the moment)...
Even for hard preemption, there is at worst a fall back to IP and
reroute...
Those
What you're describing, in general terms, is MPLS TE. Yes, MPLS TE
will allow you to use your capacity a little more efficiently.
As I said, not all networks are MPLS, and not all MPLS networks do
traffic engineering.
The scenario in question is *after* those things have been done.
On Nov
I don't believe the new charter of ieprep working group belongs in
the IETF... the work that remains belongs somewhere else--probably
the ITU-T.
Let's address this directly.
ITU-T gave us a set of requirements in
[3] Description of an International Emergency Preference Scheme
Fred == Fred Baker [EMAIL PROTECTED] writes:
Fred The remaining requirements, as I understand them, relate to
Fred more traditional internet applications: the delivery of
Fred email within a stated interval, reliable file transfer at a
Fred stated rate in the presence of
On Wed, 15 Nov 2006, Fred Baker wrote:
We also specifically addressed their requirements (in tsvwg) operationally:
http://www.ietf.org/rfc/rfc4594.txt
4594 Configuration Guidelines for DiffServ Service Classes. J.
Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes)
Robert G. Cole wrote:
I whole-heartedly agree. I believe the DoD must extend its notions of
Precedence and Preemption to all applications, voice, video, web, ftp,
mail, etc.
...
This illustrates some of my concerns about this requirements work being
done outside the IETF.
1. The DoD
(Catching up...)
James M. Polk wrote:
...
didn't the IESG, about 18 months ago (it may be longer) write a letter
to either ITU-T or ETSI to stop attempting to extend RSVP, that it was
supposed to be done in the IETF?
I seem to remember that event occuring, though I admit I don't remember
We need to
resend in 30 seconds, perhaps, and if mumble time units elapse
without successful delivery we need to initiate a response to the
sender indicating that s/he should try another communication channel
while we continue to retry this one.
Waiting 30 seconds would be unwise in the
I whole-heartedly agree. I believe the DoD must extend its notions of
Precedence and Preemption to all applications, voice, video, web, ftp,
mail, etc. Mechanisms/protocols must be defined and consistent across
applications and their interactions with services, e.g., DNS, SIP, etc.,
and with
Before you all jump all over me, I apologize for forgetting to remove the
corporate sig on my previous email.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Excerpts from Sam Hartman on Thu, Nov 02, 2006 02:30:43PM -0500:
To propose concrete action, I think the IETF should draft a liaison
statement for action to the ITU asking for them to comment on whether
they see any current conflicts and on whether there are parts of this
work they would be
I didn't write the proposed charter, and I don't intend to manage the
next instance of the working group either. I will collaborate with
the chairs on a charter if you like.
The key thing, though, is actually not this charter, as important as
it is. It is the IETF leadership taking it upon
no,it's quite a bit more than that.
So let's take the canonical hypothetical case. Nuclear-tipped pointy-
end-of-the-spear things are coming over the horizon and one of a very
small number of people (the president, a theatre commander, etc)
needs to send a message to a
Fred == Fred Baker [EMAIL PROTECTED] writes:
Fred The key thing, though, is actually not this charter, as
Fred important as it is. It is the IETF leadership taking it upon
Fred itself to enable the work to progress in a timely fashion
Fred rather than having an infinite series of
Pete Resnick wrote: Questions abound around the mechanisms for sending an email and ensuring that it is delivered in a stated time interval on the order of minutes or that an indication of failure is returned to the sender... That, in particular, seems like a relatively easy extension to RFC
On Sat, 4 Nov 2006, Fred Baker wrote:
I have to say that my discussions with US DoD and DHS/NCS, and with their
counterparts in other countries, doesn't suggest that the set of technical
mechanisms is all specified. If we're looking only at voice, it is maybe so,
but they're not looking only
It's not clear whether going on this way will achieve useful results
in a useful amount of time.
the first part of the above is a matter of opinion, which I'll
respect but disagree with.
the second is a red herring. if you wish a more detailed explanation
of the timeline of milestones in
:
Recharter of InternetEmergency
Preparedness (ieprep
There has also been a change in the external factors affecting the urgency
of this work.
At one time the perspective (from at least some of us) has been We know
we are going to need this stuff sometime in the future.
That perspective has changed to There are deadlines in place. If we don't
Fred == Fred Baker [EMAIL PROTECTED] writes:
Fred I have to say that my discussions with US DoD and DHS/NCS,
Fred and with their counterparts in other countries, doesn't
Fred suggest that the set of technical mechanisms is all
Fred specified. If we're looking only at voice, it is
On 11/4/06 at 4:04 PM -0800, Fred Baker wrote:
Questions abound around the mechanisms for sending an email and
ensuring that it is delivered in a stated time interval on the order
of minutes or that an indication of failure is returned to the
sender...
That, in particular, seems like a
On 11/5/06 at 2:38 PM -0800, Pete Resnick wrote:
On 11/4/06 at 4:04 PM -0800, Fred Baker wrote:
Questions abound around the mechanisms for sending an email and
ensuring that it is delivered in a stated time interval on the
order of minutes or that an indication of failure is returned to
the
Hi,
We now have a fair amount of guidance on how to work with other
SDO's in general, which would certainly include ITU-T. Just to
summarise:
IAB Processes for Management of IETF Liaison Relationships,
BCP 102, RFC 4052, April 2005.
Procedures for Handling Liaison Statements to and from the
I have to say that my discussions with US DoD and DHS/NCS, and with
their counterparts in other countries, doesn't suggest that the set
of technical mechanisms is all specified. If we're looking only at
voice, it is maybe so, but they're not looking only at voice.
Questions abound around
On Wed, 1 Nov 2006, Sam Hartman wrote:
I don't believe the new charter of ieprep working group belongs in the
IETF. I understand why we chartered it here, and I believe that by
doing as much work as we have done so far in the IETF, we have done
something useful. We've described the broad
Excerpts from Sam Hartman on Wed, Nov 01, 2006 04:34:20PM -0500:
[I could not find the ITU's liaison to the IETF. Scott, if such
exists, I'd appreciate you forwarding this to them.]
The ITU-T's liaison from SG13 to the IETF is Hui-Lan Lu. CCed.
FYI SG13 is about to send something to the IETF
Sam,One of the objectives of the work produced by IEPREP was to lay down the ground work and put together a baseline set of requirements to start with when considering solutions. Our intention was that the baseline then becomes a starting point where more specific requirements can be put forth.
At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote:
On Wed, 1 Nov 2006, Sam Hartman wrote:
I don't believe the new charter of ieprep working group belongs in the
IETF. I understand why we chartered it here, and I believe that by
doing as much work as we have done so far in the IETF, we have
James == James M Polk [EMAIL PROTECTED] writes:
James At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote:
On Wed, 1 Nov 2006, Sam Hartman wrote: I don't believe the
new charter of ieprep working group belongs in the IETF. I
understand why we chartered it here, and I believe
ken == ken carlberg [EMAIL PROTECTED] writes:
ken Sam, One of the objectives of the work produced by IEPREP was
ken to lay down the ground work and put together a baseline set
ken of requirements to start with when considering solutions.
ken Our intention was that the baseline
ken Interestingly enough, the work that you mention below in your
ken original posting...
ken ... rfc-4542, rfc-4411, and draft
ken -ietf-tsvwg-vpn-signal-preemption (along with some other
ken related work) has actually not been done in IEPREP because
ken the group was
On Thu, 2 Nov 2006, James M. Polk wrote:
Having looked at the output of the WG,
it already seems to include a couple of useful framework documents and
about 4 requirements documents.
the framework RFCs are for within a single public domain. The other RFCs are
requirements based.
There
[I could not find the ITU's liaison to the IETF. Scott, if such
exists, I'd appreciate you forwarding this to them.]
Hi.
I'm speaking here as an individual. I'd like to build consensus for
my position both within the IESG and within the community, but I
realize that if I fail to build that
51 matches
Mail list logo
