[Ieprep] ieprep minutes San Francisco

["King, Kimberly S." <[e-mail]>]

IEPREP Meeting Notes

Internet Emergency Preparedness WG (ieprep)

Wednesday, March 19 at 1300-1500 
================================

CHAIRS: Scott Bradner   <[e-mail]> 
        Kimberly King   <[e-mail]>

AGENDA:

		agenda bashing	
                Chairs
5 minutes

		draft-polk-ieprep-flow-model-considerations-00.txt
                James Polk
10 minutes

                draft-ietf-ieprep-framework-04.txt 
                draft-ietf-ieprep-ets-telephony-02.txt
                draft-ietf-ieprep-ets-general-02.txt                     
                Ken Carlberg
20 minutes

                ETS progress at the ITU 
                Stephen Perschau
10 minutes

                ieprep next steps
                Group discussion
25 minutes
----------
70 minutes

James Polk -> flow model considerations
Informative document on an information track

Delineate the control plane from the data plane
Signaling/Control Plane between the responder and initiator
Data plane between the responder and initiator
	
Major change will be to add a new diagram

And change wording around QoS

Questions:
An email suggestion to add SAP, but unsure of its relevance.

Ken Carlberg -> ETS General Requirements
Changing IPprep to IPPREP

Changing "better than best effort" around application layer mechanisms to
"other than best effort".

Changing:

	don't refer to VoIP as "other elastic application"

	change "carriers" to "telephony carriers"

expand the reference of "higher probability" to refer to call completion

	removed term "centralized authentication" in reference 
	to PSTN security model

TBD: 
	refer to Genuity and Sprint Traffic Engineering in Atlanta IETF

request for discussion of service that makes a positive difference

	original comments aimed at general requirements

More to be added (but perhaps premature):
	DCCP -> spec due on Dec' 03
	NSIS
	UDP-Lite

Questions:
Dennis Berg: I am trying to understand the character of a framework document
vs. a best practices document, etc. It seems to not go all the way in coming
out with a set of requirements

Scott Bradner: This is an IETF meta-question, frameworks are not meant to be
specific.  Frameworks describe the environment in which we are playing.  The
requirements are how to build the swing set.  Frameworks are not
descriptions of what you must do but describe the environment.  

Dennis Berg: Are we going to move forward with a requirements documents? Not
quite clear: high probability of completion and guarantee of completion
objective of not expecting every network or portion of a call path to be
enhanced with this work.  In other words, partial deployment is a
compromise, not a goal.

Scott Bradner: An absolute requirement for absolute reliability would imply
more resources, i.e. more bandwidth.

Dennis Berg: should just say to do a little bit better (perfect would be the
panacea, but...) at least.

Janet Gunn: One of the requirements that I would like to see is if there is
a call admission process, that there is priority in the call admission
process (call setup), even if it means simply trying again (and this goes in
the telephony requirements doc).

Ken Carlberg: That type of requirement would be in ip tel requirement
document.  He asks Janet to sent some potential text for the document.

Bill Woodcock: These problems aren't network related the network is already
doing better than PSTN call completion, so the expectation between
circuit-switched network and packet-switched network folks is completely at
odds.

Scott Bradner: We postulate that the backbone isn't the issue, but problems
are more in the access networks such as cable networks or enterprise
networks.

Bill Woodcock: We keep requiring methods, not service requirements, and no
one has demonstrated that calls are not being completed, so is there really
a problem?

Scott Bradner:  Some people want it and will pay for it so let them do so.

Bill Woodcock: That is not what IETF is here for.  No one has demonstrated
that there is a problem.

Scott Bradner: If there is no need then it will die its death and we don't
need lots of protocol development anyway.

James Polk: Just because there hasn't been an issue doesn't mean there won't
be one

Dick Knight: I am agreeing that the problem is in the access network, not
the backbone.

Scott Bradner: also the gateway

Dick Knight: How does one do authentication, massive processing, etc. in a
congested environment?  There isn't enough information about this in the
drafts.

Scott Bradner: and authorization

Eric Rescorla : If we cannot simulate the problem, how can we test a
solution?

Janet Gunn: There aren't a great deal of SIP phones at this point, and there
will be critical mass at some point

Dave Crocker: Theoretical possibility of the infrastructure being a problem
is real, and the potential damage is significant, so placing concern is
good. The question is resources, and this working group has yet to produce
so focus on the backbone should only be done after other issues have been
solved.

Peter Lothberg: Who is the operator that is the problem here? There is
decoupling between the access point and the backbone provider.

Dennis Berg: I have a procedural question.  What is the relationship between
your documents and Henning's RFC 3487, is there order of precedence and
overlap? Or a contradiction? 

Greg Woodhouse: In D.C. on 9/11, and the cell phone was his only means of
communication.  

Stephen Perschau -> ITU-T progress
E.106 description of an International Emergency Preference Scheme for
Disaster Relief Operations adding support for packet networks

Supplement to J.160 architectural framework for the delivery of
time-critical services over cable data networks

J.ETS new recommendation addressing emergency telecom over cable data
networks

Study Group 11
including support for an international codepoint for ETS

Study Group 16
Question I use of public telecom services for emergency and disaster relief
operations

Study Items
identify organizations addressing the various aspects related to telecom for
emergency and disaster relief operations

	working on security aspects for authentication of users and
prevention of interference

	TDR standardization (British Telco's might not be reimbursed if ETS
term was used in place of TDR so the name was changed)
	
Questions:
Brian Rosen: The codepoint in SG 11 is an ISUP codepoint right?

IEPREP Next Steps:
Scott Bradner: We should not assume that the backbone is a part of the
problem at the moment.

Comments:
Janet Gunn: The one thing in the charter that we haven't played with is the
BCP

John Gilmore: To what extent is the discussion here to deny service to
non-authorized users? Will non-authorized traffic simply be dropped?

Scott Bradner:  I'm reluctant to support turning off everyone.  I think
civilian should communicate just as much as government.  I suggest few ISPs
to convert to ETS only as their customers wouldn't stand for it.  

John Gilmore: Some governments declare "emergency" to curb communications.

Steve Silverman: if the prioritized traffic is less than 10% of the rest,
the impact is small.

Dan Romascanu: The issue of E911 traffic hasn't been addressed here.

Thorsten Claus (?): from a SP perspective, how can I invest money in
building my network for working with the government?  Are there any business
cases?

Janet Gunn: Money is paid for service provider and to the vendor for
software changes for GETS capability, maybe that will happen here... I  have
never seen any desire to block non-authorized traffic for any reason other
than call completion. There has never been any intention to make this only
available to government workers. There is a precedence for putting in
mechanisms for limiting the GETS type traffic.

Brian Rosen: One should not assume that this is only for voice.

Dave Knight: Globally, the US is not paying other countries to put this
stuff in (applause).

Dennis Berg: Service Providers are paranoid about E911 traffic. Should make
a note about the position about IEPREP capabilities vs. E911 support.

Janet Gunn: working on 911 issues for WPS, the PSAPS do not want
preferential treatment.  Human resources are the constrained resource.

Keith Dredge: can E911 be out of the scope for this group?

Scott Bradner:  E911 is being worked in SIPPING.  E911 is out of scope for
IEPREP.

Jon Peterson: believes that working on the access points, links, and
enterprise networks is going to be time consuming and difficult but says
okay if IEPREP has the stomach for it.

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