doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc2886.txt b/doc/rfc/rfc2886.txt
new file mode 100644
index 0000000..bcaf2e4
--- /dev/null
+++ b/doc/rfc/rfc2886.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                          T. Taylor
+Request for Comments: 2886                               Nortel Networks
+Category: Standards Track                                    August 2000
+
+
+                             Megaco Errata
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+1. Abstract
+
+   This document records the errors found in the Megaco/H.248 protocol
+   document [2], along with the changes proposed in the text of that
+   document to resolve them.
+
+2. Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC-2119 [1].
+
+3. Errata
+
+   All section numbers are those of the relevant text of [2].
+
+   Section: 2 "References"
+   ----------
+   Editorial: Add missing references to I.363.5 (AAL5) and RFC 1661
+   (PPP).
+
+   Editorial: delete unused reference to Q.724.
+
+   Editorial: Leave Recommendations referred to in Annex C undated,
+   implying latest issue.
+
+   Editorial: add reference to RFC 2805, the Megaco requirements
+   document.
+
+
+
+
+Taylor                      Standards Track                     [Page 1]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Section: 4 "Abbreviations"
+   ----------
+   Editorial: delete unused abbreviation BRI.
+
+   Editorial: add explanations for GSM and IVR.
+
+   Section: 6.2.2 "TerminationIDs"
+   ----------
+   Issue: Not clear what wildcard union responses look like.
+
+   Resolution: Add the following text:
+    "ie. Given termination Ta with properties p1=a, p2=b, and
+   termination Tb with properties p2=c, p3=d a UNION
+   response would be T* p1=a, p2=b,c, p3=d."
+
+   Section: 6.2.4 "Termination Properties and descriptors"
+   ----------
+   Issue: Says that property values set in Null context are remembered
+   and reinstated when termination returns to Null.  Contradicts latest
+   text in 7.2.3.
+
+   Resolution: Rewrite the first paragraph from the third sentence
+   onward, to read:  "Most properties have default values, which are
+   explicitly defined in this standard  or in a package (see Section 12)
+   or set by provisioning.  If not provisioned otherwise, all
+   descriptors except for TerminationState and LocalControl default to
+   empty/"no value" when a termination is first created or is returned
+   to the null context.  The default contents of the two exceptions are
+   described in sections 7.1.5 and 7.1.7."
+
+   Issue: DigitMap entry in table makes explicit reference to DTMF
+   tones, but is also intended to apply to other in-band signalling
+   systems.
+
+   Resolution: Change existing text to new one as follows: "Defines
+   patterns against which sequences of a specified set of events are to
+   be matched so they can be reported as a group rather than singly."
+
+   Section: 6.2.5 "Root Termination"
+   ----------
+   Issue: Root can have statistics as well as properties and events.
+
+   Resolution: add "statistics" to the fourth sentence of the first
+   paragraph, listing what is valid for Root.  Add "statistics" to what
+   AuditValue can return for Root.
+
+
+
+
+
+
+Taylor                      Standards Track                     [Page 2]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Section: 7.1 "Descriptors"
+   ----------
+   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,"
+
+   In the ABNF, add the choice auditItem to the production
+   auditReturnParameter.
+
+   Section: 7.1.1 "Specifying Parameters"
+   ----------
+   Issue: Third paragraph (discussing unspecified parameters): not clear
+   which parameters are mandatory.
+
+   Resolution: Replace the first two sentences (each beginning with the
+   word "unspecified") with the following text:  "If a required
+   descriptor other than the Audit descriptor is unspecified (i.e.
+   entirely absent) from a command, the previous values set in that
+   descriptor for that termination, if any, are retained.  A missing
+   Audit descriptor is equivalent to an empty Audit descriptor.  The
+   behaviour of the MG with respect to unspecified parameters within a
+   descriptor varies with the descriptor concerned, as indicated in
+   succeeding sections."
+
+   Section: 7.1.6 "Stream Descriptor", ABNF (Annex B.2)
+   ----------
+   Issue: Text indicates use of "true" and "false" values while ABNF
+   uses "on" and "off"
+
+   Resolution: Add comment in B.2 that "true" in text corresponds to
+   "on" in ABNF, and "false" corresponds to "off".
+
+
+
+
+
+
+
+
+
+
+
+Taylor                      Standards Track                     [Page 3]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Section: 7.1.8 "Local and Remote Descriptors"
+   ----------
+   Issue: case where reserveGroup or reserveValue is true, last bulleted
+   item beginning: "If the Mode property of the LocalControl descriptor
+   is RecvOnly or SendRecv,...", could also have DSP involvement in the
+   case of loopback mode.
+
+   Resolution: Add "loopback".
+
+   Section: 7.1.9 "Events Descriptor"
+   ----------
+   Issue: EventDM is part of syntax but not mentioned in section.
+
+   Resolution: Add text: "If a digit map completion event is present or
+   implied in the EventsDescriptor, EventDM is used to carry either the
+   name or the value of the associated digit map. See section 7.1.14."
+
+   Issue: Not clear whether events trigger side effects (e.g. signal
+   termination) at time of detection, at time of processing (whether or
+   not in active Events Descriptor) or at time of notification.  Also,
+   the third paragraph of the section fails to mention these side
+   effects and limits MG action to notification.
+
+   Resolution: Modify the third paragraph of the section, so that it
+   reads:  "When an event (either newly detected or buffered) is
+   processed against the contents of an active Events descriptor and
+   found to be present in that descriptor ("recognized"), the default
+   action of the MG is to send a Notify command to the MG.  Notification
+   may be deferred if the event is absorbed into the current dial string
+   of an active digit map (see section 7.1.14).  Any other action is for
+   further study.  Moreover, event recognition may cause currently
+   active signals to stop, or may cause the current Events and/or
+   Signals descriptor to be replaced, as described at the end of this
+   section."
+
+   Replace "detection" with "recognition" in the fourth paragraph from
+   the end, so that it reads:  "Normally, recognition of an event shall
+   cause any active signals to stop.  When KeepActive is specified in
+   the event, the MG shall not interrupt any signals active on the
+   Termination on which the event is detected."
+
+   In the third-last paragraph, replace all three instances of
+   "detected" with "recognized".
+
+   Leave the word "detected" as is in the final paragraph.
+
+
+
+
+
+
+Taylor                      Standards Track                     [Page 4]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Issue: Case 1, step 2(a) is incorrectly formulated.  Existing logic
+   may result in an infinite loop.  Also, the step excludes side effect
+   actions such as signal termination.
+
+   Resolution: Modify step 2(a) to read:  "If the event in the queue is
+   in the events listed in the new EventsDescriptor, the MG acts on the
+   event and removes it from the EventBuffer.  The time stamp of the
+   Notify shall be the time the event was actually detected.  The MG
+   then waits for a new EventsDescriptor.  While waiting for a new
+   EventsDescriptor, any events detected which appear in the current
+   EventsBufferDescriptor will be placed in the EventBuffer.  When a new
+   EventDescriptor is received, event processing repeats from step 1."
+
+   Section: 7.1.11 "Signals Descriptor"
+   ----------
+   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: 7.1.13 "ServiceChange Descriptor"
+   ----------
+   Issue: Missing "extension" component in the API.
+
+   Resolution: Add missing component.
+
+
+
+
+
+
+
+Taylor                      Standards Track                     [Page 5]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Section: 7.1.14 "DigitMap Descriptor"
+   ----------
+   Editorial: 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, starting "Note
+   that if a package contains [...]")
+
+   7.1.14.9 Example (before the example)
+
+   Issue: incorrect statements regarding the interaction of the dot
+   symbol with default timing rules.
+
+   Resolution: last sentence of the paragraph beginning "The letter "x"
+   is used as a wildcard, ..." should be modified to read:  "As a
+   consequence of the third timing rule above, inter-event timing while
+   matching a terminal dot symbol uses the short timer by default."  In
+   the next paragraph, the third sentence, which begins:  "A timer
+   specifier following a dot ...", should be deleted.
+
+   Issue: Step 5 in second numbered list  understates conditions for
+   digit map completion when single candidate remains.
+
+   Resolution: Add the words "and it has been fully matched" to the
+   existing sentence.  Also remove the parenthetical remark:  "...
+   (because the candidate set still contains more than one alternative
+   event sequence)" from step 6.
+
+
+
+
+
+Taylor                      Standards Track                     [Page 6]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Issue: Not clear when unmatched events are recognized and trigger
+   side effects (e.g. signal termination).
+
+   Resolution:  Modify the final sentence of the paragraph following
+   procedural step 6 to read as follows:  "Normal event behaviour (e.g.
+   stopping of signals unless the digit completion event has the
+   KeepActive flag enabled) continues to apply for each such event
+   detected, except that
+
+     . the events in the package containing the specified digit map
+       completion event other than the completion event itself are not
+       individually notified, and
+     . an event which triggers a "partial match" completion is not
+       recognized and therefore has no side effects until reprocessed
+       following the recognition of the digit map completion event."
+
+   Issue: the last paragraph before the example is misleading if the
+   package containing the digit map completion event is different from
+   the package containing the actual digits.
+
+   Resolution: qualify the second sentence of the paragraph as follows:
+   "Regardless of whether a digit map is activated, if the package also
+   contains the digit events themselves, this form of event
+   specification ...".
+
+   Section: 7.1.18 "Topology Descriptor"
+   ----------
+   Issue: Third bullet attached to third para: says loopback achieved by
+   manipulating TerminationMode, which no longer has that name.
+
+   Resolution: Delete the clause "; loopbacks are created by setting the
+   TerminationMode"
+
+   Section: 7.2
+   ----------
+   Issue: The order in which descriptors are processed within a command
+   matters, but is not clear.  Moreover, it is fixed in the ASN.1 but
+   variable in the ABNF.
+
+   Resolution: Add text stating that descriptors are processed in the
+   order in which they are provided.  Change ASN.1 in Annex A.2 to allow
+   the MGC to specify ordering:
+
+
+
+
+
+
+
+
+
+Taylor                      Standards Track                     [Page 7]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   AmmRequest ::= SEQUENCE
+   {
+           terminationID           TerminationIDList,
+           descriptors             SEQUENCE OF AmmDescriptor,
+           -- At most one descriptor of each type (see AmmDescriptor)
+           -- allowed in the sequence
+           ...
+   }
+
+   AmmDescriptor ::= CHOICE
+   {
+           mediaDescriptor         MediaDescriptor,
+           modemDescriptor         ModemDescriptor,
+           muxDescriptor           MuxDescriptor,
+           eventsDescriptor        EventsDescriptor,
+           eventBufferDescriptor   EventBufferDescriptor,
+           signalsDescriptor       SignalsDescriptor,
+           digitMapDescriptor      DigitMapDescriptor,
+           auditDescriptor         AuditDescriptor,
+           ...
+   }
+
+   Section: 7.2.3 "Subtract"
+   ----------
+   Issue: cannot use the CHOOSE wildcard for terminationId of a Subtract
+   command.
+
+   Resolution: add this qualification to the second sentence, which
+   indicates that terminationId may be wildcarded.
+
+   Section: 7.2.4 "Move"
+   ----------
+   Issue: cannot use the CHOOSE wildcard for terminationId of a Move
+   command.
+
+   Resolution: add this qualification to the second sentence, which
+   indicates that terminationId may be wildcarded.
+
+   Section: 7.2.5 "AuditValue"
+   ----------
+   Issue: Not clear whether AuditValue of ObservedEventsDescriptor
+   reports events captured in current dial string of active digit map.
+
+   Resolution: Add text to indicate that if a digit map is active and
+   ObservedEventsDescriptor is specified the response to an AuditValue
+   includes a digit map completion event which shows the current dial
+   string but does not show a termination method.
+
+
+
+
+Taylor                      Standards Track                     [Page 8]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Issue: Fails to indicate what AuditValue for EventBufferDescriptor
+   returns
+
+   Resolution: Add the following text: "EventBuffer returns the set of
+   events and associated parameter values currently enabled in the
+   EventBufferDescriptor."
+
+   Issue: not clear whether wildcarded context includes the null
+   context.
+
+   Resolution: add statement that ALL as a contextID does not include
+   the null context.
+
+   Issue: the text of 7.2.5 allows retrieval of multiple digit maps with
+   one AuditValue command if the terminationId is ALL.  Moreover,
+   earlier text in the Annex anticipates that multiple instances of a
+   descriptor may be returned.  The comment in front of production
+   auditReturnParameter in Annex B.2 contradicts this text.  Note that
+   Annex A has no restriction on the number of instances of any
+   descriptor in either a command or a response.
+
+   Proposed Resolution: delete the"at-most-once" comment preceding ABNF
+   production auditReturnParameter.
+
+   Issue: Does not indicate how an audit of digit maps returns unnamed
+   digit maps.
+
+   Resolution: Change syntax of DigitMapDescriptor to allow return of
+   unnamed digit maps as follows:
+
+   digitMapDescriptor = DigitMapToken EQUAL
+                        ( (LBRKT digitMapValue RBRKT)
+                        / (digitMapname [ LBRKT digitMapValue RBRKT ])
+                        ) and
+
+   DigitMapDescriptor ::= SEQUENCE {
+           digitMapName    DigitMapName OPTIONAL,
+           digitMapValue   DigitMapValue OPTIONAL }
+
+   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.
+
+
+
+Taylor                      Standards Track                     [Page 9]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   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.2.6 "AuditCapabilities"
+   ----------
+   Issue: Fails to indicate what AuditCapabilities for
+   EventBufferDescriptor returns
+
+   Resolution: Add the following text: "EventBuffer returns the same
+   information as Events."
+
+   Issue: Inconsistency regarding permissibility of DigitMap or Packages
+   as capability audit items.
+
+   Resolution: Add comment to B.2 "auditItem" production indicating that
+   DigitMap and Packages are not allowed in the AuditCapabilities
+   command.
+
+   Section: 7.2.8 "ServiceChange"
+   ----------
+   Issue: In point 1) describing the Graceful ServiceChange method, the
+   scope of the recommendation against new connections is unclear.
+
+   Resolution: at the end of the first sentence, add the phrase "on the
+   termination(s) affected by the ServiceChange command".
+
+   Issue: the explanatory string associated with ServiceChangeReason is
+   optional in the syntax, but not in the text.
+
+   Resolution: add "optional" before "explanatory string" in the
+   explanation of the ServiceChangeReason" parameter.
+
+   Issue: Paragraph beginning "A ServiceChange Command specifying the
+   Root..." immediately following the description of ServiceChange
+   Descriptor parameters erroneously states that the response to the
+   ServiceChange command terminates the registration process.  This is
+   so only if the response does not specify an alternate MGC.
+
+   Resolution: Add text to the offending sentence, so that it reads:
+   "Acknowledgement of the ServiceChange Command completes the
+   registration process, except when the MGC has returned an alternative
+   ServiceChangeMgcId as described in the next paragraph."
+
+
+
+Taylor                      Standards Track                    [Page 10]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Section: 7.3 "Command Error Codes"
+   ----------
+   Issue: Text for error code 403 should be consistent with that for 404
+   and 405.
+
+   Resolution: Change text to "Syntax error in TransactionRequest"
+
+   Issue: There should be no error responses to TransactionReply or
+   TransactionPending, lest they create response loops.
+
+   Resolution: Delete codes 404, 405, 461-467
+
+   Section: 8 "Transactions", A.2
+   ----------
+   Issue: state is unclear if a command fails.
+
+   Resolution: add the following text:  "If a command fails, the MG
+   shall as far as possible restore the state which prevailed prior to
+   the attempted execution of the command before continuing with
+   transaction processing."
+
+   Section: 8.1.1 "Transaction Identifiers"
+   ----------
+   Issue: need a transaction identifier to use when reporting a syntax
+   error such that the identifier is unavailable.
+
+   Resolution: add text reserving transionId = 0 for this purpose.
+
+   Section: 8.1.2 "Context Identifiers"
+   ----------
+   Issue: ALL as a context identifier does not include the null context.
+
+   Resolution: add text to indicate that exclusion in the final sentence
+   of the section.
+
+   Section: 8.2.2 "TransactionReply"
+   ----------
+   Issue: Final para has wrong text for error code 442.
+
+   Resolution: Change to "Syntax Error in Command"
+
+   Section: 10.2 "Interim AH Scheme", B.2
+   ----------
+   Issue: The interim AH header can actually be as short as 24 hex
+   digits (per RFCs 2403, 2404 which are indirectly referenced).  It is
+   also unclear whether it is the source or destination UDP port which
+   is prepended in the calculation.
+
+
+
+
+Taylor                      Standards Track                    [Page 11]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Resolution: Change 10.2 second para, second-last sentence to specify
+   the destination port, in consistency with IPSEC.  In Annex B.2,
+   change lower count for production AuthData to 24 from 32.
+
+   Section: 11.2 "Cold Start"
+   ----------
+   Issue: First paragraph last sentence inadvertently modified --
+   duplicates material in 11.3.
+
+   Resolution: Restore original sentence: "If the MG is unable to
+   establish a control relationship with any MGC, it shall wait a random
+   amount of time as described in Section 9.2 and then start contacting
+   its primary, and if necessary, its secondary MGCs again."
+
+   Section: 11.4 "Failure Of an MG"
+   ----------
+   Issue: Second para: wrong MG is specified as the one to be used after
+   failover.
+
+   Resolution: Change fourth sentence to refer to "secondary MG" rather
+   than "primary MG".
+
+   Section: 12.1.2 "Properties"
+   ----------
+   Issue: As indicated in 6.2.4, Properties occur in other descriptors
+   besides LocalControl and TerminationState.
+
+   Resolution: after the sentence mentioning TerminationState, add
+   another sentence:  "Although these are the most common cases, it is
+   also possible for a property to be defined for other descriptors."
+
+   Section: 12.1.4 "Signals"
+   ----------
+   Issue: Note says that default duration should be specified for BR
+   signals.  This also applies to TO signals.
+
+   Resolution: Add TO signals to note.
+
+   Section: 12.2 "Guidelines to defining  Properties, Statistics and
+   Parameters to Events and Signals", B.2
+   ----------
+   Issue: Text indicates that statistics can have the sub-list data
+   type, but ABNF does not support that.
+
+   Resolution: qualify the sublist type by adding the note:  "(not
+   supported for statistics)".
+
+
+
+
+
+Taylor                      Standards Track                    [Page 12]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Section: Annex A.1, ASN.1 Syntax
+   ----------
+   Issue: the ASN.1 uses the values 0x0, 0xFFFFFFFE, and 0xFFFFFFFF for
+   the NULL context, a wildcard CHOOSE of context, and a wildcard ALL of
+   context respectively.  Because of the possibility of a switch between
+   binary and text encoding for messages relating to the same context,
+   these values should be reserved in the text encoded syntax.
+
+   Resolution: Add a comment preceding the ContextID production in Annex
+   B.2 indicating that these values are reserved.
+
+   Section: Annex A.2, ASN.1 Syntax
+   ----------
+   Issue: sloppy ASN.1 -- in production EventBufferControl the values
+   "off" and "lockstep" should not be capitalized, and IA5STRING in
+   production NonStandardIdentifier should be IA5String.  Both
+   TransactionID and TransactionId are used.  A number of productions
+   need ellipses to express extensibility.
+
+   Resolution: fix them.
+
+   Issue: syntax for PropertyParm does not support sub-lists (i.e.
+   parameters supporting multiple values simultaneously)
+
+   Resolution: add a third choice to extrainfo in PropertyParm as
+   follows:
+
+            extraInfo   CHOICE
+        {
+                relation        Relation,
+                range           BOOLEAN,
+                sublist         BOOLEAN
+        } OPTIONAL
+
+   and add an appropriate note to the preceding comments.
+
+   Issue: LocalControlDescriptor still contains reserve rather than
+   reserveValue and reserveGroup.
+
+   Resolution: Replace reserve with separate reserveValue and
+   reserveGroup Booleans.
+
+   Issue: EventBufferDescriptor is incorrectly portrayed as a SEQUENCE
+   OF ObservedEvent.
+
+   Resolution: replace with the following productions:
+
+
+
+
+
+Taylor                      Standards Track                    [Page 13]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   EventBufferDescriptor ::= SEQUENCE OF EventSpec
+
+   EventSpec ::= SEQUENCE {
+        pkgdName                PkgdName,
+        streamID                StreamID OPTIONAL,
+        evParList               SEQUENCE OF EventParameter }
+
+   Issue: Assigned object identifier missing.  It is usually present as
+   a matter of convention.
+
+   Resolution: Add object identifier line in the message header with
+   content:
+       "itu-t recommendation h 248 media-gateway-control(0)" Delete the
+   version field, which this makes redundant.
+
+   Issue: the T.35 country code in the H221NonStandard production does
+   not have the right structure.
+
+   Resolution: fix it.
+
+   Section: Annex B.2, ABNF Syntax
+   ----------
+   Issue: Syntax for parmValue and VALUE together make parsing of range
+   ambiguous.  Furthermore, sub-lists and sets of alternative values
+   have the same syntax, introducing possible ambiguity
+
+   Resolution: Replace production alternativeValue by the following:
+     "alternativeValue = ( VALUE
+          / LSBRKT VALUE *(COMMA VALUE) RSBRKT     ; sub-list
+          / LBRKT VALUE *(COMMA VALUE) RBRKT       ; alternatives
+          / LSBRKT VALUE COLON VALUE RSBRKT )      ; range"
+
+   Issue: EventBufferDescriptor content mistakenly shown as a sequence
+   of observedEvent.
+
+   Resolution: replace the production for eventBufferDescriptor with the
+   following productions:
+
+   eventBufferDescriptor = EventBufferToken LBRKT [ eventSpec
+      *( COMMA eventSpec ) ] RBRKT
+
+   eventSpec = pkgdName [ LBRKT  eventSpecParameter
+                          *( COMMA eventSpecParameter ) RBRKT ]
+
+   eventSpecParameter = ( eventStream / eventOther )
+
+   Issue: Error in syntax for  digitMapDescriptor: value meant to be
+   optional.
+
+
+
+Taylor                      Standards Track                    [Page 14]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Resolution: Change production:
+   digitMapDescriptor = DigitMapToken EQUAL digitMapName
+                [ LBRKT digitMapValue RBRKT ]
+
+   Issue: VersionToken not defined.
+
+   Resolution: Add ABNF:       VersionToken =  ("Version" / "V")
+
+   Issue: DiscardToken not used.
+
+   Resolution: Delete production.
+
+   Section: Annex C
+   ----------
+   Issue: alignment of sub-octet fields within the octet is not
+   indicated.
+
+   Resolution: add note that fields of sub-octet length are placed in
+   the low-order bits of the octet.
+
+   Section: Annex C, ATM-related sections C.4, C.7, C.8, C.10
+   ----------
+   Issue: direction of flow is segregated by outgoing (Remote
+   descriptor) and incoming (Local descriptor).  Since forward and
+   backward properties will not both reside in the same descriptor, need
+   only the one set of properties applicable to both directions.
+
+   Resolution: replace with a single set of properties.
+
+   Issue: miscellaneous problems of parameter specifications
+   inconsistent with the relevant standards, unused parameters,
+   distinction between ATM Forum and ITU-T usages, missing references.
+
+   Resolution: fix them.
+
+   Section: Annex C.8 "ATM AAL1"
+   ----------
+   Issue: Length of GIT is wrong.
+
+   Resolution: ITU-T procedural problem, to be resolved by SG 16.
+   Probable solution is to allow 29 octets, event though the relevant
+   form requires only four octets.
+
+   Section: Annex C.9 "Bearer Capabilities"
+   ----------
+   Issue: ITC has reference to missing note 2
+
+   Resolution: Delete reference.
+
+
+
+Taylor                      Standards Track                    [Page 15]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Issue: Not clear that Q.931 Bearer Capability IE rather than Low
+   Layer Compatibility IE is being used.
+
+   Resolution: Specify that values are those valid for Bearer Capability
+   IE
+
+   Section: Annex D.1 "Transport over IP/UDP using Application Level
+   Framing"
+   ----------
+   Issue: Even in the case of handoff or failover, the originating MGC
+   needs confirmation that its command was received.
+
+   Resolution: In the last sentence of the first paragraph, delete the
+   excepting clause, so that the sentence reads: "Responses must be sent
+   to the address and port from which the corresponding commands were
+   sent."
+
+   Section: Annex D.1.1 "Providing At-Most-Once Functionality"
+   ----------
+   Issue: Second para last sentence provides a procedural reference to
+   8.2.3.  Should refer to UDP-specific procedures.
+
+   Resolution: Add reference to D.1.4.
+
+   Section: Annex D.1.3 "Repeating Requests, Responses and
+   Acknowledgements"
+   ----------
+   Issue: Make exponential backoff in the face of congestion mandatory.
+
+   Resolution: To the paragraph just before the note, which begins "The
+   specification purposely avoids specifying any value for the
+   retransmission timers...", add the following sentence:
+
+   "Implementations SHALL ensure that the algorithm used to calculate
+   retransmission timing performs an exponentially increasing backoff of
+   the retransmission timeout for each retransmission or repetition
+   after the first one."
+
+   In the paragraph in the middle of the note beginning "After any
+   retransmission ...", capitalize the word SHOULD to emphasize the
+   importance of the steps which follow.
+
+   Issue: Last paragraph is equivocal about what ServiceChangeReason to
+   use when recovering from loss of contact; it must always be
+   "Disconnected".
+
+
+
+
+
+
+Taylor                      Standards Track                    [Page 16]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Resolution: Change the two sentences following the phrase "_ and it
+   begins its recovery process" to read as follows: "The MG shall use a
+   ServiceChange with ServiceChangeMethod set to disconnected so that
+   the new MGC will be aware that the MG lost one or more transactions."
+
+   Section: Annex D.1.4 "Provisional responses"
+   ----------
+   Issue: First paragraph, last sentence talks about when to send the
+   Transaction Pending response.  When UDP/ALF is in use, the originator
+   of a transaction may repeat it because it has not received an
+   acknowledgement that the transaction was received.  An appropriate
+   response to a duplicate transaction which is still being processed is
+   to return Transaction Pending.
+
+   Resolution: Add the sentence: "They SHOULD send this response if they
+   receive a repetition of a transaction that is still being executed."
+
+   Issue: Second para: transaction originator may not have received
+   TransactionPending response(s) because they were lost, and may
+   therefore not know that responder is expecting immediate
+   acknowledgement of the TransactionReply.
+
+   Resolution: add an optional field to TransactionReply allowing the
+   responder to indicate if an immediate ACK is required.  Add text in
+   the section indicating that when the responder has sent a provisional
+   response, it shall also set the indicator in the final transaction
+   reply to indicate that an immediate acknowledgement is required.
+
+   Section: Annex E "Basic Packages"
+   ----------
+   Issue: package numbering does not follow order of presentation.
+
+   Resolution: renumber packages to follow order of numbering.
+
+   Section: Annex E.2.1 "Base Root Package -- Properties"
+   ----------
+   Issue: the descriptor in which these properties occur is not
+   specified.
+
+   Resolution: in each case, indicate that the property is defined in
+   the TerminationState descriptor.
+
+   Section: Annex E.6.2 "DTMF detection Package -- Events"
+   ----------
+   Issue: "Long duration event modifier" is shown as "L" in parameter
+   DigitString -- should be "Z".
+
+   Resolution: Replace with "Z".
+
+
+
+Taylor                      Standards Track                    [Page 17]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Section: Annex E.9.2 "Analog Line Supervision Package -- Events"
+   ----------
+   Issue: Stated hook state reporting behaviour has race condition where
+   same transition could be reported twice.
+
+   Resolution: add an optional EventsDescriptor parameter and an
+   optional ObservedEvents parameter to each of the on-hook and off-hook
+   events.  Delete the second sentence of the existing event description
+   (which indicates that the event is always reported if the hook state
+   has already been achieved).
+
+   The EventsDescriptor parameter is described as follows:
+
+   Strict Transition
+         ParameterID: strict (0x0001)
+         Type: enumeration
+         Possible values:
+             "exact" means that only an actual hook state transition
+             to on-hook (off-hook) is to be recognized
+
+             "state" means that the event is to be recognized
+             either if the hook state transition is detected or if the
+             hook state is already on-hook (off-hook).  This is the
+             default value if "strict" is unspecified.
+
+             "failWrong" means that if the hook state is already what
+             the transition would imply, the command fails and an error
+             is reported [error code to be defined in the package].
+
+   The ObservedEvents parameter is described as follows:
+
+   Initial State
+         ParameterID: init (0x0002)
+         Type: Boolean
+         Possible values:
+             true/"ON" means that the event was reported because the
+             line was already on-hook (off-hook) when the events
+             descriptor containing this event was activated
+
+             false/"OFF" means that the event represents an actual
+             state transition to on-hook (off-hook)
+
+   Section: Annex E.10.3 "Basic Continuity Package -- Signals"
+   ----------
+   Issue: The rsp signal should continue until the MGC tells the MG to
+   stop applying it.
+
+   Resolution: change the type of signal from Timeout to ON/OFF.
+
+
+
+Taylor                      Standards Track                    [Page 18]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+   Section: Annex E.10.5 "Basic Continuity Package -- Procedures"
+   ----------
+   Issue: Wording of condition for generating cmp event with "success"
+   does not cover case where test also requires successful removal of
+   tone.
+
+   Resolution: In the second paragraph of E.10.5 (dealing with test
+   initiation), add the words "and any other required conditions are
+   satisfied" in the second sentence, as part of the condition upon
+   which success is reported.  Replace the third paragraph (dealing with
+   test response) with the following text:
+
+   "When a MGC wants the MG to respond to a continuity test, it sends a
+   command to the MG containing a signals descriptor with the rsp
+   signal. Upon reception of a command with the rsp signal, the MG
+   either applies a loop-back or (for 2-wire circuits) awaits reception
+   of a continuity test tone.  In the loop-back case, any incoming
+   information shall be reflected back as outgoing information.  In the
+   2-wire case, any time the appropriate test tone is received, the
+   appropriate response tone should be sent.  The MGC will determine
+   when to remove the rsp signal."
+
+   Section: Appendix A.1.2 "Example -- Collecting Originator Digits and
+   Initiating Termination"
+   ----------
+   Issue: Step 3 uses a now-obsolete package DS0 for echo cancellation.
+
+   Resolution: replace with echo cancellation via package TDM.
+
+   Issue: Step 20 fails to show a returned TerminationStateDescriptor.
+   It also contains the erroneous statement that an RTP termination does
+   not support events and signals and fails to show a number of other
+   descriptors.
+
+   Resolution:
+   Delete the sentence containing the erroneous statement.
+   Add the following to the Media Descriptor preceding the line "Stream
+   = 1_":
+   "TerminationState { ServiceStates = InService, EventBufferControl =
+   OFF },"
+
+   Add lines showing Events, Signals, and DigitMap descriptors
+   following the Media descriptor.
+
+   "Events, Signals, DigitMap,"
+
+
+
+
+
+
+Taylor                      Standards Track                    [Page 19]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+4. Security Considerations
+
+   This memo is a supplement to [2], which contains the required
+   security section.
+
+5. References
+
+   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+       9, RFC 2026, October 1996.
+
+   [2] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B. and J.
+       Segeret, "Megaco Protocol", RFC 2885, August 2000.
+
+   [3] Bradner, S., "Key Words For Use In RFCs To Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+6. Acknowledgments
+
+   This memo records the contributions of a number of people on the
+   Megaco list and the H.248 faithful in ITU-T Study Group 16 who took
+   the time to read the Megaco/H.248 document with care and attention.
+   Thanks to all of them.
+
+7. Author's Address
+
+   Tom Taylor
+   Nortel Networks
+   P.O. Box 3511, Station C
+   Ottawa, Ontario, Canada K1Y 4P7
+
+   Phone: +1 613 736 0961
+   EMail: taylor@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                      Standards Track                    [Page 20]
+
+RFC 2886                     Megaco Errata                   August 2000
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                      Standards Track                    [Page 21]
+