Subject: [Ieprep] draft-ietf-ieprep-requirements-01.txt

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 15:29:27 -0500

Here are my own comments on this document.  There is some overlap
with Bill's comments, probably because before my current job I spent  
some years
engineering and operating a multi-continent commercial IP network.

	I've tried  to make specific suggestions on what edits I think are  
desirable
to create a more acceptable Informational document, by way of  
suggestion.  It is
conceivable that other kinds of edits (which didn't occur to me so far)  
would
also yield an improved document.

	I do think that it is desirable and useful to have Informational  
documents
from NCS and other organisations describing what kinds of IEprep  
capabilities they
desire to purchase.  A document from Japan on their IAA system would be  
particularly
helpful.

	I'm trying to organise my comments by the existing documents  
sectioning.
Global comments are marked "meta".

Ran
[email-masked]

------------------------------------------------------------------------ 
--------
Title:		This document does not discuss "requirements" in the usual IETF
			sense of that word.  So the title probably needs editing.  Something
			more like this (edit to taste) would be clearer all around:
				"US NCS Perspectives on Internet Emergency Preparedness"

Abstract:		Same issue as with the title.  The document does not discuss
			"requirements" in the usual IETF sense.  This use of "requirements"
			is pretty common in USG/DoD circles, but is not common in IETF
			circles.  Since the primary audience is IETF folks, not DoD folks,
			editing seems in order.  I'd suggest altering the abstract to say
			that the document outlines the current GETS services using the PSTN
			and the kinds of GETS-like services that NCS would like to be able
			to obtain (under normal business arrangement) from VoIP service
			providers that are interconnected with the PSTN.

Conventions:	This section and using the capitalised "MUST/SHOULD/MAY"  
are both
			inappropriate in an Informational status RFC.  That usage is normally
			only in a standards-track RFC (and rarely but sometimes in an
			Informational or Experimental protocol specification).  Suggest
			deleting this text.

Section 1,
meta:		It is unclear whether the author intends only VoIP applications
			when the phrase "Emergency Telecommunications Service" is used
			xor means other things in addition (e.g. email, web).  This needs
			to be made more clear at a minimum.  If only the voice applications
			are intended, that scoping needs to be a whole lot more clear than
			it is at present.

Section 1,
page 2:		The claim "...public networking facilities experience severe  
stress
			due to damaged infrastructure and heavy traffic loads." might be
			true for the PSTN.  I am aware of no evidence that this is true for  
the
			global Internet.  For example, on 9/11/01 the Internet did NOT
			experience severe stress or (unusually) heavy traffic loads,
			even though there was substantial damaged infrastructure  
(particularly
			in lower Manhatten, NY).  If the author means the PSTN, please say
			so.  If the author means also the global Internet, please add at
			least a formal bibliographic citation to documentation supporting
			the claim (also to include in the REFERENCES section of this draft).

Section 1.2,
page ?:		I think it is possible that the PSTN is migrating to VoIP, as  
this
			claims, but I do not think that it is certain to be the case.  The
			PSTN architecture is very much tailored for voice services and the
			Internet architecture is quite deliberately general (not tailored
			for voice services).  So it isn't really universally accepted that
			"convergence" is happening or guaranteed to happen.

			It would be helpful if this section were edited to make more clear
			whether the scope of this draft is primarily GETS-like voice
			(which is currently the bulk of the text in this draft) or some
			specific broader scope.

Section 1.3:	It would be better to rephrase as "user requirements" into  
something
			more like "NCS objectives" or "GETS objectives" or otherwise not
			use "requirements" in a manner that is not congruent with customary
			IETF usage of the word "requirements".

Section 2:	(Repeat comment on Section 1.3)

Section 2:	Does this mean just voice applications (as seems to be  
implied)
			or a broader range of applications ?  If the broader range, it
			would be good to clearly delineate the intended scope.

Section 2:	Which users should be able to use which public telecom  
resources ?
			Today, not all IP Carriers are fully connected with the global  
Internet.
			The degree of peering/connectivity of a given carrier is typically
			governed by a set of business contracts (whose terms are usually
			not disclosed publicly) which in turn cause BGP routers to be
			configured in particular ways.  The BGP configurations (and the
			forwarding tables derived from BGP) are the final determinant of what
			is actually reachable from a given location.  SLAs have roughly
			nothing to do with this.

Section 2:	Rather than saying "we assume the presence of a service  
level agreement"
			it would be better to say something like:
					Current GETS services provided using the PSTN are provided
			under normal commercial contracts between NCS and various PSTN  
carriers.
			NCS envisions that it will arrange analogous contracts with IP  
carriers
			in the future for all IEprep services used or managed by NCS."

Section 2:	IP is a datagram service.  It does not have a call setup  
phase.
			For the most part, the network is unaware of IP "sessions" existing.
			Certainly routers in the middle of the network are typically  
performing
			longest-prefix match forwarding of IP packets, with each packet being
			forwarded independently of each other packet.  Different packets in
			an IP flow might have different drop probabilities or different  
routing
			(and hence different latency or jitter characteristics).  This  
connectionless
			datagram nature of the Internet Architecture is fundamental, hence  
very
			unlikely to change.  The phrase "session is established" is fairly
			meaningless in terms of the IP layer or the Internet Architecture.
			The Internet Architecture does not even possess a Session Layer
			formally, unlike the ISO OSI Model.

Section 2:	The discussion about labels needs to be edited so that it is  
specifically
			limited/scoped to voice calls that need to interconnect with the  
PSTN.
			That discussion is quite irrelevant for non-IEprep disconnected VoIP
			services, such as the one Bill Woodcock manages.  The paper needs to
			reflect this reality.

Section 2:	"When networks reach traffic saturation..." needs to be  
edited to read
			"If networks reach traffic saturation...".  It is common today for
			large IP Carriers to over-provision their backbones such that the
			backbone cannot be saturated.  Access links not operated by that  
carrier
			(e.g. tail circuit into a Tier-2 ISP) might well get saturated, but
			it is not the case that all networks are vulnerable to saturation.

Section 2:	ETSI is a fine group, but their expertise is in GSM mobile  
phones
			and they do not define Internet Standards.  Internet Standards
			are the province of the IETF.

Section 2:	It is not possible to prevent denial-of-service attacks or  
many
			other kinds of attacks.  Carriers are typically NOT responsible for
			protecting customers from attacks -- customers are responsible for
			installing and maintaining their own security schemes (e.g.  
firewalls).
			So trying to place this burden on the IP Carrier is unreasonable and
			also inconsistent with the End-to-End Principle.

Section 2:	Most of the Internet does not have a concept of QoS.  For  
this reason,
			the concept of "degraded QoS" also does not widely exist.  This
			needs to be edited to scope it only to networks that happen to have
			some form of QoS.  Such networks might constitute the null set today.

Section 3:	Experience so far with real-time traffic, particularly voice  
and video,
			over the Internet is that the challenges are primarily in selecting
			appropriately resilient codecs/vocoders -- NOT in changing the way
			the IP network itself is deployed.  Experiments with use of  
Integrated
			Services (RSVP et alia) caused us to learn that such an approach  
cannot
			scale.  DiffServ/IP ToS cannot provide fine-grained QoS and has not
			yet proven itself to be deployable on the large scale in a commercial
			(not research) IP network.  Even the US DoD does not currently  
support
			DiffServ/IP ToS in its IP networks (in fact might not have *any* form
			of explicit QoS support today).

Section 4:	I am not sure what this means.

Section 5:	One of my concerns is that deploying additional mechanisms  
(e.g. QoS)
			into an IP network generally means increasing the vulnerabilities
			and operational risks of that network.  This ought to be noted here.
------------------------------------------------------------------------ 
-----------

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