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,
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
milesto
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
> co
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
th
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 underst
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 applica
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 c
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 t
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, w
> "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 objec
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:
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 r
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 singl
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
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 a
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 PST
> 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 pri
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) applica
ietf@ietf.org; ieprep@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
> &
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 the
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
> "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
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
(I
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 doesn
(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
th
> 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
> "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 infini
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 larger-but-well-define
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
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
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
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
> "Janet" == Janet P Gunn <[EMAIL PROTECTED]> writes:
Janet> It seems to me that there are two separate issues.
Janet> First, should this work be done within IETF, or would it be
Janet> better done in ITU (or ATIS, etc.)?
Janet> Second, if it is done within IETF, should it be
ietf@ietf.org
Subject
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
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 onl
> 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 extensi
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
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 relat
> "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
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 th
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 t
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.
>
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 w
> "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 th
> "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,
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 d
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. O
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 IET
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
[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 con
52 matches
Mail list logo
