idnits 2.17.1 draft-ietf-megaco-msf-followup-00.txt: 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 3) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MEGACO Working Group Matt Holdrege (Liaison) 2 Internet Draft Multiservice Switching Forum 3 June 1999 Media Control Group 5 Multiservice Switching Forum requirements input to MEGACO 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To view the entire list of current Internet-Drafts, please check 31 the "1id-abstracts.txt" listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 33 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 34 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 35 (US West Coast). 37 Copyright Notice 39 Copyright (C) The Internet Society (1999). All Rights Reserved. 41 Abstract: 42 This document serves as input into the IETF MEGACO requirements 43 process. It includes requirements as input by MSF members and 44 refined by the MSF Media Control group and requests clarifications 45 of requirements currently being considered at IETF. This document 46 has been prepared in response to a document prepared by Nancy 47 Greene, one of the IETF Megaco Requirements editors. This is a 48 followup to a response from MEGACO. 50 Disclaimer: 51 This is a representation of the preliminary requirements generated 52 by the Multiservice Switching Forum/Media Control Working Group. 53 This document has been approved by the Working Group for liaison 54 distribution to the IETF. However, this document in no way binds any 55 of the member organizations to the ideas presented. It should also 56 be noted that this work is incomplete and a draft. It is being 57 submitted now to meet the MEGACO WG timelines. The MSF will revisit 58 this work in the future and may add, change or delete its 59 requirements. 61 I-D MSF requirements followup to MEGACO June 1999 63 Introduction: 64 MSF submitted a document entitled "Multiservice Switching Forum 65 requirements input to MEGACO" to the IETF MEGACO group as Internet 66 draft draft-ietf-megaco-msf-reqs-01.txt for consideration. Most of 67 the requirements proposed in draft-ietf-megaco-msf-reqs-01.txt have 68 been incorporated in the latest MEGACO requirements draft draft- 69 ietf-megaco-reqs-03. Nancy Greene, one of the editors of draft- 70 ietf-megaco-reqs-03 provided a document detailing how the 71 requirements in draft-ietf-megaco-msf-reqs-01.txt are addressed in 72 draft-ietf-megaco-reqs-03. 74 This document requests the addition of requirements into the next 75 IETF MEGACO requirements draft that the MSF Media Control WG does 76 not feel were not adequately addressed in draft-ietf-megaco-reqs-03. 77 This document also requests clarification on some requirements that 78 are currently in draft-ietf-megaco-reqs-03. 80 Requirements: 82 Requirement 1: 83 The original MSF document draft-ietf-megaco-msf-reqs-01.txt stated: 84 Report: The protocol shall allow the request and notification of 85 mid-call trigger events. 87 The current version of draft-ietf-megaco-reqs-03 states: 5.4 c. 88 Allow reporting of detected events on the MG to the MGC. The 89 protocol should provide the means to minimize the messaging required 90 report commonly-occurring event sequences. 92 We would like the MEGACO requirements document to include the 93 following requirement: Report: The protocol shall allow the MGC to 94 request the arming of a mid-call trigger even after the call has 95 been set up. 97 Requirement 2: 98 The original MSF requirement in draft-ietf-megaco-msf-reqs-01.txt 99 read: Function: The Protocol shall allow the recovery or 100 redistribution of traffic without call/packet loss. 102 The IETF response indicated: Not added - no call/packet loss is too 103 strict a requirement. 105 We would like to modify the original requirement to read: Function: 106 The Protocol shall allow the recovery or redistribution of traffic 107 without call loss. 109 We hope that the restated requirement can be included in the IETF 110 MEGACO requirements document. 112 Requirement 3: 113 The requirements draft draft-ietf-megaco-reqs-03.txt states: 8. d. 114 Support scalability from very small to very large MGs: The protocol 115 must support MGs with capacities ranging from one to a few tens of 116 thousands of terminations. 118 I-D MSF requirements followup to MEGACO June 1999 120 We would like to modify the requirement to read: 8. d. Support 121 scalability from very small to very large MGs: The protocol must 122 support MGs with capacities ranging from one to millions of 123 terminations. 125 Clarifications: 126 We would like to require the following clarifications: 128 Clarification 1: The IETF draft draft-ietf-megaco-reqs-03.txt 129 states: 131 5.7. c. Provide the mechanism for the MGC to specify that the MG 132 report accounting information automatically at end of call, in mid- 133 call upon request, at specific time intervals as specified by the 134 MGC and at unit usage thresholds as specified by the MGC. 136 5.7. e. Allow the MGC to have some control over which statistics are 137 reported, to enable it to manage the amount of information 138 transferred. 140 We would like the requirements to clarify the difference between 141 accounting information and statistics. The current requirements have 142 ambiguity regarding these two terms. 144 The MSF view of the terms: Statistics - aggregate information, 145 usage measurements and counters Accounting - per call information, 146 call detail record information (e.g. AMA). This information may be 147 subjected to more rigorous auditing than statistical information as 148 well as regulatory review. 150 Clarification 2: 151 The IETF draft draft-ietf-megaco-reqs-03.txt states: 153 d. Specifically support collection of: 155 * start and stop time, by media flow, 157 * volume of content carried (e.g. number of packets/cells transmit- 158 ted, number received with and without error, interarrival jitter), 159 by media flow, 161 * QOS statistics, by media flow. 163 We would like to understand the reasoning behind collecting the 164 specific type of statistics indicated in draft-ietf-megaco-reqs- 165 03.txt compared to other information (e.g. type of resources like 166 echo cancellers, codecs etc. used.) 168 Author's Address 169 Matt Holdrege 170 Ascend Communications 171 1701 Harbor Bay Parkway 172 Alameda, CA 94502 173 matt@ascend.com