Subject: Re: [Ieprep] updated requirements documents (general)

From: [email-masked]
Date: Thu, 12 Dec 2002 16:47:42 EST

Comments on draft -01:

This generally covers the requirements quite well.

1.1 List of existing standards:

H.GEF.4 is now H.460.4

3. General Requirements

2) The statement that "labels for different layers are NOT required to be 
related to each other" could be misinterpreted by some (regardless of the 
exact grammatical parsing of the words). The fundamental requirement detailed 
in draft-pierce-ieprep-assured-service-00 for one application presumes that 
the "label" which identifies the call level priority may affect the choice of 
a "label" which identifies the packet layer treatment. (Otherwise why have 
it?) This statement in the draft could be read by some to mean that this is 
not required (or even that it is not allowed). In any case, the upper case 
"NOT" by itself is not one of the key words defined in RFC 2119. Suggest that 
this sentence be reworded as:

"Labels for different layers are not required to be the same, but MAY be 
related to each other."

I believe this is consistent with what others have said it is intended to 
mean and would help avoid the possibility of mis-interpretation.

3) In the 4th paragraph, the sentence beginning "The relationship between 
unrelated labels..." seems a little strange. Perhaps it should say "The 
meanings of unrelated labels..."

4. Issues

1) Accounting: Following my presentation in Atlanta at which no objection was 
raised, this should be moved to the Requirements section. I suggest the 
following text, which I believe correctly reflects the need and avoids any 
bad implications:

9) Accounting (auditing)

Accounting represents a method of tracking actual usage of a service for 
purposes of capacity and trend analysis, cost allocation, auditing, and 
billing [RFC2975]. We assume that the usage of any service better than best 
effort will be tracked and may subsequently be billed to the user. Accounting 
for billing purposes is not addressed as a general requirement for ETS. 
However, solutions used to realize ETS should include the capability of an 
accounting mechanism to support auditing as defined in [RFC2975].

6. References should be corrected as follows:

2. Designation should be "ANSI T1.631-1993 (R1999)" It was reaffirmed in 1999.
3. Date should be "E.106, March 2000"
4. F.706 has not yet been approved, so list it as "draft" without a date. We 
hope it will be approved in May.
5. This has been approved as "Call Priority Designation for H.323 Calls", 
H.460.4, November 2002.
Add: "Introduction to Accounting Management", RFC 2975, October 2000.

Mike Pierce
Artel

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 13 Dec 2002 13:11:52 +0000

> 1.1 List of existing standards:

right, will do.

> 3. General Requirements
> 
> 2) The statement that "labels for different layers are NOT required to
> be related to each other" could be misinterpreted by some (regardless of
> the exact grammatical parsing of the words). The fundamental requirement
> detailed in draft-pierce-ieprep-assured-service-00 for one application
> presumes that the "label" which identifies the call level priority may
> affect the choice of a "label" which identifies the packet layer
> treatment. (Otherwise why have it?) This statement in the draft could be
> read by some to mean that this is not required (or even that it is not
> allowed). In any case, the upper case "NOT" by itself is not one of the
> key words defined in RFC 2119. Suggest that this sentence be reworded
> as:
> 

ok, I can make the change to the original passage so that it is similar
to your above sentence.

> 3) In the 4th paragraph, the sentence beginning "The relationship
> between unrelated labels..." seems a little strange. Perhaps it should
> say "The meanings of unrelated labels..."

I'll clarify the passage in the next version.

> 4. Issues
> 
> 1) Accounting: Following my presentation in Atlanta at which no
> objection was raised, this should be moved to the Requirements
> section. I suggest the following text, which I believe correctly
> reflects the need and avoids any bad implications:

I disagree with listing it as a requirement -- especially in the General
Requirements draft.  I have listed my objections in the past, as has
Henning and others on the list.  I have also stated on this list and
in the General requirements document that...

   Subsequent documents that articulate a more specific set of
   requirements for a particular service may make a statement about the
   following issues.

...and you've done that with the Pierce draft as it relates to MLPP.
Without revisiting the previous arguements, I'll leave it at that.

As for your presentation in Atlanta, I have to apologize that while i
was present, I was engaged in another conversation.  It was my
impression that your presentation was specifically scoped at MLPP and
not ETS as a whole, which may explain in part why there were no
objections.  And finally, working group consensus is predominantly
reached on the list.  I didn't hear a call for humms when you spoke :-)

> 4. F.706 has not yet been approved, so list it as "draft" without a date. 
> We hope it will be approved in May.

ok.  these will be changed.

> Add: "Introduction to Accounting Management", RFC 2975, October 2000.

I may add it in.

-ken

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 08:21:52 -0500

On Thursday, Dec 12, 2002, at 16:47 America/Montreal, [email-masked] 
wrote:
> be related to each other" could be misinterpreted by some (regardless 
> of the exact grammatical parsing of the words). The fundamental 
> requirement detailed in draft-pierce-ieprep-assured-service-00 for one 
> application presumes that the "label" which identifies the call level 
> priority may affect the choice of a "label" which identifies the 
> packet layer treatment. (Otherwise why have it?)

One reason to have a label in SIP, even if lower-layer labels don't 
happen to be in use,
might be to ensure that a telephone voice-call whose signalling path is 
PSTN--SIP--PSTN
does not lose any labels that originated on the PSTN side (where they 
might be
more meaningful) just because it transited a SIP segment.

>  This statement in the draft could be read by some to mean that this 
> is not required (or even that it is not allowed). In any case, the 
> upper case "NOT" by itself is not one of the key words defined in RFC 
> 2119. Suggest that this sentence be reworded as:

(There is precedence for capitalising NOT in standards-track RFCs, so 
that
is not at issue here.)

> objection was raised,

Disagree.  There were several objections from operators during the 
meeting.  I was
in the room.  Moreover, the list discussion takes precedence over 
in-person meetings
under IETF process rules (unlike with some other standards groups).  
And there are
numerous unresolved objections here on the list -- mainly because you 
haven't made
it clear what exactly you want to account for.

It would help further discussion a great deal if you could be more 
clear and very
specific in what objects you want.  Depending on what they are, folks 
here might
well agree with the specifics.

The root problem with your proposal remains the same.  Your proposal 
does not make clear
what sorts of objects you want accounting to be performed on.  A number 
of us might
withdraw our objections if you could be a lot more clear about this.  I 
noted this
on list specifically before the presentation and (in vain) asked that 
the presentation
make this clear.  The presentation did not make it clear.

>  this should be moved to the Requirements section. I suggest the 
> following text, which I believe correctly reflects the need and avoids 
> any bad implications:
>
> 9) Accounting (auditing)
>
> Accounting represents a method of tracking actual usage of a service 
> for purposes of capacity and trend analysis, cost allocation, 
> auditing, and billing [RFC2975]. We assume that the usage of any 
> service better than best effort will be tracked and may subsequently 
> be billed to the user. Accounting for billing purposes is not 
> addressed as a general requirement for ETS. However, solutions used to 
> realize ETS should include the capability of an accounting mechanism 
> to support auditing as defined in [RFC2975].

Disagree.  I'd be happy to add text saying that a solution "must not 
preclude
an operator from performing accounting", but not text making it a 
requirement.

Ran
[email-masked]