Subject: [Ieprep] What is ieprep?

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 6 Nov 2002 12:25:15 -0500

There have been several questions about the scope/context/process/etc. of
this working group.  For clarity, I've aggregated several of Scott's guiding
words (below).

On deliverables:

"the 1st deliverable of this group is a requirements doc to SIPPING
that doc will, by definition, be talking about things that are not
present in SIP

the 2nd deliverable is a document that says what we can and can 
not do in ISPs and the Internet with existing Internet technology 

a number of IDs have been submitted to the WG that go beyond
what is doable in today's Internet

I think that the 1st pass on these documents have to reflect
what is possible with today's Internet technology -

after we have that we can start looking at requirements that imply 
changes in IETF protocols (aside from SIP which we are already doing) - 
any such requirements will have to be delt with in the way that
the SIP requirements are being delt with - writing a document that
describes specific requirements for a specific IETF protocol (more
than one document if there are more thna one IETF protocol) which
would then be forwarded to the working group responsibe for the
protocol (if any, if there is no such working group, one might
have to be formed)

there is a bigger problem with developing requirements that imply
rearchitecting ISPs or the Internet - that seems unrealistic, and
requirements that define business practices for ISPs - that is
an area that the IETF specifically avoids"
____________
On the context of the work:

"Henning sez:
> While your view certainly represents the "traditional" Internet view and 
> current operational practice, one should not forget that there has been 
> a large body of more recent research work related to QoS routing.

this brings up two questions to me

1/ how close is that research to being deployed in ISPs?

and more importantally

2/ should this WG be talking about what the Internet can be expected
   to be able to do now or in the immediate future (see 1st deliverable
   in the WG charter) of speculate on what might be possible at some
   point in the future?

(my feeling, if its not clear, is that we should stick to the world
of today and the near future)"
_______________

On requirements:

"I think that we need to be quite careful
to specify whether we are talking about what requirements can be met on the
Internet (and private IP networks) with existing or near-term technology
and what would require significant new technology development.

I think that we also need to be careful to say what requirements can be met
with the current Internet architectural model (of autonomous
interconnecting with no particular service guarantees) and what would
require a change in this architectural model.  Along this line, we should
also be careful to say which requirements are targeted at use within an
enterprise (such as a telephone company using IP internally), at a single
ISP and which are expected to be able to be met for traffic spanning ISPs
in the open Internet."
_____________
On working with SIP and SIPPING...

"this group can say that there are problems X & Y that need to be
solved for ieprep to work with SIP - it can not tell SIPPING
(which gets the requirement 1st)  that solving the problems means 
that a new header is needed - i.e., defining how to meet the requirement is
not IEPREP's job 

SIPPING  will then take a look at the requirement to see if it:
1/ can be met in some way with SIP as-is that the ieprep did not figure out,
   even if the solution is not as "efficient" as IEPREP might like
2/ can be combined with other resuirements that SIPPING has received
   from other WGs or individuals, and can be reworked to make the
requirement
   more general to solve a wider class of problems, (SIPPING
   might on its own do this w/o the need for specific other requirements
   being submitted)
3/ does not make sense
4/ deals with too narrow a situation to warrent changing SIP ("you can't
   always get what you want, but you generally get what you need")
5/ makes sense as-is

in case 1 SIPPING responds to ieprep - 'here is how to do it'
in case 3 it sends back a "huh?" message
in case 4 it sends back a 'no, and here is why' messgae
in case 2 & 5 SIPPING sends the requirement on to SIP which
then figures out how best to meet the requirement

IEPREP can make a suggestion on how to meet the requirement but SIP
can reject the suggestion if SIP thinks that the ieprep
suggestion is the wrong way to meet the requirement (I do not suggest that
IEPREP should spend time coming up with such suggestions)"

_________
On capacity/context

"this WG does have to think about the case where there is not enough
capacity in the IP network on the path that a data stream will use

the lack of capacity might be restricted to tail circuits, as might
be the general case in US wireline ISPs, or in the infrastructure - the
WG should not worry about the case where the IP path spans multiple ISPs

but the current deliverable is to say what in this space can be
supported using existing IP protocols - it is not to invent new ones"

Thus, we are converging on a more defined understanding of ieprep.  This is
good.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 6 Nov 2002 09:37:42 -0800 (PST)

On Wed, 6 Nov 2002, King, Kimberly  S. wrote:
    > that a new header is needed.

Okay, these seem very clear.  Particularly, they seem clearer than
"Informational: Requirements for Internet Emergency Preparedness in the
Internet. Framework for Supporting Internet Emergency Preparedness in IP
Telephony."  Perhaps that sentence of the charter should be updated?
Maybe something like "Informational: Desired Features Supporting Emergency
Telephony in a SIP Environment."

                                -Bill