Subject: Re: [Ieprep] requirements document(s)

From: [email-masked]
Date: Wed, 18 Sep 2002 23:46:52 EDT

Ken,

Some comments on the two drafts:

draft-carlberg-ets-general-00

1.1 The list of existing standards should include:
T1.619 (MLPP in the US)

2.1 The statement that "adhering to regulations and laws of governments is 
out of scope" seems a little strong and could be misleading, causing some to 
think that the IETF is going to ignore the presence of existing regulations 
and produce something that can not be legally used in many countries. This 
needs to be rewritten to recognize that there are government laws which 
carriers must comply with and that this work in the IETF will attempt to 
provide the framework for that compliance. I suggest the following rewrite of 
this sentence:

Further, the specification of requirements to address specific regulations or 
laws of governments is also out of scope of this document, however, the 
efforts MUST take into account the existence of regulations in various 
countries with which carriers will have to comply.

The sentence following this one about "sound technical positions" should be 
deleted. Everyone should know this, and it seems to be saying "rather than 
concerning ourselves with laws..." (which admittedly are not always "sound").

3. General Requirements

2) It is unknown how to interpret the statement that "labels for different 
layers are NOT required to be related to each other". The fundamental 
requirement detailed in draft-pierce-sipping-assured-service-02 presumes that 
the "label" which identifies the call level priority will be mapped into a 
"label" which identifies the packet layer priority or preferential treatment 
class. This statement seems to explicitly say this is not required.

3) It is unknown what the statement that "Policy MUST be kept separate from 
the label(s)" means as a requirement. Unfortunately, this issue (policy) has 
caused much disagreement in the past, and this hard statement could be 
interpreted by various people to defend various positions. The real meaning 
of this needs to be expressed without assuming that everyone has the same 
concept of what "policy" means or what a "label" is in this context.

There are "policies" by which a government or carrier authorizes someone to 
use a particular priority level. Of course, this is not carried in the label, 
so one could say it is "separate". There are "policies" that the end user is 
supposed to apply to decide when to use a priority, so they are not exactly 
"separate", but clearly not included with the "label". Also, there are 
"policies" regarding what a carrier does with specific values of "labels" it 
finds in signaling, headers, etc. This really isn't "separate" from the 
label, and could be coded with the "label" at a proxy or gateway.

4. Issues

1) Accounting should be moved to "Requirements". It is a fundamental 
requirement as detailed in draft-pierce-sipping-assured-service-02.

2) Admission Control - In a congested network, admission controls to prevent 
new low priority calls from being setup is a requirement.

draft-carlberg-ets-telephony-00

1.1 Reference should be T1.631.

2.1 This section, as written, should not be necessary. It must be generally 
understood that all documents produced by the IETF share this situation - 
they do not, by themselves mandate any carrier to follow them. The 
over-emphasis on the point here might make somone wonder.

3. Since the title and purpose of this document is to address the 
requirements for "IP-telephony", it should address the requirements for 
end-to-end provision of a telephony service. Therefore, the statement that 
"the following requirements explicitly do not relate to IP-layer mechanisms" 
should be removed. In fact, it really should not state requirements for the 
non-IP protocols, since the IETF has no control of those protocols. It should 
refer to what non-IP protocols do, and state the requirements for what the 
IP-protocols must do and how they must interwork.

1) IP signaling (SIP) MUST be able to carry labels.

Mike Pierce
Artel

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 19 Sep 2002 15:03:34 +0100

> 1.1 The list of existing standards should include: 

ok, it'll be added.

> 2.1 The statement that "adhering to regulations and laws of governments
> is out of scope" seems a little strong and could be misleading, causing
> some to think that the IETF is going to ignore the presence of existing 
> regulations and produce something that can not be legally used in many 
> countries. This needs to be rewritten to recognize that there are
> government laws which carriers must comply with and that this work in
> the IETF will attempt to provide the framework for that compliance. I
> suggest the following rewrite of this sentence: 
>
> Further, the specification of requirements to address specific regulations
> or laws of governments is also out of scope of this document, however,
> the efforts MUST take into account the existence of regulations in
> various countries with which carriers will have to comply. 

taken literally, your above suggested change with the use of "MUST"
means that people are going to have to be familiar with regulations
of 160(?) countries and anywhere between 10-50(?) times that number of
legal jurisdictions.  thats not the path to travel.  

so i'll gladly be corrected by the chairs, ADs, or any of the other
powers that be, but the bulk of the working groups of the IETF only
focus on technical standards.  i don't recall any RFC from a working 
group that said, "because of regulation X, do Z".  nor do i recall
any working group charter that mentions country laws and regulations.
the only exceptions I can think of are ones that deal with the IETF
process (eg, POISON).

we simply need to get across that these are technical requirements.

> The sentence following this one about "sound technical positions" should
> be deleted. Everyone should know this, and it seems to be saying "rather
> than concerning ourselves with laws..." (which admittedly are not always 
> "sound"). 

I'll take out the word "sound" since it would seem obvious.  the sentence
itself, is what is roughly what I just stated above -- ie, the focus
of the IETF is technical issues and the Internet architecture.  it seems
I'm a bit more pesimistic than you and don't believe that this is
obvious to everyone.  <i expand on this a bit at the bottom>

> requirement detailed in draft-pierce-sipping-assured-service-02 presumes
> that the "label" which identifies the call level priority will be mapped
> into a "label" which identifies the packet layer priority or preferential 
> treatment class. This statement seems to explicitly say this is not
> required.

an example of what I meant would be:  I may have a label in the 
application layer (eg, SIP) that states "authorized-emergency", and I 
may use a DSCP value of AF21 at the network layer for that same datagram.
these labels are from different layers and are not directly related to
each other.  the goal in "my" using them may be the same to improve the
probability of traffic reaching its destination may be the same, but 
specifics of how this is accomplished for each label is different.  

what i can probably do is to modify what was written to make this more 
clear.

> 3) It is unknown what the statement that "Policy MUST be kept separate
> from the label(s)" means as a requirement. Unfortunately, this issue
> (policy) has caused much disagreement in the past, and this hard statement 
> could be interpreted by various people to defend various positions. The
> real meaning of this needs to be expressed without assuming that everyone
> has the same concept of what "policy" means or what a "label" is in this 
> context. 

we shall expand on the requirement to provide additional clarity and rely
on the consensus of what has been discussed on the list about this topic.

> requirement as detailed in draft-pierce-sipping-assured-service-02. 

however, the pierce draft is not representative of all IP telephony.
accounting generally is associated with billing.  there may be an
organization that chooses a flat-rate fee type SLA.  given an 
accompanying authentication/integrity service, they may choose not
to use accounting.  hence, i don't see a need to *require* them to
use have a separate accounting mechanism.

if the group decides the follow the separate requirements model we have 
proposed, then it may be better to migrate the pierce draft into one that 
lists additional requirements for MLPP

> 2) Admission Control - In a congested network, admission controls to
> prevent new low priority calls from being setup is a requirement. 
 
if I'm a tier-1 provider, and my customer is satisfied with an SLA
that simply segments labeled traffic into a different virtual path and 
over-provisioning is the method contracted to achieve a high
probability of forwarding the traffic through the network, then that
provider shouldn't be required to support an Admission Control mechanism.

this follows the theme of the document in that we make no assumptions
about the labels or what is to be done with them.  in the above, you use
the term "prevent".  what if I choose the term "reduce the probability"?
which term would be used as a requirement?

again, perhaps its best to have a subsequent MLPP draft that offers more
specific set of requirements that apply to it.

         =================================================

> 1.1 Reference should be T1.631. 

ok, will be done.

> 2.1 This section, as written, should not be necessary. It must be
> generally understood that all documents produced by the IETF share this 
> situation - they do not, by themselves mandate any carrier to follow
> them. The over-emphasis on the point here might make somone wonder. 

i agree that the section should not have to be stated, but unfortunately,
your assumption is not correct.  there are non-technical people who do
not understand that IETF documents do not represent mandates to carriers.  
and i've been rudely given the riot act about this from technical 
people.  the statement needs to be there.

> end-to-end provision of a telephony service. Therefore, the statement
> that "the following requirements explicitly do not relate to IP-layer
> mechanisms" should be removed.

recall that we talk about network functionality in the General Requirements
draft, and that the Telephony Requirements are an *extension* of the
General Requirements.  we don't need to repeat that section, and none of
the requirements listed refer to the IP layer.  if someone suggests a
network requirement that doesn't apply to all applications and is specific
to the general case of IP telephony, then we'll remove the statement.

> In fact, it really should not state
> requirements for the non-IP protocols, since the IETF has no control of
> those protocols. It should refer to what non-IP protocols do, and state
> the requirements for what the IP-protocols must do and how they must
> interwork. 

yes, point taken about mentioning non-IETF protocols.  they shall be
removed from the text.

> 1) IP signaling (SIP) MUST be able to carry labels. 

yes, that first requirement will be modified.

-ken

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