Re: I-D ACTION:draft-ietf-ieprep-framework-03.txt
Ken Carlberg <K.Carlberg <at> cs.ucl.ac.uk>
2003-02-15 20:27:39 GMT
> Abstract
> Is there a definition of "stub domain"?
definitions and references can be found in rfc 1631, 3022, 1322, 1364,
1477, 1478, 1745, and some others
> 1.1.1
> NCS is now part of the Department of Homeland Security.
I'll note this in the next version of the draft
> The non governmental participants in GETS are a LOT more than "a select
> set of individuals" I THINK the GETS users are split roughly 50/50
> between government and non government users.
i think "select set of individuals" is fine. nothing breaks with the
phrase and it doesn't relate to size. but the point is taken that the
system is not just a collections of users from the govt.
> 1.2
> Should say "...interactive voice has a lower threshold of loss than
> elastic applications..." NOT "...than other elastic applications..."
> Interactive voice is NOT an elastic application.
the change will be made.
> What do you mean by "carriers"?
telco carriers. i've not come across the term carriers in association
with ISPs. however, i shall extend the term so that it will read as
"telecom carriers"
> "...some of the protocols of discussed in section 4..."
> should be
> "...some of the protocols discussed in section 4..."
the change will be made.
> Section 2, pg 6
>
> When talking about "higher probability" it would be helpful to define
> "higher probability than WHAT". I am assuming it means "higher
> probability than for an equivalent non-emergency call".
ok. additional verbage will be added to provide a point of comparison.
> I don't agree with the statement "... probability ... cannot easily be
> quantified." I quantify probability all the time.
the meaning statement is within a larger context as stated below:
The critical word in this objective
is "probability", as opposed to assurance or guarantee -- the latter
two placing a higher burden on the network. It stands to reason,
though, that the word "probability" is a less tangible description
that cannot be easily quantified. It is relative in relation to
other traffic transiting the same network.
I'm not sure its fair to cut out so much of what is stated and expect
the parts to stand on its own. as I stated in the comments on the
General Requirements, aspects such as delay, loss, and jitter can be
(within limitations) addressed by the network. so if one is going to
focus on probability, which of those three does one concentrate on? to
me, that not an easy question to make a definitive statement about.
> Some kind of weird formatting "=A0" before "Hence, ..."
its a problem i have with NROFF. i'll fix it in the next release.
> Pg 7
> "More
> specifically, we associate this objective in the context of IP
> telephony acting as part of the Public Telephone Network (PTN).
> This, as opposed to the use of IP telephony within a private or stub
> network."
>
> Might want to put this in the scope section.
noted.
> "a higher probability
> of call completion than that of normal IP telephony call traffic."
>
> Might want to say this earlier.
noted
> Pg 8
> Authentication is not necessarily centralized.
page 8 doesn't have any word on authentication. is there a specific
phrase or sentence that you were concerned about? your statement is
a bit general and I'd rather not read things into that may not be
there.
> Section 3- First sentence needs to be reworked to reflect that you now
> have TWO (not just ONE) objectives.
ok, the change will be made.
> Pg 11 reference to Henning's document - it no longer refers explicitly
> to headers.
the original passage is:
[15] is a (soon to be) RFC that defines the requirements for a new
header field for SIP in reference to resource priority. This new
header field is meant to provide an additional measure of distinction
that can influence the behavior of gateways and SIP proxies.
my understanding is that it pertains to requirements for a header *field*.
so yes, we are in agreement.
> Pg 12 Here you introduce MLPP. Would it make sense to also discuss it
> in section 1.1?
i'll give it some thought.
> Pg 15. This statement is NOT true:
> "As a point of reference, existing SLAs established by the NCS
> for GETS service tend to focus on a maximum allocation of (e.g., 1%)
> of calls allowed to be established through a given LEC using HPC.
> Once this limit is reached, all other GETS calls experience the same
> probability of call completion as the general public. "
>
> GETS is ENGINEERED for 1% GETS calls, and some of the SLAs refer to such
> a limit, but there is NO real time MECHANISM to track GETS usage, and NO
> real time MECHANISM to change the treatment of GETS calls.
you've totally lost me. if you claim that my statement of "SLAs...focus
on a maximum allocation" is incorrect, how can you then state that "SLAs
refer to such a limit"? are the words "focus" and "refer" that different?
we have also had private discussions of how some vendors provide limits
on trunk queuing used for GETS calls. is that not a real-time
functionality? usage of a service, and in particular its individual
components, can be in several forms. my original passage does not refer
to a specific form nor where limits exist.
> In WPS (the wireless extension to GETS) there IS a traffic threshold
> (25% WPS in a single cell) beyond which the priority treatment for radio
> channels changes. But NOT in GETS.
ok. but as stated above, i did not refer to a specific form of
threshold or mechanism used to achieve it int he original passage.
> Under "traffic engineering", might it make sense to discuss the Sprint
> and Genuity access link traffic engineering approaches described in
> Atlanta.
I'll review what was presented to see what can be added to the TE section.
> Pg 16.
>
> In general, PSTN authentication does NOT need to be PIN based. WPS
> authentication is not PIN based, and, for GSM, not centralized. In
> discussing generic PSTN based priority systems, it would be helpful to
> describe them in a way which encompasses both WPS AND GETS. (WPS is now
> operational, at least as "IOC phase 1".)
i'll defer my response to Ian on this.
> Section 5 Key Scenarios
>
> "imply", not "infer"
ok
> Pg 18
> "The fact that
> each administrative domain peers with each other as part of the PSTN,
> means that existing security, in the form of Personal Identification
> Number (PIN) authentication (under the context of telephony
> infrastructure protection), is the default scope of security. "
>
> No longer true. WPS authentication "exists" (went live Dec 22), and is
> NOT PIN based. To describe PINs as the "default mechanism" WOULD place
> "additional requirements on existing authorized emergency telephony
> systems."
understood about WPS and its use of the unique SIM identifier. again,
i'll defer to Ian on the subject of security. however, i have a
question about the subject of PINs. Is there a general term that
encompasses the use of PINs (the numbers that people use to identify use
of service) and unique identifiers used to phone SIMs? in my ignorance,
I thought that these two unique identifiers could be termed as PINs.
> Page 22
>
> Under standards work, you might want to make reference to the changes to
> the CDMA standards to support emergency traffic. Like the CPC, there
> MAY be a need to translate these new parameters into SIP, etc.
if we add info into the body of the document refering to CDMA standards,
then we'll certainly add the corresponding reference.
regards,
-ken
that came out
right after I submitted version of the Framework draft. hopefully, in
short period, two others will also be replaced by RFCs.
-ken
RSS Feed