Subject: Updates Submitted To ITU Based On Issue Scorecard

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 7 Feb 2000 09:58:23 -0500

What follows below is the document I submitted to Study Group 16 based on
our past two weeks' discussion.  Please note in particular the
clarifications to 7.1.14, digit maps.  I found that the introduction of
long-duration tones required very careful spelling out of the processing of
events against the digit map alternatives.

All of these comments are against the v14 document.

ITU - Telecommunication Standardization Sector  Temporary Document XX (WP
2/16)
STUDY GROUP 16

Geneva, 7-18 February 2000

Question(s):      Q.14/16

SOURCE*:        Rapporteur

TITLE:  Additional Changes to draft recommendation H.248

___________________
Introduction
This document lists additional changes made to draft recommendation H.248
after submitting the white document to ITU and the changes listed in
Temporary Document 32 (WP2/16).  These changes are meant to be applied on
top of the TD 32/2 changes.
These detailed changes result from discussions with interested parties from
SG 16 and from IETF megaco working group over the last few weeks.

Proposed Changes
===========
The section numbers in this contribution refer to section numbers in the
revised draft recommendation (TD-XXX) as submitted to this meeting.

Section 7.1.6
===========
Action: replace the last sentence of the first paragraph of this section
with new text:
(start of changed text)
A stream is deleted by setting empty Local and Remote descriptors for the
stream with Reserve in LocalControl set to "false" on all terminations in
the context which previously supported that stream.
(end of changed text)
Motivation: deletion of a protocol mechanism which clarifications in TD 32/2
have rendered unnecessary.

Section 7.1.7
===========
Actions
* remove "delete" as an allowed value for the Mode parameter in the first
sentence of the second paragraph of the section
* delete the final sentence of that paragraph
(begin deleted text)
Mode set to delete is used to remove a stream from a termination.
(end of deleted text)
Motivation: deletion of a protocol mechanism which clarifications in TD 32/2
have rendered unnecessary.

Section 7.1.11
===========
Actions
* replace  the last two sentences of the second paragraph:
(begin replacement text)
Finally, the optional parameter "notifyCompletion" allows the MGC to
indicate that it wishes to be notified when this signal finishes playout.
When the MGC enables the Signal Completion event (see section E.1.2) in an
Event Descriptor, that event is detected whenever a signal terminates and
"notifyCompletion" for that signal is set to TRUE.
(end replacement text)

* delete the final paragraph of the section.
(begin deleted text)
If the MGC requested notification of completion for a signal, a Notify
command SHALL be sent by the MG upon completion of that signal.  A Notify
triggered by completion of a signal SHALL NOT affect the state of the
eventbuffer or any active events descriptor.
(end deleted text)

Motivation: replace a special purpose mechanism for notification of signal
completion with the ordinary event mechanism.

Section 7.1.13
===========
Actions
* change Profile to ServiceChangeProfile
* change Version to ServiceChangeVersion
* change MGCIdToTry to ServiceChangeMgcId
Motivation: editorial.

Section 7.1.14
===========
Actions
* replace item 3. in the numbered list in the third paragraph with the
following text
(begin replacement text)
3. If the digit string has matched one of the patterns in the digit map, but
it is possible that more digits could be received which would cause a match
with a different pattern, then instead of reporting the match immediately,
the MG must apply the short timer (S) and wait for more digits.
(end replacement text)

* fifth paragraph, third  and fourth sentences, replace with the following
text:
(begin replacement text)
Each string in the list is an alternative event sequence, specified either
as a sequence of digit map symbols or as a regular expression of digit map
symbols.  These digit map symbols, the digits "0" through "9" and letters
"A" through a maximum value depending on the signalling system concerned,
but never exceeding "K", correspond to specified events within a package
which has been designated in the Events Descriptor on the termination to
which the digit map is being applied.
(end replacement text)

* add a new sentence at the end of the fifth paragraph.
(begin new text)
Finally, the dot symbol "." stands for zero or more repetitions of the event
selector (event, range of events, set of alternative events, or wildcard)
which precedes it.  As a consequence of the third timing rule above,
inter-event timing while matching the dot symbol uses the short timer.
(end new text)

* sixth paragraph, first sentence, delete "S" and the word "and" which
follows it.

* seventh paragraph, currently beginning "A MG that detects ...", replace
paragraph including numbered list with the following text:
(begin replacement text)
A digit map is active while the event descriptor which invoked it is active
and it has not completed.  A digit map completes when:
   * a timer has expired, or
   * an alternative event sequence has been matched and no other alternative
event sequence in the digit map could be matched through detection of an
additional event (unambiguous match), or
   * an event has been detected such that a match to a complete alternative
event sequence of the digit map will be impossible no matter what additional
events are received.
Upon completion, a digit map completion event as defined in the package
providing the events being mapped into the digit map shall be generated.
Pending completion, successive events shall be processed according to the
following rules:
0. The "current dial string", an internal variable, is initially empty.  The
set of candidate alternative event sequences includes all of the
alternatives specified in the digit map.
1. At each step, a timer is set to wait for the next event.  The rules for
determining how long to wait are listed above.  If the timer expires and a
member of the candidate set of alternatives is fully satisfied, a timeout
completion with full match is reported.  If the timer expires and part or
none of any candidate alternative is satisfied, a timeout completion with
partial match is reported.
2. If an event is detected before the timer expires, it is mapped to a digit
string symbol and added to the end of the current dial string.  The duration
of the event (long or not long) is noted if and only if this is relevant in
the current symbol position (because at least one of the candidate
alternative event sequences includes the "L" modifier at this position in
the sequence).
3. The current dial string is compared to the candidate alternative event
sequences, and any of these which do not match are discarded from the
candidate set.  If a sequence expecting a long-duration event at this
position is matched (i.e. the event had long duration and met the
specification for this position), then any alternative event sequences not
specifying a long duration event at this position are discarded, and the
current dial string is modified by inserting an "L" in front of the symbol
representing the latest event.  If no sequence expecting a long-duration
event at this position is matched, any such sequences are discarded from the
candidate set, but the observed event duration is treated as irrelevant in
assessing matches to the remaining candidates.
4. If exactly one candidate remains, a completion event is generated
indicating an unambiguous match.  If no candidates remain, but one of the
candidates from the previous step was fully satisfied before the latest
event was detected, a completion event is generated indicating a full match
and an extra event.  If no candidates remain and no candidate from the
previous step was fully satisfied before the latest event was detected, a
completion event is generated indicating a partial match and an extra event.
If multiple candidates remain, steps 1 through 4 are repeated.

* final paragraph of section, third sentence, and following digit map:
replace with the following
(begin replacement text)
 If the DTMF detection package described in Annex E (section E.6) is used to
collect the dialled digits, then the dialling plan shown above results in
the following digit map:
(0 | 00 | [1-7]xxx | 8xxxxxxx | Fxxxxxxx | Exx | 91xxxxxxxxxx | 9011x. )
(end replacement text)

Motivation: clarify and remove obsolete information from the description of
operation of digit maps.

Section 7.1.17
===========
Actions
* Add the following text after the second sentence (relating to AuditValue):
(begin new text)
In addition, if a digit map is active, the ObservedEventsDescriptor shall
contain a digit map completion event as defined in the package whose events
are being mapped.  This event shall show the contents of the current dial
string at the time the audit request was processed.
(end new text)

* delete the fourth sentence:
(begin deleted text)
If a Notify is sent as a result of a signal completion, the
ObservedEventsDescriptor contains the name of the signal that completed and
the time at which it completed.
(end deleted text)

Section 7.2.5
===========
Action: in the second last paragraph, replace the word "unspecified" with
the word "wildcarded".
Motivation: completion of earlier modifications presented in TD-32
clarifying the operation of audits.

Section 7.2.7
===========
Actions
* Second paragraph after API (third from end), last sentence: delete all
after "... on the termination concerned".
(begin deleted text)
, or as the result of completion of a signal for which the MGC requested
notification of completion
(end deleted text)

* next paragraph, second sentence: replace all after "... triggering
EventsDescriptor ...":
(begin replacement text)
or embedded EventsDescriptor.
(end replacement text)

* delete the final paragraph of the section:
(begin deleted text)
A Notify triggered by completion of a signal, contains the corresponding
signal name in the ObservedEventsDescriptor.
(end deleted text)
Motivation replace a special purpose mechanism for notification of signal
completion with the ordinary event mechanism.

Section 7.2.8
===========
Actions
* API should show TerminationID as a required result.  Other items need
updating to match terminology in the rest of the section.
(begin replacement text)
TerminationID
[ServiceChangeReplyDescriptor]
                ServiceChange(TerminationID,
                        ServiceChangeDescriptor
                )
(end replacement text)

* throughout the section, replace the following ServiceChangeDescriptor
fields: "Profile" becomes "ServiceChangeProfile", "Version" (note initial
capital letter) becomes "ServiceChangeVersion", and "MGCIdToTry" becomes
"ServiceChangeMgcId".

* numbered list in the paragraph beginning "The ServiceChangeMethod
parameter specifies ...", add the following text to the fifth list item
(Handoff method):
(begin new text)
Sent from the MG to the MGC, this indicates that the MG is attempting to
establish a new association in accordance with a Handoff received from the
MGC with which it was previously associated.
(end new text)

* in the next list item (Failover), delete all after "... secondary MG is
taking over"
(begin deleted text)
, and sent from MG to (new) MGC in response to the MG having received a
ServiceChange with ServiceChangeMethod equal to Handoff
(end deleted text)

*  numbered list in the paragraph beginning "The ServiceChangeMethod
parameter specifies ...", add a seventh list item as follows:
(begin new text)
7) Another value whose meaning is mutually understood between the MG and the
MGC.
(end new text)

* second paragraph following this list, beginning "The optional
ServiceChangeAddress parameter ...", add the following sentences at the end
of the paragraph:
(begin new text)
ServiceChangeAddress and ServiceChangeMgcId parameters must not both be
present in the ServiceChangeDescriptor or the ServiceChangeResultDescriptor.
The ServiceChangeAddress provides an address to be used within the context
of the association currently being negotiated, while the ServiceChangeMgcId
provides an alternate address where the MG should seek to establish another
association.
(end new text)

* Following the paragraph beginning "The optional Timestamp parameter
specifies ..." add a new paragraph.
(begin new text)
The optional Extension parameter may contain any value whose meaning is
mutually understood by the MG and MGC.
(end new text)

* In the next paragraph, beginning "A ServiceChange Command specifying the
"Root" ...", replace the fourth to seventh sentences (starting from "The MG
may specify the transport ServiceChangeAddress ...") with the following
text:
(begin replacement text)
The MG may specify an address in the ServiceChangeAddress parameter of the
ServiceChange request, and the MGC may also do so in the ServiceChange
reply.  In either case, the recipient must use the supplied address as the
destination for all subsequent transaction requests within the association.
At the same time, as indicated in section 9, transaction replies and pending
indications must be sent to the address from which the corresponding
requests originated.  This must be done even if  it implies extra messaging
because commands and responses cannot be packed together.
(end replacement text)

* Delete the paragraph and bulleted list beginning "Summarizing use of
properties in the ServiceChangeDescriptor ...", as it has proved to be
misleading.
(begin deleted text)
Summarizing use of properties in the ServiceChange Descriptor:
  * ServiceChangeMethod mandatory in all cases.
  * ServiceChangeReason mandatory in all cases.
  * ServiceChangeDelay mandatory if ServiceChangeMethod is "Graceful" or
"Restart", otherwise not allowed.
  * ServiceChangeAddress mandatory when the terminationID is ROOT, otherwise
not allowed.
  * Profile required if terminationID is ROOT, optional otherwise.
  * Version as specified in section 11.3.
  * MGCIdToTry optional if the message comes from MGC and terminationID is
ROOT, not allowed otherwise.
  * TimeStamp mandatory when terminationID is ROOT, optional otherwise.
(end deleted text)

* Replace the paragraph following the deleted text, as follows:
(begin replacement text)
The return from ServiceChange is empty except when the Root terminationID is
used.  In that case it includes the following parameters as required:
   * ServiceChangeAddress, if the responding MGC wishes to specify an new
destination for messages from the MG for the remainder of the association;
   * ServiceChangeMgcId, if the responding MGC does not wish to sustain an
association with the MG;
   * ServiceChangeProfile, if the responder wishes to negotiate the profile
to be used for the association;
   * ServiceChangeVersion, if the responder wishes to negotiate the version
of the protocol to be used for the association.
(end of replacement text)
Motivation: clarify the operation of the ServiceChange command and render
the text more consistent.

Section 8
===========
Action: delete first sentence of fourth paragraph after the figure.
(begin deleted text)
A TransactionReply includes the return values for all of the Commands in the
corresponding TransactionRequest.
(end deleted text)
Motivation: made redundant by second sentence of paragraph.

Section 8.3
===========
 Action: remove any reference to RFC 2145 in the second paragraph.
(begin replaced text, modified from TD 32/2)
Versions consist of one or two digits, beginning with version 1 for the
present version of the protocol.
(end of replaced text)
Motivation: remove inapplicable reference and provide a starting version
number.

Section 9
===========
Action: all of the second paragraph following the first sentence as follows:
(begin replacement text)
If TCP or UDP is used as the protocol transport and the port to which the
initial ServiceChange request is to be sent is not otherwise known, that
request should be sent to the default port number for the protocol.  This
port number is xxxx for text-encoded operation or yyyy for binary-encoded
operation, for either UDP or TCP.  The MGC receives the message containing
the ServiceChange request from the MG and can determine the MG's address
from it.  As described in section 7.2.8, either the MG or the MGC may supply
an address in the ServiceChangeAddress parameter to which subsequent
transaction requests must be addressed, but responses (including the
response to the initial ServiceChange request) must always be sent back to
the address which was the source of the corresponding request.
(end replacement text)
Motivation: Update the intent with regard to default ports.  (Actual IANA
port number assignments should be known shortly.)  Clarify the use of
ServiceChangeAddress and emphasize the rules for routing of responses.

Section 11.1
===========
Action: delete the final sentence from the final paragraph.
(begin deleted text)
ServiceChange may only be applied to the Root by the Master MGC.
(end deleted text)
Motivation: remove an unnecessary restriction, allowing handoff of Virtual
MGs.

Section 11.2
===========
Action: replace "MGCIdToTry" with "ServiceChangeMgcId" wherever it occurs.
Motivation: editorial.

Section 11.3
===========
Action: first paragraph, final sentence should be modified as follows:
(begin replacement text)
If the MG is unable to comply and it has established a transport connection
to the MGC, it should close that connection.  In any event, it should reject
all subsequent requests from the MGC with Error 406 Version Not Supported.
(end replacement text)
Motivation: specify more precisely the MG role in this case.

Section 11.5
===========
Actions
* replace "MGCIdToTry" with "ServiceChangeMgcId" wherever it occurs.
* second paragraph, third sentence: replace "Failover" by "Handoff".
Motivation: editorial, consistency.

Section 12.1.1
===========
Action for description of PackageID on third line, remove all after
"identifier"
(begin deleted text)
, its text encoding may not be a keyword in the base protocol
(end deleted text)

Annex A, Section A.2
===========
Actions
* in production AuditRequest, element auditDescriptor, remove the OPTIONAL
attribute
* in production StreamMode, remove value delete (5)
* modify the comment to production PkgdName to say that wildcarding of
Package Name (first two octets) is permitted only if Property Name is also
wildcarded
* in production Signal, element notifyCompletion, change type from RequestID
to BOOLEAN
Motivation: consistency with changes in the body of the document.

Annex A, section A.3
===========
Actions
* in production digitLetter, replace term "ditigMapLetter" by term
"digitMapLetter".
* replace production digitMapLetter:
(begin replacement text)
digitMapLetter = DIGIT  /  %x41-4B / %x61-6B /      ; Mapped events 0-9, A-K
(a-k)
                                "L"
; Long duration modifier
(end replacement text)

* delete production MFSig
Motivation: consistency with section 7.1.14

Annex B, section B.2
===========
Actions
* in production auditRequest, make the term LBRKT auditDescriptor RBRKT
non-optional by removing the square brackets around it
* change production ErrorCode from 1*3(DIGIT) to 1*4(DIGIT)
* in production streamModes, remove alternative DeleteToken
* replace production pkgdName as follows:
(begin replacement text)
pkgdName = (PackageName SLASH ItemID) /    ; specific item
                     (PackageName SLASH "*" )      /     ; all events in
package
                     ( "*" SLASH "*")                              ; all
events supported by the MG
(end replacement text)
* replace production notifyCompletion as follows:
(begin replacement text)
notifyCompletion     = NotifyCompletionToken EQUAL ("ON" / "OFF" )
(end replacement text)
* replace production digitMapLetter as follows:
(begin replacement text)
digitMapLetter = DIGIT  /  %x41-4B / %x61-6B /      ; Mapped events 0-9, A-K
(a-k)
                                "L"
; Long duration modifier
(end replacement text)
* delete production MFSig
* in the production quotedString, remove the upper limit 64
* in the production VALUE, remove the upper limit 64
* remove production DeleteToken
Motivation: consistency with the body of the document; removal of arbitrary
limits on size of fields.

Annex D, section D.1
===========
Action:  modify the second sentence:
(begin replacement text)
When no port is provided by the peer (see section 7.2.8), commands should be
sent to the default port number, xxxx for text-encoded operation or yyyy for
binary-encoded operation.  Responses must always be sent to the address and
port from which the corresponding commands were sent.
(end replacement text)
Motivation: update to show separation by encoding method and clarify routing
of responses.

Annex D, section D.1.1
===========
Actions
* Second paragraph, end of second sentence: replace the phrase "from the
same entity" with the phrase "sent to the same MId".
Motivation correct and clarify the description of which transaction
identifier are to be matched.

Annex E, section E.1.2
===========
Action add description of a general signal completion event.
(begin new text)
Signal Completion
EventID:                sc (0x0002)
Indicates termination of one or more signals for which the notifyCompletion
parameter was set to "ON".  For further procedural description, see sections
7.1.11, 7.1.17, and 7.2.7.

Descriptor parameters:
Signal Identity
  ParameterID:  SigID (0x0001)
  This parameter identifies the signals which have terminated.
  Possible values: a list of signals and/or sequential signal lists which
have terminated.  A signal outside of a sequential signal list shall be
identified using the pkgdName syntax without wildcarding.  An individual
signal inside of a sequential signal list shall be identified using the
sequential signal list syntax with the correct signal list identifier,
enclosing the name of the specific signal which terminated in pkgdName
syntax.

Termination Method
  ParameterID:  Meth (0x0002)
  Type: enumeration
  Possible values:
  "TO" (0x0001) Duration expired
  "EV" (0x0002) Interrupted by event
  "SD" (0x0003) Halted by new Signals Descriptor
  "FL" (0x0004) Failure
  Description: Indicates the means by which the signal terminated.

(end new text)
Motivation: complete the description of the signal completion reporting
mechanism.

Annex E, section E.5.3
===========
Action: in the table of signal names and signal/tone IDs, replace d*
(0x0020) by ds (0x0020), and d# (0x0021) by do (0x0021).
Motivation: d* and d# are not legal ItemIDs in the syntax of Annex B.

Annex E, section E.6
===========
Action: delete the third paragraph of the description.
(begin deleted text)
Implementers of this package shall support d0-d9,d* and d#.  Support of
dA-dD is optional.
(end of deleted text)
Motivation: support of a package is on an "all or none" basis.

Annex E, section E.6.2
===========
Actions
* Replace the existing digit map completion event documentation with the
following:
(begin replacement text)
DigitMap Completion Event
EventID: ce, 0x0001
Raised when a digit map completes as described in section 7.1.14, or when an
AuditValue requesting events is applied to a termination, as described in
section 7.1.17.
EventsDescriptor parameters: none.  This event is armed through activation
of a DigitMap Descriptor in accompaniment with an events descriptor
specifying the set of DTMF digit events to be mapped into the digit map.

ObservedEventsDescriptor parameters:
DigitString
ParameterID: ds (0x0001)
Type: string of digit map symbols (possibly empty)
Possible values: any sequence of the characters "0" through "9", "A" through
"F", and the long duration modifier "L".
Description: the portion of the current dial string as described in section
7.1.14 which matched part or all of an alternative event sequence specified
in the digit map.

Extra
ParameterID: ex (0x0002)
Type: digit map symbol
Possible values: any one of the characters "0" through "9" or "A" through
"F"
Description: the final digit map symbol added to the current dial string in
the case where as a result it was determined that no match of the digit map
was possible.  This parameter is present only when that outcome has
occurred.

Termination Method
ParameterID:    Meth (0x0003)
Type: enumeration
Possible values:
"MA" (0x0001) Unambiguous match
"PM"  (0x0002) Partial match, timer expired or unmatched event
"FM"  (0x0003) Full match, timer expired or unmatched event
"AU"  (0x0004) Audit, collection in progress
Description: indicates the reason for generation of the event.  See the
procedures in section 7.1.14.  The Extra parameter may be present only if
the "PM" or "FM" termination method is reported.  Its absence in those cases
indicates that termination was by timer expiry.  The "AU" reason shall be
used only for a response to an AuditValue of the termination while digit
collection is in progress.
(end of replacement text)

* Add the following new text describing the mapping between DTMF tone events
and digit map symbols:
(begin new text)
The following table maps DTMF events to digit map symbols as described in
section 7.1.14.
DTMF Event  Symbol
d0                     "0"
d1                     "1"
d2                     "2"
d3                     "3"
d4                     "4"
d5                     "5"
d6                     "6"
d7                     "7"
d8                     "8"
d9                     "9"
da                     "A" or "a"
db                     "B" or "b"
dc                     "C" or "c"
dd                     "D" or "d"
ds                     "E" or "e"
do                     "F" or "f"

(end new text)
Motivation: complete implementation for DTMF of digit map procedures
described in section 7.1.14.

Annex E, section E.9.2
===========
Actions
* Add the following text to the description of the on-hook event.
(begin new text)
If the first event descriptor after (re)establishment of MGC control over
the specific termination concerned or the MG as a whole contains the on-hook
event request and the line is already on-hook, the MG shall raise an on-ook
event as if on-hook had occurred immediately after the event descriptor
became active.
(end new text)

* Add the following to the description of the off-hook event.
(begin new text)
If the first event descriptor after (re)establishment of MGC control over
the specific termination concerned or the MG as a whole contains the
off-hook event request and the line is already off-hook, the MG shall raise
an off-hook event as if off-hook had occurred immediately after the event
descriptor became active.
(end new text)
Motivation: ensure synchronization of hook state between the MG and MGC
following a control outage.

Annex E, section E.10.3
===========
Actions
* add "(extendible)" after "q724" on the "Possible Values" line for each
signal
* add the following descriptive text to the Test type parameter for each
signal
(begin new text)
Description: this parameter, if present, gives guidance to the MG on which
type of continuity test to perform for the indicated Termination.  It is
necessary only where multiple choices are valid for that termination.  In
general, the MG will have to make use of information provisioned for the
given termination in order to know the exact flavour of continuity test to
run.
(end new text)
Motivation: make clear the responsibility of the MG to determine the exact
type of continuity test to run.

Annex E, section E.10.5
===========
Action replace the paragraph with the following text:
(begin replacement text)
When a MGC initiates or responds to a MG by sending the Initiate or Response
signal to the MG, the MG shall perform the continuity test in accordance
with the specified test type and additional information provisioned in the
MG for the affected termination.
(end replacement text)
Motivation: make clear the responsibility of the MG to determine the exact
type of continuity test to run.

Annex E, section E.11.1
===========
Action: add the following definition of the Silence Suppression property.
(begin new text)
Silence Suppression
PropertyID: ssup (0x1008)
This property indicates whether silence suppression is to be activated in
the encoding of the audio media flow to which it relates.
Type: Boolean
Possible values: True if silence suppression is to be applied.
Defined in: LocalControl
Characteristics: read/write
(end of new text)
Motivation: restore material inadvertently omitted.

Annex E, section E.13.1
===========
Action replace the definition of the echo cancellation property with the
following text.
(begin replacement text)
Echo Cancellation
PropertyID: ec (0x0008)
By default, the telephony gateways always perform echo cancellation
according to                 G.165/G.168. However, it is necessary, for some
calls, to turn off these operations.
Type: enumerated
Possible Values:
  "on" (echo cancellation is permanently enabled and will disregard any
incoming tones)
  "g165" (echo cancellation is according to G.165/G.168: echo cancellation
is on to start with, but will turn itself off when it sees a 2100Hz tone
with phase reversal (i.e. a CED fax tone, or an ANS modem tone)
  "g164" (echo cancellation is according to G.164)
  "off" (echo cancellation is turned off.)
The default is "g165".
        Defined In: LocalControlDescriptor
        Characteristics: read/write
(end replacement text)
Motivation: allow specification of the echo cancellation algorithm, giving
responsibility for detailed application to the MG.

Appendix A, section A.1.2
===========
Actions
* in step 9, remove "L"and "S" characters from the digit map.  Use "E"
instead of "*" and "F" instead of "#"
* in step 11, the parameters to the dd/ce event should be
"{ds="916135551212",Meth=FM}"
* in step 15, add the line "Events = 1234{al/of}" preceding the Signals line
* in step 16.  Insert the line "Add = A5555{}" above the line "Add = A5556{"
Motivation: correct errors and make examples consistent with body of
protocol document.

Tom Taylor
Advisor -- Emerging Carrier IP Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 7 Feb 2000 14:53:17 -0500

A small nits:

In 7.1.17, should "SHALL" be "SHOULD"?  There might not be
a reason to do so, but why be so restrictive?  Also, the
second sentence added does not belong here, it belongs in the
package definition, if at all.

In 7.2.5, should "wildcarded" be "ALL"?

In 7.2.8, in additional wording about ServiceChangeAddress and
ServiceChangeMgcIdToTry, the word "must" should be "shall".

12.1.1 there was an unfinished discussion re "keywords in the
protocol for package names.  Did you just dismiss that discussion?

E.1.2 There is presently no "list" type for Signal Identity, there
is enumeration and sublist, or it could be a string.  Please also
note that "Descriptor Parameters" should be "ObservedEvents
Descriptor Parameters" here, and in the cause event above

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Monday, February 07, 2000 9:58 AM
> To: [email-masked]
> Subject: Updates Submitted To ITU Based On Issue Scorecard
>
>
>                      ( "*" SLASH "*")
>      ; all