Subject: Final Roundup Of Issues

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Apr 2000 23:20:32 -0500

I have seen no comments on the errata document update I sent out earlier
this week.  What follows is a set of issues and proposed resolutions which
have been under discussion or have been noted in the intervening days.  I
propose to update the errata document with the contents of this E-mail, then
submit it as a formal I-D.  If there are no further comments tomorrow I will
forward it to the IESG for final approval.

Section: 7.2.5, Annex B.2
-----------------
Issue: the text of 7.2.5 allows retrieval of multiple digit maps with one
AuditValue command if the terminationId is ALL.  There is no ABNF syntax to
support this return result.  Note that Annex A has no restriction on the
number of instances of any descriptor in either a command or a response.

Proposed Resolution: add digitMapDescriptor to the exceptions to the
"at-most-once" comment preceding ABNF production auditReturnParameter.

Section: 7.2.5, Annex A.2, Annex B.2
-----------------
Issue: the text in section 7.2.5 mentions that using an empty Audit
descriptor with a wildcarded terminationId is a way to get a list of the
terminations in the context.  Annex A provides the possibility that the
auditReply may be a contextAuditResult of type terminationIdList, and Annex
B allows for an auditReply containing a contextTerminationAudit which in
turn presents a terminationIdList.  The connection between the text in 7.2.5
and these special forms of audit result is not clear.  Moreover, a note at
the beginning of Annex A section A.2 limits terminationIdList to one
terminationId.

Proposed Resolution: add the following text in section 7.2.5 after the
sentence "This may be useful to get a list of TerminationIDs when used with
wildcard.":
"Annexes A and B provide a special syntax for presenting such a list in
condensed form, such that the AuditValue command tag does not have to be
repeated for each terminationId."
Also, in the Note at the beginning of section A.2 of Annex A, provide an
exception on the length of type TerminationIdList when used in
contextAuditResult.

Section: 7.1, Annex A.2, Annex B.2
-----------------
Issue: it is unclear how to express empty descriptors in responses to the
MGC.

Proposed resolution: In section 7.1, add the following text after the
sentence: "Descriptors may be returned as output from a command.":
"In any such return of descriptor contents, an empty descriptor is
represented by its name unaccompanied by any list."

In the ASN.1, add the following choice to the AuditReturnParameter
production:

  "emptyDescriptors               AuditDescriptor,"

Note that this introduces a dependency which may force reordering of the
AuditDescriptor and AuditReturnParameter productions.

In the ABNF, add the choice auditItem to the production
auditReturnParameter.  Redraft the preceding "At-most-once" comment to say:
"; at-most-once for any descriptor or its token, except possibly for
errorDescriptor"

Section: 7.1.11, Annex A.2, Annex B.2
-----------------
Issue: There is a need for the MGC to be aware of signalling failures.  It
is not possible to use the signal completion event to monitor for signalling
failures only, without also having to process successes.

Proposed Resolution: In section 7.1.11, replace the current text on
completion notification, beginning: "Finally, the optional parameter
"notifyCompletion" ..." and continuing to the end of the paragraph with the
following text:

"Finally, the optional parameter "notifyCompletion" allows a MGC to indicate
the circumstances under which it wishes to be notified when the signal
finishes playout.  The possible cases are that the signal timed out, that it
was interrupted by an event, that it was halted when a Signals descriptor
was replaced, or that it stopped or never started for other reasons.  If
"notifyCompletion" is absent, notification is generated in the "other
reasons" case only.  For reporting to occur the signal completion event (see
section E.1.2) must be enabled in the currently active Events descriptor."

In Annex A.2, make notifyCompletion a BIT STRING with the four cases.  In
B.2, make it a parameter consisting of a name and a list of values
representing the possible completion methods.

Section: 8
-----------------
Issue: unclear what state the MG is in if a command fails.

Proposed Resolution: add the statement:
"If a command fails, the MG shall as much as possible restore the state
which existed before execution of the command began."

Section: E.9.2
-----------------
Issue: where hook state differs from the expected one, it is sometimes
desirable that the command fail rather than proceed anyway.

Proposed Resolution: change the possible values for the proposed Strict
Transition EventsDescriptor parameter from On/Off to "State" /
"TransitionOnly" / "Fail", meaning respectively that the event is reported
as soon as the desired state is reached, or is reported only when the
indicated transition is next observed, or the command fails if the hook
state is not as expected.

Also add a new package-specific error code with explanation "Unexpected Hook
State".

Section: Appendix A.1.2
-----------------
Issue: incorrect statement that an RTP termination has no events or signals.
Missing descriptors in the reply as compared with the request in the
previous step.

Resolution: delete the offending sentence.  Add the line "Events, Signals,
DigitMap," after the end of the Media descriptor to show that these other
descriptors are empty.

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: [email-masked]

---

From: Christian Groves <[email-masked]>
Date: Fri, 28 Apr 2000 15:17:30 +1000

G'Day Tom,

An additional one which has just been discussed:
Section: 7.2.5 & 8.1.2
-----------
Issue: Unclear whether wilcarded ALL on contextID includes the NULL
context.
Proposed Resolution:
8.1.2,
"The MGC may use the ALL wildcard to address all Contexts (except the
NULL context) on the MG."

7.2.5
All     wildcard        Audit of all matching Terminations not in the
                        NULL context and the
                        Context to which they are associated

Could you also wait for until Monday to send the draft as different
timezones need time to look at it?

Regards, Christian

Tom-PT Taylor wrote:
..snip..
> Section: 7.2.5, Annex A.2, Annex B.2

[CHG] I thought that the "special syntax" for terminationID list was not
meant to be used. It was a hook added to the ASN1 for future
upgradability. Do we need have this possibility in v1? Its not an error
and its a bit of a dubious clarification.

> Section: 7.1, Annex A.2, Annex B.2

[CHG] This is a bit confusing. We don't return lists in descriptors, we
return properties, signal, events events. Does this really need to be
clarified in the main text?

> AuditDescriptor and AuditReturnParameter productions.

[CHG] Why do we need to add an "emptyDescriptor" element? We have the
choice not to send anything. We can also send the TAG for the descriptor
without any contents.

> "; at-most-once for any descriptor or its token, except possibly for

[CHG] I don't see the point of putting "as much as possible" because
this still leaves the MG in an unknown state which defeats the purpose
of this clarification. We know we can't say "all" because it depends on
how the MG actually parses the command. That's internal MG operation
which we don't dictate here.

---

From: John Segers <[email-masked]>
Date: Fri, 28 Apr 2000 17:13:51 +0200

Tom,

I received some more comments off-line, mostly of editorial nature.  But
I suppose it's best to have all comments out on the list to be looked
over by anyone who wants to.

At the end of the message, I have some comment about your document.

ATM properties in Annex C
--------------------------
I received some comments from Olivier LeGrand of France Telecom and Bob
Dianda of Lucent about the properties related to ATM.
1. Table C.4, General ATM properties
- The SC (Service Category) field (for CBR, UBR, etc.) does not exist in
Q.2931 or any DSS2 standard.  The parameter was proposed by MSF, but
apparently we got the reference wrong.  Does anybody know the correct
reference from the top of their heads?
- The Broadband Transfer Capability is defined in Q.2961.2, but Q.2961
is referenced.  I propose that we leave this as is, because some BBTC
codepoints are in Q.2961.3, 4, and others.
- ATC field: the value SBR(3) should be replaced by SBR3(3).
- PCR0 and PCR1 fields: should reference Q.2931 because I.371 does not
specify coding details.
- SCR and MBS fields: one of the contributors suggested referencing
Q.2961.1 for similar reasons.
- SCR2 field: should be called SCR1 as it pertains to sustainable cell
rate for CLP=0+1.
- MBS3 field: should be callsed MBS1 as is pertains to sustainable cell
rate for CLP=0+1.
- Are forward/backward indications needed for the cell rate and burst
size fields?
- Some parameters are missing for ABR and ABT (allowed values in ATC
field): MCR is one.  Any others?
- GFRs needed?
- Tagging indicator (TI): one of the contributors suggested including a
reference to Q.2961.1; also, may need backward and forward indicators.
- Frame Discard (FD): add reference to I.371, need forward/backward
separated?
- BCLR0 and BCLR1 fields: should not have P-P in value column.
- Qos properties (FCCDV to EETD): it's unclear for some whether they
apply to CLP=0 or CLP=0+1.  Brian noted a long time ago in the liaison
from MSF that there were omissions in this area, but it never got
fixed.  I'm not comfortable enough with ATM to make the change.
- FACDV field: replace P-P-P by P-P.
- End-to-end Transit Delay (EETD): need two parameters, acceptable and
cumulative.
- Cell delay variation: ATM forum and ITU use a different CDV (peak to
peak as opposed to 2 point).  It was suggested to add a reference to
Q.2965.2.
- QosClass: the table in the value column is unclear, and the reference
to Q.2931 should be replaced by a reference to Q.2965.1.

2. Table C.7, ATM AAL2
- SCLP field: isn't cell loss priority set at ATM level?
- EETR: broadband bearer capability has been amended and EETR does not
exist any longer.  What is the intended use of the field?  Indicating
that an ATM path providing  end-to-end timing requirements is to be
used?

3. Table C.8, ATM AAL1
- Same question for EETR as under 2.

4. Table C.10, ATM AAL5
- SC: same comment as under 1.  Or are different values intended here?
- EETR: why is there no EETR field for AAL5?

Additional comments to the draft
--------------------------------
Some of this came from Pietro Schicker.
1. Annex A.1, explanation of PropertyParm
The explanation is unclear and can be improved by adding the text
"without extraInfo present" in two places:

-- In PropertyParm , value is a SEQUENCE OF octet string. When sent
[...]
-- one element sequence _without extraInfo present_ specifies value
-- longer sequence _without extraInfo present_ means "choose one of the
values"
[...]

2. Section 7.1.14, DigitMap Descriptor
It was suggested to add subsection headings to add more structure to
this section (it has grown quite a bit over time).  My proposal is to
add the following subsections.

7.1.14.1 DigitMap definition, creation, modification and termination
(before first paragraph)
7.1.14.2 DigitMap Timers
(after the first bullet list)
7.1.14.3 DigitMap syntax
(before the long paragraph starting "The formal syntax of the digit map
[...]")
7.1.14.4 DigitMap completion event
(before the paragraph starting "A digit map is active while the events
descriptor [...]")
7.1.14.5 DigitMap procedures
(before the sentence "Pending completion, successive events shall be
processed [...]", preceding the numbered list)
7.1.14.6 DigitMap activation
(after the numbered list)
7.1.14.7 Interaction of DigitMap and event processing
(before the next paragraph, starting "While the digit map is activated,
[...]")
7.1.14.8 Wildcards
(before the the next paragraph, staring "Note that if a package contains
[...]")
7.1.14.9 Example
(before the example)

3. My notes from Geneva _seem_ to record a decision to add a new
subsection explaining the errorDescriptor.  This new subsection has not
been added.  Does anyone recall the decision (I couldn't find it in the
Geneva meeting report).

4. Section 8.1.1.  Suggest adding text indicating that TransactionId 0
is reserved for responses to erroneous trnasactions with a x-ref to
8.2.2.

5. Error codes in packages.  My notes from Geneva reminded me that we
discussed adding a section about error codes defined in packages, but no
resolution.  Is this desirable?

6. Appendix A
The example profile is called ResGW, while the document refers to
gateways as MGs (minor nit).

Comments on Tom's internet-draft
--------------------------------
1. Section 7.1.4.  There was some discussion about properties of root.
The resolution (as far as I remember) was to add text stating that they
are in TerminationState.  Should this be added to the document?

2. Section 7.2.3.  Needs a similar remark as suggested for 7.2.4, that
CHOOSE cannot be used for TerminationId in Subtract command.

3. ASN.1 and ABNF.  I remember some discussion on the minimum length of
the authdata (e.g. message from Tom, Apr 13, in thread "Interim AH in
Megaco").  Do we need to change the minimum length to 24 hex digits (12
octets)?

Cheers,

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954