idnits 2.17.1 draft-ietf-megaco-errata-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 137 has weird spacing: '...tandard or in...' == Line 340 has weird spacing: '...ed list under...' == Line 743 has weird spacing: '...tax for digit...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2000) is 8719 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 1005, but no explicit reference was found in the text ** Downref: Normative reference to an Historic draft: draft-ietf-megaco-protocol (ref. '2') Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Media Gateway Control P.T. Taylor 2 Internet Draft Nortel Networks 3 Document: draft-ietf-megaco-errata-03.txt May 2000 4 Category: Standards Track 6 Megaco Errata 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 1. Abstract 28 This document records the errors found in the draft Megaco/H.248 29 protocol document [2], along with the changes proposed in the text 30 of that document to resolve them. After joint IETF/ITU-T Study Group 31 16 approval of these corrections, they will be incorporated into the 32 final decided version of H.248 and the corresponding Megaco protocol 33 RFC. The current status of approval is as follows: 34 . IETF process is complete, and the IESG has granted its approval; 35 . ITU-T process is complete except that the Members' comment period 36 does not expire until June 8, 2000 and the final act of Decision 37 is scheduled for June 15, 2000. 39 This draft has been modified from the previous issue by 40 strengthening the sentence in section D.1.3 which requires 41 exponential backoff in the face of congestion. The detailed list of 42 changes from draft-ietf-megaco-errata-01.txt has been left intact 43 for the user's convenience. 45 2. Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in RFC-2119 [1]. 51 Taylor Standards Track -- Expires Nov 2000 1 52 3. Errata 54 All section numbers are those of the relevant text of [2]. 56 3.1 Changes From draft-ietf-megaco-errata-01.txt 58 Section 7.1: proposed change in the comment preceding production 59 auditReturnItem in Annex B.2 (ABNF) has been deleted, because a 60 later section actually proposes deletion of the comment. 62 Section 7.2.5: issue has been expanded to note that the text of 63 section 7.2.5 anticipates the possibility of return of multiple 64 instances of the same descriptor. Proposed remedy is to delete the 65 restrictive comment in front of production auditReturnItem in Annex 66 B.2 (ABNF), rather than just modify it to add exceptions. 68 Section 7.2.5: to get the current dial string of an active digit 69 map, the ObservedEvents descriptor must be audited rather than the 70 Events descriptor. 72 Section A.2: along with the addition of the protocol identifier 73 field in the message header, the now-redundant version field is 74 removed. The need to add extensibility to more productions through 75 use of ellipses is noted. 77 Section A.2, B.2: the ASN.1 uses three values from contextId 78 numbering space to denote NULL, CHOOSE, and ALL. A comment is added 79 to the ABNF to reserve the values concerned. 81 Section A.2: format of H221NonStandard field does not properly 82 reflect structure of T.35 country code. 84 Annex C: changes to ATM-related sections are noted. Alignment of 85 sub-octet fields is stated to be at the low-order end of the octet. 87 Section D.1.3: exponential backoff in the face of congestion made 88 mandatory by replacing SHOULD with SHALL. 90 Annex E: package serial numbers are revised to make them 91 consecutive. 93 Appendix A step 3: revised to use echo control as defined in the TDM 94 package. 96 3.2 Complete List Of Corrections 98 Taylor Standards Track -- Expires Nov 2000 2 99 Section: 2 "References" 100 ---------- 102 Editorial: Add missing references to I.363.5 (AAL5) and RFC 1661 103 (PPP). 105 Editorial: delete unused reference to Q.724. 107 Editorial: Leave Recommendations referred to in Annex C undated, 108 implying latest issue. 110 Editorial: add reference to RFC 2805, the Megaco requirements 111 document. 113 Section: 4 "Abbreviations" 114 ---------- 115 Editorial: delete unused abbreviation BRI. 117 Editorial: add explanations for GSM and IVR. 119 Section: 6.2.2 "TerminationIDs" 120 ---------- 121 Issue: Not clear what wildcard union responses look like. 123 Resolution: Add the following text: 124 "ie. Given termination Ta with properties p1=a, p2=b, and 125 termination Tb with properties p2=c, p3=d a UNION 126 response would be T* p1=a, p2=b,c, p3=d." 128 Section: 6.2.4 "Termination Properties and descriptors" 129 ---------- 130 Issue: Says that property values set in Null context are remembered 131 and reinstated when termination returns to Null. Contradicts latest 132 text in 7.2.3. 134 Resolution: Rewrite the first paragraph from the third sentence 135 onward, to read: 136 "Most properties have default values, which are explicitly defined 137 in this standard or in a package (see Section 12) or set by 138 provisioning. If not provisioned otherwise, all descriptors except 139 for TerminationState and LocalControl default to empty/"no value" 140 when a termination is first created or is returned to the null 141 context. The default contents of the two exceptions are described 142 in sections 7.1.5 and 7.1.7." 144 Issue: DigitMap entry in table makes explicit reference to DTMF 145 tones, but is also intended to apply to other in-band signalling 146 systems. 148 Taylor Standards Track -- Expires Nov 2000 3 149 Resolution: Change existing text to new one as follows: "Defines 150 patterns against which sequences of a specified set of events are to 151 be matched so they can be reported as a group rather than singly." 153 Section: 6.2.5 "Root Termination" 154 ---------- 155 Issue: Root can have statistics as well as properties and events. 157 Resolution: add "statistics" to the fourth sentence of the first 158 paragraph, listing what is valid for Root. Add "statistics" to what 159 AuditValue can return for Root. 161 Section: 7.1 "Descriptors" 162 ---------- 163 Issue: it is unclear how to express empty descriptors in responses 164 to the MGC. 166 Proposed resolution: In section 7.1, add the following text after 167 the sentence: "Descriptors may be returned as output from a 168 command.": 169 "In any such return of descriptor contents, an empty descriptor is 170 represented by its name unaccompanied by any list." 172 In the ASN.1, add the following choice to the AuditReturnParameter 173 production: 175 "emptyDescriptors AuditDescriptor," 177 In the ABNF, add the choice auditItem to the production 178 auditReturnParameter. 180 Section: 7.1.1 "Specifying Parameters" 181 ---------- 182 Issue: Third paragraph (discussing unspecified parameters): not 183 clear which parameters are mandatory. 185 Resolution: Replace the first two sentences (each beginning with the 186 word "unspecified") with the following text: 187 "If a required descriptor other than the Audit descriptor is 188 unspecified (i.e. entirely absent) from a command, the previous 189 values set in that descriptor for that termination, if any, are 190 retained. A missing Audit descriptor is equivalent to an empty 191 Audit descriptor. The behaviour of the MG with respect to 192 unspecified parameters within a descriptor varies with the 193 descriptor concerned, as indicated in succeeding sections." 195 Section: 7.1.6 "Stream Descriptor", ABNF (Annex B.2) 196 ---------- 197 Issue: Text indicates use of "true" and "false" values while ABNF 198 uses "on" and "off" 200 Taylor Standards Track -- Expires Nov 2000 4 201 Resolution: Add comment in B.2 that "true" in text corresponds to 202 "on" in ABNF, and "false" corresponds to "off". 204 Section: 7.1.8 "Local and Remote Descriptors" 205 ---------- 206 Issue: case where reserveGroup or reserveValue is true, last 207 bulleted item beginning: "If the Mode property of the LocalControl 208 descriptor is RecvOnly or SendRecv,...", could also have DSP 209 involvement in the case of loopback mode. 211 Resolution: Add "loopback". 213 Section: 7.1.9 "Events Descriptor" 214 ---------- 215 Issue: EventDM is part of syntax but not mentioned in section. 217 Resolution: Add text: "If a digit map completion event is present or 218 implied in the EventsDescriptor, EventDM is used to carry either the 219 name or the value of the associated digit map. See section 7.1.14." 221 Issue: Not clear whether events trigger side effects (e.g. signal 222 termination) at time of detection, at time of processing (whether or 223 not in active Events Descriptor) or at time of notification. Also, 224 the third paragraph of the section fails to mention these side 225 effects and limits MG action to notification. 227 Resolution: Modify the third paragraph of the section, so that it 228 reads: 229 "When an event (either newly detected or buffered) is processed 230 against the contents of an active Events descriptor and found to be 231 present in that descriptor ("recognized"), the default action of the 232 MG is to send a Notify command to the MG. Notification may be 233 deferred if the event is absorbed into the current dial string of an 234 active digit map (see section 7.1.14). Any other action is for 235 further study. Moreover, event recognition may cause currently 236 active signals to stop, or may cause the current Events and/or 237 Signals descriptor to be replaced, as described at the end of this 238 section." 240 Replace "detection" with "recognition" in the fourth paragraph from 241 the end, so that it reads: 242 "Normally, recognition of an event shall cause any active signals to 243 stop. When KeepActive is specified in the event, the MG shall not 244 interrupt any signals active on the Termination on which the event 245 is detected." 247 In the third-last paragraph, replace all three instances of 248 "detected" with "recognized". 250 Leave the word "detected" as is in the final paragraph. 252 Taylor Standards Track -- Expires Nov 2000 5 253 Issue: Case 1, step 2(a) is incorrectly formulated. Existing logic 254 may result in an infinite loop. Also, the step excludes side effect 255 actions such as signal termination. 257 Resolution: Modify step 2(a) to read: 258 "If the event in the queue is in the events listed in the new 259 EventsDescriptor, the MG acts on the event and removes it from the 260 EventBuffer. The time stamp of the Notify shall be the time the 261 event was actually detected. The MG then waits for a new 262 EventsDescriptor. While waiting for a new EventsDescriptor, any 263 events detected which appear in the current EventsBufferDescriptor 264 will be placed in the EventBuffer. When a new EventDescriptor is 265 received, event processing repeats from step 1." 267 Section: 7.1.11 "Signals Descriptor" 268 ---------- 269 Issue: There is a need for the MGC to be aware of signalling 270 failures. It is not possible to use the signal completion event to 271 monitor for signalling failures only, without also having to process 272 successes. 274 Proposed Resolution: In section 7.1.11, replace the current text on 275 completion notification, beginning: "Finally, the optional parameter 276 "notifyCompletion" ..." and continuing to the end of the paragraph 277 with the following text: 279 "Finally, the optional parameter "notifyCompletion" allows a MGC to 280 indicate the circumstances under which it wishes to be notified when 281 the signal finishes playout. The possible cases are that the signal 282 timed out, that it was interrupted by an event, that it was halted 283 when a Signals descriptor was replaced, or that it stopped or never 284 started for other reasons. If "notifyCompletion" is absent, 285 notification is generated in the "other reasons" case only. For 286 reporting to occur the signal completion event (see section E.1.2) 287 must be enabled in the currently active Events descriptor." 289 In Annex A.2, make notifyCompletion a BIT STRING with the four 290 cases. In B.2, make it a parameter consisting of a name and a list 291 of values representing the possible completion methods. 293 Section: 7.1.13 "ServiceChange Descriptor" 294 ---------- 295 Issue: Missing "extension" component in the API. 297 Resolution: Add missing component. 299 Section: 7.1.14 "DigitMap Descriptor" 300 ---------- 302 Editorial: add the following subsections. 304 7.1.14.1 DigitMap definition, creation, modification and termination 306 Taylor Standards Track -- Expires Nov 2000 6 307 (before first paragraph) 308 7.1.14.2 DigitMap Timers 309 (after the first bullet list) 310 7.1.14.3 DigitMap syntax 311 (before the long paragraph starting "The formal syntax of the digit 312 map [...]") 313 7.1.14.4 DigitMap completion event 314 (before the paragraph starting "A digit map is active while the 315 events descriptor [...]") 316 7.1.14.5 DigitMap procedures 317 (before the sentence "Pending completion, successive events shall be 318 processed [...]", preceding the numbered list) 319 7.1.14.6 DigitMap activation 320 (after the numbered list) 321 7.1.14.7 Interaction of DigitMap and event processing 322 (before the next paragraph, starting "While the digit map is 323 activated, [...]") 324 7.1.14.8 Wildcards 325 (before the the next paragraph, starting "Note that if a package 326 contains [...]") 327 7.1.14.9 Example 328 (before the example) 330 Issue: incorrect statements regarding the interaction of the dot 331 symbol with default timing rules. 333 Resolution: last sentence of the paragraph beginning "The letter "x" 334 is used as a wildcard, ..." should be modified to read: 335 "As a consequence of the third timing rule above, inter-event timing 336 while matching a terminal dot symbol uses the short timer by 337 default." In the next paragraph, the third sentence, which begins: 338 " A timer specifier following a dot ...", should be deleted. 340 Issue: Step 5 in second numbered list understates conditions for 341 digit map completion when single candidate remains. 343 Resolution: Add the words "and it has been fully matched" to the 344 existing sentence. Also remove the parenthetical remark: 345 "... (because the candidate set still contains more than one 346 alternative event sequence)" 347 from step 6. 349 Issue: Not clear when unmatched events are recognized and trigger 350 side effects (e.g. signal termination). 352 Resolution: Modify the final sentence of the paragraph following 353 procedural step 6 to read as follows: 354 "Normal event behaviour (e.g. stopping of signals unless the digit 355 completion event has the KeepActive flag enabled) continues to apply 356 for each such event detected, except that 358 Taylor Standards Track -- Expires Nov 2000 7 359 . the events in the package containing the specified digit map 360 completion event other than the completion event itself are not 361 individually notified, and 362 . an event which triggers a "partial match" completion is not 363 recognized and therefore has no side effects until reprocessed 364 following the recognition of the digit map completion event." 366 Issue: the last paragraph before the example is misleading if the 367 package containing the digit map completion event is different from 368 the package containing the actual digits. 370 Resolution: qualify the second sentence of the paragraph as follows: 371 "Regardless of whether a digit map is activated, if the package also 372 contains the digit events themselves, this form of event 373 specification ...". 375 Section: 7.1.18 "Topology Descriptor" 376 ---------- 377 Issue: Third bullet attached to third para: says loopback achieved 378 by manipulating TerminationMode, which no longer has that name. 380 Resolution: Delete the clause "; loopbacks are created by setting 381 the TerminationMode" 383 Section: 7.2 384 ---------- 385 Issue: The order in which descriptors are processed within a command 386 matters, but is not clear. Moreover, it is fixed in the ASN.1 but 387 variable in the ABNF. 389 Resolution: Add text stating that descriptors are processed in the 390 order in which they are provided. Change ASN.1 in Annex A.2 to 391 allow the MGC to specify ordering: 393 AmmRequest ::= SEQUENCE 394 { 395 terminationID TerminationIDList, 396 descriptors SEQUENCE OF AmmDescriptor, 397 -- At most one descriptor of each type (see AmmDescriptor) 398 -- allowed in the sequence 399 ... 400 } 402 AmmDescriptor ::= CHOICE 403 { 404 mediaDescriptor MediaDescriptor, 405 modemDescriptor ModemDescriptor, 406 muxDescriptor MuxDescriptor, 407 eventsDescriptor EventsDescriptor, 408 eventBufferDescriptor EventBufferDescriptor, 409 signalsDescriptor SignalsDescriptor, 410 digitMapDescriptor DigitMapDescriptor, 412 Taylor Standards Track -- Expires Nov 2000 8 413 auditDescriptor AuditDescriptor, 414 ... 415 } 417 Section: 7.2.3 "Subtract" 418 ---------- 419 Issue: cannot use the CHOOSE wildcard for terminationId of a 420 Subtract command. 422 Resolution: add this qualification to the second sentence, which 423 indicates that terminationId may be wildcarded. 425 Section: 7.2.4 "Move" 426 ---------- 427 Issue: cannot use the CHOOSE wildcard for terminationId of a Move 428 command. 430 Resolution: add this qualification to the second sentence, which 431 indicates that terminationId may be wildcarded. 433 Section: 7.2.5 "AuditValue" 434 ---------- 435 Issue: Not clear whether AuditValue of ObservedEventsDescriptor 436 reports events captured in current dial string of active digit map. 438 Resolution: Add text to indicate that if a digit map is active and 439 ObservedEventsDescriptor is specified the response to an AuditValue 440 includes a digit map completion event which shows the current dial 441 string but does not show a termination method. 443 Issue: Fails to indicate what AuditValue for EventBufferDescriptor 444 returns 446 Resolution: Add the following text: "EventBuffer returns the set of 447 events and associated parameter values currently enabled in the 448 EventBufferDescriptor." 450 Issue: not clear whether wildcarded context includes the null 451 context. 453 Resolution: add statement that ALL as a contextID does not include 454 the null context. 456 Issue: the text of 7.2.5 allows retrieval of multiple digit maps 457 with one AuditValue command if the terminationId is ALL. Moreover, 458 earlier text in the Annex anticipates that multiple instances of a 459 descriptor may be returned. The comment in front of production 460 auditReturnParameter in Annex B.2 contradicts this text. Note that 461 Annex A has no restriction on the number of instances of any 462 descriptor in either a command or a response. 464 Taylor Standards Track -- Expires Nov 2000 9 465 Proposed Resolution: delete the"at-most-once" comment preceding ABNF 466 production auditReturnParameter. 468 Issue: Does not indicate how an audit of digit maps returns unnamed 469 digit maps. 471 Resolution: Change syntax of DigitMapDescriptor to allow return of 472 unnamed digit maps as follows: 474 digitMapDescriptor = DigitMapToken EQUAL 475 ( (LBRKT digitMapValue RBRKT) 476 / (digitMapname [ LBRKT digitMapValue RBRKT ]) 477 ) 478 and 480 DigitMapDescriptor ::= SEQUENCE 481 { 482 digitMapName DigitMapName OPTIONAL, 483 digitMapValue DigitMapValue OPTIONAL 484 } 486 Issue: the text in section 7.2.5 mentions that using an empty Audit 487 descriptor with a wildcarded terminationId is a way to get a list of 488 the terminations in the context. Annex A provides the possibility 489 that the auditReply may be a contextAuditResult of type 490 terminationIdList, and Annex B allows for an auditReply containing a 491 contextTerminationAudit which in turn presents a terminationIdList. 492 The connection between the text in 7.2.5 and these special forms of 493 audit result is not clear. Moreover, a note at the beginning of 494 Annex A section A.2 limits terminationIdList to one terminationId. 496 Proposed Resolution: add the following text in section 7.2.5 after 497 the sentence "This may be useful to get a list of TerminationIDs 498 when used with wildcard.": 499 "Annexes A and B provide a special syntax for presenting such a list 500 in condensed form, such that the AuditValue command tag does not 501 have to be repeated for each terminationId." 502 Also, in the Note at the beginning of section A.2 of Annex A, 503 provide an exception on the length of type TerminationIdList when 504 used in contextAuditResult. 506 Section: 7.2.6 "AuditCapabilities" 507 ---------- 508 Issue: Fails to indicate what AuditCapabilities for 509 EventBufferDescriptor returns 511 Resolution: Add the following text: "EventBuffer returns the same 512 information as Events." 514 Issue: Inconsistency regarding permissibility of DigitMap or 515 Packages as capability audit items. 517 Taylor Standards Track -- Expires Nov 2000 10 518 Resolution: Add comment to B.2 "auditItem" production indicating 519 that DigitMap and Packages are not allowed in the AuditCapabilities 520 command. 522 Section: 7.2.8 "ServiceChange" 523 ---------- 524 Issue: In point 1) describing the Graceful ServiceChange method, the 525 scope of the recommendation against new connections is unclear. 527 Resolution: at the end of the first sentence, add the phrase "on the 528 termination(s) affected by the ServiceChange command". 530 Issue: the explanatory string associated with ServiceChangeReason is 531 optional in the syntax, but not in the text. 533 Resolution: add "optional" before "explanatory string" in the 534 explanation of the ServiceChangeReason" parameter. 536 Issue: Paragraph beginning "A ServiceChange Command specifying the 537 Root..." immediately following the description of ServiceChange 538 Descriptor parameters erroneously states that the response to the 539 ServiceChange command terminates the registration process. This is 540 so only if the response does not specify an alternate MGC. 542 Resolution: Add text to the offending sentence, so that it reads: 543 "Acknowledgement of the ServiceChange Command completes the 544 registration process, except when the MGC has returned an 545 alternative ServiceChangeMgcId as described in the next paragraph." 547 Section: 7.3 "Command Error Codes" 548 ---------- 549 Issue: Text for error code 403 should be consistent with that for 550 404 and 405. 552 Resolution: Change text to "Syntax error in TransactionRequest" 554 Issue: There should be no error responses to TransactionReply or 555 TransactionPending, lest they create response loops. 557 Resolution: Delete codes 404, 405, 461-467 559 Section: 8 "Transactions", A.2 560 ---------- 561 Issue: state is unclear if a command fails. 563 Resolution: add the following text: 564 "If a command fails, the MG shall as far as possible restore the 565 state which prevailed prior to the attempted execution of the 566 command before continuing with transaction processing." 568 Section: 8.1.1 "Transaction Identifiers" 570 Taylor Standards Track -- Expires Nov 2000 11 571 ---------- 572 Issue: need a transaction identifier to use when reporting a syntax 573 error such that the identifier is unavailable. 575 Resolution: add text reserving transionId = 0 for this purpose. 577 Section: 8.1.2 "Context Identifiers" 578 ---------- 579 Issue: ALL as a context identifier does not include the null 580 context. 582 Resolution: add text to indicate that exclusion in the final 583 sentence of the section. 585 Section: 8.2.2 "TransactionReply" 586 ---------- 587 Issue: Final para has wrong text for error code 442. 589 Resolution: Change to "Syntax Error in Command" 591 Section: 10.2 "Interim AH Scheme", B.2 592 ---------- 593 Issue: The interim AH header can actually be as short as 24 hex 594 digits (per RFCs 2403, 2404 which are indirectly referenced). It is 595 also unclear whether it is the source or destination UDP port which 596 is prepended in the calculation. 598 Resolution: Change 10.2 second para, second-last sentence to specify 599 the destination port, in consistency with IPSEC. In Annex B.2, 600 change lower count for production AuthData to 24 from 32. 602 Section: 11.2 "Cold Start" 603 ---------- 604 Issue: First paragraph last sentence inadvertently modified -- 605 duplicates material in 11.3. 607 Resolution: Restore original sentence: "If the MG is unable to 608 establish a control relationship with any MGC, it shall wait a 609 random amount of time as described in Section 9.2 and then start 610 contacting its primary, and if necessary, its secondary MGCs again." 612 Section: 11.4 "Failure Of an MG" 613 ---------- 614 Issue: Second para: wrong MG is specified as the one to be used 615 after failover. 617 Resolution: Change fourth sentence to refer to "secondary MG" rather 618 than "primary MG". 620 Section: 12.1.2 "Properties" 622 Taylor Standards Track -- Expires Nov 2000 12 623 ---------- 624 Issue: As indicated in 6.2.4, Properties occur in other descriptors 625 besides LocalControl and TerminationState. 627 Resolution: after the sentence mentioning TerminationState, add 628 another sentence: 629 "Although these are the most common cases, it is also possible for a 630 property to be defined for other descriptors." 632 Section: 12.1.4 "Signals" 633 ---------- 634 Issue: Note says that default duration should be specified for BR 635 signals. This also applies to TO signals. 637 Resolution: Add TO signals to note. 639 Section: 12.2 "Guidelines to defining Properties, Statistics and 640 Parameters to Events and Signals", B.2 641 ---------- 642 Issue: Text indicates that statistics can have the sub-list data 643 type, but ABNF does not support that. 645 Resolution: qualify the sublist type by adding the note: 646 "(not supported for statistics)". 648 Section: Annex A.1, ASN.1 Syntax 649 ---------- 650 Issue: the ASN.1 uses the values 0x0, 0xFFFFFFFE, and 0xFFFFFFFF for 651 the NULL context, a wildcard CHOOSE of context, and a wildcard ALL 652 of context respectively. Because of the possibility of a switch 653 between binary and text encoding for messages relating to the same 654 context, these values should be reserved in the text encoded syntax. 656 Resolution: Add a comment preceding the ContextID production in 657 Annex B.2 indicating that these values are reserved. 659 Section: Annex A.2, ASN.1 Syntax 660 ---------- 661 Issue: sloppy ASN.1 -- in production EventBufferControl the values 662 "off" and "lockstep" should not be capitalized, and IA5STRING in 663 production NonStandardIdentifier should be IA5String. Both 664 TransactionID and TransactionId are used. A number of productions 665 need ellipses to express extensibility. 667 Resolution: fix them. 669 Taylor Standards Track -- Expires Nov 2000 13 670 Issue: syntax for PropertyParm does not support sub-lists (i.e. 671 parameters supporting multiple values simultaneously) 673 Resolution: add a third choice to extrainfo in PropertyParm as 674 follows: 675 extraInfo CHOICE 676 { 677 relation Relation, 678 range BOOLEAN, 679 sublist BOOLEAN 680 } OPTIONAL 681 and add an appropriate note to the preceding comments. 683 Issue: LocalControlDescriptor still contains reserve rather than 684 reserveValue and reserveGroup. 686 Resolution: Replace reserve with separate reserveValue and 687 reserveGroup Booleans. 689 Issue: EventBufferDescriptor is incorrectly portrayed as a SEQUENCE 690 OF ObservedEvent. 692 Resolution: replace with the following productions: 694 EventBufferDescriptor ::= SEQUENCE OF EventSpec 696 EventSpec ::= SEQUENCE 697 { 698 pkgdName PkgdName, 699 streamID StreamID OPTIONAL, 700 evParList SEQUENCE OF EventParameter 701 } 703 Issue: Assigned object identifier missing. It is usually present as 704 a matter of convention. 706 Resolution: Add object identifier line in the message header with 707 content: 708 "itu-t recommendation h 248 media-gateway-control(0)" 709 Delete the version field, which this makes redundant. 711 Issue: the T.35 country code in the H221NonStandard production does 712 not have the right structure. 714 Resolution: fix it. 716 Taylor Standards Track -- Expires Nov 2000 14 717 Section: Annex B.2, ABNF Syntax 718 ---------- 719 Issue: Syntax for parmValue and VALUE together make parsing of range 720 ambiguous. Furthermore, sub-lists and sets of alternative values 721 have the same syntax, introducing possible ambiguity 723 Resolution: Replace production alternativeValue by the following: 724 "alternativeValue = ( VALUE 725 / LSBRKT VALUE *(COMMA VALUE) RSBRKT ; sub-list 726 / LBRKT VALUE *(COMMA VALUE) RBRKT ; alternatives 727 / LSBRKT VALUE COLON VALUE RSBRKT ) ; range" 729 Issue: EventBufferDescriptor content mistakenly shown as a sequence 730 of observedEvent. 732 Resolution: replace the production for eventBufferDescriptor with 733 the following productions: 735 eventBufferDescriptor = EventBufferToken LBRKT [ eventSpec 736 *( COMMA eventSpec ) ] RBRKT 738 eventSpec = pkgdName [ LBRKT eventSpecParameter 739 *( COMMA eventSpecParameter ) RBRKT ] 741 eventSpecParameter = ( eventStream / eventOther ) 743 Issue: Error in syntax for digitMapDescriptor: value meant to be 744 optional. 746 Resolution: Change production: 747 digitMapDescriptor = DigitMapToken EQUAL digitMapName 748 [ LBRKT digitMapValue RBRKT ] 750 Issue: VersionToken not defined. 752 Resolution: Add ABNF: VersionToken = ("Version" / "V") 754 Issue: DiscardToken not used. 756 Resolution: Delete production. 758 Section: Annex C 759 ---------- 760 Issue: alignment of sub-octet fields within the octet is not 761 indicated. 763 Resolution: add note that fields of sub-octet length are placed in 764 the low-order bits of the octet. 766 Taylor Standards Track -- Expires Nov 2000 15 767 Section: Annex C, ATM-related sections C.4, C.7, C.8, C.10 768 ---------- 769 Issue: direction of flow is segregated by outgoing (Remote 770 descriptor) and incoming (Local descriptor). Since forward and 771 backward properties will not both reside in the same descriptor, 772 need only the one set of prperties applicable to both directions. 774 Resolution: replace with a single set of properties. 776 Issue: miscellaneous problems of parameter specifications 777 inconsistent with the relevant standards, unused parameters, 778 distinction between ATM Forum and ITU-T usages, missing references. 780 Resolution: fix them. 782 Section: Annex C.8 "ATM AAL1" 783 ---------- 784 Issue: Length of GIT is wrong. 786 Resolution: ITU-T procedural problem, to be resolved by SG 16. 787 Probable solution is to allow 29 octets, event though the relevant 788 form requires only four octets. 790 Section: Annex C.9 "Bearer Capabilities" 791 ---------- 792 Issue: ITC has reference to missing note 2 794 Resolution: Delete reference. 796 Issue: Not clear that Q.931 Bearer Capability IE rather than Low 797 Layer Compatibility IE is being used. 799 Resolution: Specify that values are those valid for Bearer 800 Capability IE 802 Section: Annex D.1 "Transport over IP/UDP using Application Level 803 Framing" 804 ---------- 805 Issue: Even in the case of handoff or failover, the originating MGC 806 needs confirmation that its command was received. 808 Resolution: In the last sentence of the first paragraph, delete the 809 excepting clause, so that the sentence reads: "Responses must be 810 sent to the address and port from which the corresponding commands 811 were sent." 813 Section: Annex D.1.1 "Providing At-Most-Once Functionality" 814 ---------- 815 Issue: Second para last sentence provides a procedural reference to 816 8.2.3. Should refer to UDP-specific procedures. 818 Resolution: Add reference to D.1.4. 820 Taylor Standards Track -- Expires Nov 2000 16 821 Section: Annex D.1.3 "Repeating Requests, Responses and 822 Acknowledgements" 823 ---------- 824 Issue: Make exponential backoff in the face of congestion mandatory. 826 Resolution: To the paragraph just before the note, which begins "The 827 specification purposely avoids specifying any value for the 828 retransmission timers...", add the following sentence: 830 "Implementations SHALL ensure that the algorithm used to calculate 831 retransmission timing performs an exponentially increasing backoff 832 of the retransmission timeout for each retransmission or repetition 833 after the first one." 835 In the paragraph in the middle of the note beginning "After any 836 retransmission ...", capitalize the word SHOULD to emphasize the 837 importance of the steps which follow. 839 Issue: Last paragraph is equivocal about what ServiceChangeReason to 840 use when recovering from loss of contact; it must always be 841 "Disconnected". 843 Resolution: Change the two sentences following the phrase "_ and it 844 begins its recovery process" to read as follows: "The MG shall use a 845 ServiceChange with ServiceChangeMethod set to disconnected so that 846 the new MGC will be aware that the MG lost one or more 847 transactions." 849 Section: Annex D.1.4 "Provisional responses" 850 ---------- 851 Issue: First paragraph, last sentence talks about when to send the 852 Transaction Pending response. When UDP/ALF is in use, the 853 originator of a transaction may repeat it because it has not 854 received an acknowledgement that the transaction was received. An 855 appropriate response to a duplicate transaction which is still being 856 processed is to return Transaction Pending. 858 Resolution: Add the sentence: "They SHOULD send this response if 859 they receive a repetition of a transaction that is still being 860 executed." 862 Issue: Second para: transaction originator may not have received 863 TransactionPending response(s) because they were lost, and may 864 therefore not know that responder is expecting immediate 865 acknowledgement of the TransactionReply. 867 Resolution: add an optional field to TransactionReply allowing the 868 responder to indicate if an immediate ACK is required. Add text in 869 the section indicating that when the responder has sent a 870 provisional response, it shall also set the indicator in the final 872 Taylor Standards Track -- Expires Nov 2000 17 873 transaction reply to indicate that an immediate acknowledgement is 874 required. 876 Section: Annex E "Basic Packages" 877 ---------- 878 Issue: package numbering does not follow order of presentation. 880 Resolution: renumber packages to follow order of numbering. 882 Section: Annex E.2.1 "Base Root Package -- Properties" 883 ---------- 884 Issue: the descriptor in which these properties occur is not 885 specified. 887 Resolution: in each case, indicate that the property is defined in 888 the TerminationState descriptor. 890 Section: Annex E.6.2 "DTMF detection Package -- Events" 891 ---------- 892 Issue: "Long duration event modifier" is shown as "L" in parameter 893 DigitString -- should be "Z". 895 Resolution: Replace with "Z". 897 Section: Annex E.9.2 "Analog Line Supervision Package -- Events" 898 ---------- 899 Issue: Stated hook state reporting behaviour has race condition 900 where same transition could be reported twice. 902 Resolution: add an optional EventsDescriptor parameter and an 903 optional ObservedEvents parameter to each of the on-hook and off- 904 hook events. Delete the second sentence of the existing event 905 description (which indicates that the event is always reported if 906 the hook state has already been achieved). 908 The EventsDescriptor parameter is described as follows: 910 Strict Transition 911 ParameterID: strict (0x0001) 912 Type: enumeration 913 Possible values: 914 "exact" means that only an actual hook state transition 915 to on-hook (off-hook) is to be recognized 917 "state" means that the event is to be recognized 918 either if the hook state transition is detected or if the 919 hook state is already on-hook (off-hook). This is the 920 default value if "strict" is unspecified. 922 "failWrong" means that if the hook state is already what 923 the transition would imply, the command fails and an error 924 is reported [error code to be defined in the package]. 926 Taylor Standards Track -- Expires Nov 2000 18 927 The ObservedEvents parameter is described as follows: 929 Initial State 930 ParameterID: init (0x0002) 931 Type: Boolean 932 Possible values: 933 true/"ON" means that the event was reported because the 934 line was already on-hook (off-hook) when the events 935 descriptor containing this event was activated 937 false/"OFF" means that the event represents an actual 938 state transition to on-hook (off-hook) 940 Section: Annex E.10.3 "Basic Continuity Package -- Signals" 941 ---------- 942 Issue: The rsp signal should continue until the MGC tells the MG to 943 stop applying it. 945 Resolution: change the type of signal from Timeout to ON/OFF. 947 Section: Annex E.10.5 "Basic Continuity Package -- Procedures" 948 ---------- 949 Issue: Wording of condition for generating cmp event with "success" 950 does not cover case where test also requires successful removal of 951 tone. 953 Resolution: In the second paragraph of E.10.5 (dealing with test 954 initiation), add the words "and any other required conditions are 955 satisfied" in the second sentence, as part of the condition upon 956 which success is reported. Replace the third paragraph (dealing 957 with test response) with the following text: 959 "When a MGC wants the MG to respond to a continuity test, it sends a 960 command to the MG containing a signals descriptor with the rsp 961 signal. Upon reception of a command with the rsp signal, the MG 962 either applies a loop-back or (for 2-wire circuits) awaits reception 963 of a continuity test tone. In the loop-back case, any incoming 964 information shall be reflected back as outgoing information. In the 965 2-wire case, any time the appropriate test tone is received, the 966 appropriate response tone should be sent. The MGC will determine 967 when to remove the rsp signal." 969 Taylor Standards Track -- Expires Nov 2000 19 970 Section: Appendix A.1.2 "Example -- Collecting Originator Digits and 971 Initiating Termination" 972 ---------- 973 Issue: Step 3 uses a now-obsolete package DS0 for echo cancellation. 975 Resolution: replace with echo cancellation via package TDM. 977 Issue: Step 20 fails to show a returned TerminationStateDescriptor. 978 It also contains the erroneous statement that an RTP termination 979 does not support events and signals and fails to show a number of 980 other descriptors. 982 Resolution: 983 Delete the sentence containing the erroneous statement. 984 Add the following to the Media Descriptor preceding the line "Stream 985 = 1_": 986 "TerminationState { ServiceStates = InService, EventBufferControl = 987 OFF }," 989 Add lines showing Events, Signals, and DigitMap descriptors 990 following the Media descriptor. 992 "Events, Signals, DigitMap," 994 6. Security Considerations 996 This draft is a supplement to [2], which contains the required 997 security section. 999 7. References 1001 [1] Scott Bradner, The Internet Standards Process -- Revision 3, 1002 IETF RFC 2026, October 1996. 1003 [2] Rosen et al, draft-ietf-megaco-protocol-08.txt, Megaco Protocol, 1004 work in progress, May 2000. 1005 [3] Scott Bradner, Key Words For Use In RFCs To Indicate Requirement 1006 Levels, IETF RFC 2119, March, 1997. 1008 8. Acknowledgments 1010 This draft records the contributions of a number of people on the 1011 Megaco list and the H.248 faithful in ITU-T Study Group 16 who took 1012 the time to read the Megaco/H.248 draft with care and attention. 1013 Thanks to all of them. 1015 Taylor Standards Track -- Expires Nov 2000 20 1016 9. Author's Addresses 1018 Tom Taylor 1019 Nortel Networks 1020 P.O. Box 3511, Station C 1021 Ottawa, Ontario, Canada K1Y 4P7 1022 Phone: +1 613 736 0961 1023 Email: taylor@nortelnetworks.com 1025 Full Copyright Statement 1027 "Copyright (C) The Internet Society (date). All Rights Reserved. 1028 This document and translations of it may be copied and furnished to 1029 others, and derivative works that comment on or otherwise explain it 1030 or assist in its implmentation may be prepared, copied, published 1031 and distributed, in whole or in part, without restriction of any 1032 kind, provided that the above copyright notice and this paragraph 1033 are included on all such copies and derivative works. However, this 1034 document itself may not be modified in any way, such as by removing 1035 the copyright notice or references to the Internet Society or other 1036 Internet organizations, except as needed for the purpose of 1037 developing Internet standards in which case the procedures for 1038 copyrights defined in the Internet Standards process must be 1039 followed, or as required to translate it into other languages. 1041 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1042 Levels", BCP 14, RFC 2119, March 1997 1044 Taylor Standards Track -- Expires Nov 2000 21