From internet-drafts@ietf.org Mon Feb 4 07:49:30 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5121F88B4; Mon, 4 Feb 2013 07:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhYk9ZH9VAkB; Mon, 4 Feb 2013 07:49:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1E421F88B2; Mon, 4 Feb 2013 07:49:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130204154929.18637.98676.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2013 07:49:29 -0800 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-mrb-17.txt X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:49:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Media Server Control Working Group of the= IETF. Title : Media Resource Brokering Author(s) : Chris Boulton Lorenzo Miniero Gary Munson Filename : draft-ietf-mediactrl-mrb-17.txt Pages : 143 Date : 2013-02-04 Abstract: The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-mrb-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Feb 5 13:06:24 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9381921F85C2; Tue, 5 Feb 2013 13:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GHIZ0tr9oSO; Tue, 5 Feb 2013 13:06:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C58621F853E; Tue, 5 Feb 2013 13:06:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130205210624.8059.99328.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2013 13:06:24 -0800 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-mrb-18.txt X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 21:06:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Media Server Control Working Group of the= IETF. Title : Media Resource Brokering Author(s) : Chris Boulton Lorenzo Miniero Gary Munson Filename : draft-ietf-mediactrl-mrb-18.txt Pages : 142 Date : 2013-02-05 Abstract: The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-mrb-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eburger@standardstrack.com Tue Feb 12 15:02:04 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E599521F88CC for ; Tue, 12 Feb 2013 15:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O2jop2Q-LEm for ; Tue, 12 Feb 2013 15:02:04 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 65EA521F88A0 for ; Tue, 12 Feb 2013 15:02:01 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:65390 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U5OrJ-0006Zv-SX for mediactrl@ietf.org; Tue, 12 Feb 2013 15:01:54 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_1DDFB521-F2D5-4ABE-BAEE-ECB6156ECF7E"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> Date: Tue, 12 Feb 2013 18:02:01 -0500 To: "mediactrl@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [MEDIACTRL] MRB seqnumber X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 23:02:05 -0000 --Apple-Mail=_1DDFB521-F2D5-4ABE-BAEE-ECB6156ECF7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The MRB document talks about a seqnumber in a subscription request and = notification response. For your laziness, I have included the entirety = of the text defining both uses: 5.1.3.1. [=85] seqnumber: indicates a sequence number to be used in conjunction with the subscription session id to identify a specific subscription command. The first subscription MUST have 1 as 'seqnumber', and following subscriptions MUST increment by 1 the previous 'seqnumber' value. The attribute MUST be present. [=85] 5.1.5. [=85] seqnumber: indicates a sequence number to be used in conjunction with the subscription session id to identify a specific notification update. The first notification MUST have 1 as 'seqnumber', and following notifications MUST increment by 1 the previous 'seqnumber' value. The attribute MUST be present. It's important to point out that the 'seqnumber' that appears in a is not related to the 'seqnumber' appearing in a . In fact, the latter is associated with subscriptions and would increase at every command issued by the MRB, while the former is associated with the asynchronous notifications the Media Server would trigger according to the subscription, and as such would increase at every notification message to enable the MRB keep track of them. [=85] The AD's are having trouble wrapping their heads around the use of = seqnumber. Upon closer inspection, this chair has trouble wrapping his = head around the utility of seqnumber. On the subscribe side, what does it mean in a TCP/DTLS environment, = where there is no issue of out-of-sequence request delivery, for there = to be an out-of-sequence request? Can anyone tell me the value of = seqnumber in this environment? In particular, what does a server do if = it gets an out of order request (which cannot happen) or a request gets = lost (which cannot happen)? On the notification side, I *think* I *might* see a value of having = monotonically increasing response sequence numbers. If for some reason = the server loses a request, the client might figure out that, for a = given id, no response ever came. However, in a TCP/DTLS environment, = where there is no issue of out-of-sequence notification delivery, what = does it mean for the client to receive an out-of-order response (which = cannot happen) or a request gets lost (which cannot happen)? Unless there is a reason to keep seqnumber, my vote is to take it out = altogether. If there is a reason to keep seqnumber, then we need to describe what a = server does if it gets a request "out of sequence" and what a client = does if it gets a response "out of sequence." Also, if we keep it, I would offer having two attributes that are = unrelated having the same name is confusing at best, and will lead to = implementation errors at worst. Thus, I would propose we give them = different names, like reqseq and respseq. This is the LAST issue holding up publication. Prompt discussion and = resolution is strongly desired.= --Apple-Mail=_1DDFB521-F2D5-4ABE-BAEE-ECB6156ECF7E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjEyMjMwMjAyWjAjBgkqhkiG9w0BCQQxFgQU i1r6031hzuGlIvKVq5ErJ33mu9gwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAAWZM4Wh2U4BLgdo9iqAFZfLH6d54jaqTN+2RrBUI0f0ghuseOMkb 5NpXe+uC9XUK/wuMh1R/67z1QRchxWrqZ0TkNaspZGpZfYB10AdQ7uTgLVGh6mOvi3usMvT3JRSa 6bCgRSHS9m9VqUNMnNCpHLryxSp3xaTSPJby6n3i8jHXTJmF+m7TAZi0EMeGjbcLfsPDX/O1j5LD pv5G1LYW7GnoP/RJCDRmsx3C1/ePVsiYF4krJGjMAMGZDPm6Ygp5NdVWUoGvGGkfutc6jP4b8JIQ wA18Rk0QqjFqwmc19mX8m97MroLfauji3ZnfRwPDMmBwTJd+6RrZR1tdLIcKngAAAAAAAA== --Apple-Mail=_1DDFB521-F2D5-4ABE-BAEE-ECB6156ECF7E-- From chris-standards@ns-technologies.com Wed Feb 13 04:58:59 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7717621F87FD for ; Wed, 13 Feb 2013 04:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aTZkP44jdgJ for ; Wed, 13 Feb 2013 04:58:56 -0800 (PST) Received: from host.quksdns12.net (ns1.quksdns12.net [82.147.22.230]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1321F8782 for ; Wed, 13 Feb 2013 04:58:55 -0800 (PST) Received: from [62.239.63.126] (port=28661 helo=[192.168.102.140]) by host.quksdns12.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U5bvK-000efE-FZ for mediactrl@ietf.org; Wed, 13 Feb 2013 12:58:54 +0000 Message-ID: <511B8D9D.6070506@ns-technologies.com> Date: Wed, 13 Feb 2013 12:57:01 +0000 From: Chris Boulton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mediactrl@ietf.org References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> In-Reply-To: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> Content-Type: multipart/alternative; boundary="------------090109010806060706080504" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.quksdns12.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ns-technologies.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MEDIACTRL] MRB seqnumber X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 12:58:59 -0000 This is a multi-part message in MIME format. --------------090109010806060706080504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, After some discussion we have agreed that the text needs to change slightly to address the comment submitted and other queries we have received. The change would result in subscription reading something like: seqnumber: indicates a sequence number to be used in conjunction with the subscription session id to identify a specific subscription command. The first subscription MUST contain a non-zero number 'seqnumber', and following subscriptions MUST contain a higher number that the previous 'seqnumber' value. If a subsequent 'seqnumber' is not higher, a XXX response code is generated as per section 5.1.4. The attribute MUST be present. This also applies to the notification text in section 5.1.5 and the following text is proposed: seqnumber: indicates a sequence number to be used in conjunction with the subscription session id to identify a specific notification update. The first notification update MUST contain a non-zero number 'seqnumber', and following notification updates MUST contain a higher number that the previous 'seqnumber' value. If a subsequent 'seqnumber' is not higher the situation should be considered an error by the entity receiving the notification update. It is implementation specific how the receiving entity deals with this situation. The attribute MUST be present. Please let me know if you are OK with these changes. Thanks. Chris. On 12/02/2013 23:02, Eric Burger wrote: > The MRB document talks about a seqnumber in a subscription request and notification response. For your laziness, I have included the entirety of the text defining both uses: > > 5.1.3.1. > [...] > seqnumber: indicates a sequence number to be used in conjunction > with the subscription session id to identify a specific > subscription command. The first subscription MUST have 1 as > 'seqnumber', and following subscriptions MUST increment by 1 the > previous 'seqnumber' value. The attribute MUST be present. > > [...] > > 5.1.5. > [...] > seqnumber: indicates a sequence number to be used in conjunction > with the subscription session id to identify a specific > notification update. The first notification MUST have 1 as > 'seqnumber', and following notifications MUST increment by 1 the > previous 'seqnumber' value. The attribute MUST be present. > > It's important to point out that the 'seqnumber' that appears in a > is not related to the 'seqnumber' appearing in a > . In fact, the latter is associated with > subscriptions and would increase at every command issued by the MRB, > while the former is associated with the asynchronous notifications > the Media Server would trigger according to the subscription, and as > such would increase at every notification message to enable the MRB > keep track of them. > [...] > > > The AD's are having trouble wrapping their heads around the use of seqnumber. Upon closer inspection, this chair has trouble wrapping his head around the utility of seqnumber. > > On the subscribe side, what does it mean in a TCP/DTLS environment, where there is no issue of out-of-sequence request delivery, for there to be an out-of-sequence request? Can anyone tell me the value of seqnumber in this environment? In particular, what does a server do if it gets an out of order request (which cannot happen) or a request gets lost (which cannot happen)? > > On the notification side, I *think* I *might* see a value of having monotonically increasing response sequence numbers. If for some reason the server loses a request, the client might figure out that, for a given id, no response ever came. However, in a TCP/DTLS environment, where there is no issue of out-of-sequence notification delivery, what does it mean for the client to receive an out-of-order response (which cannot happen) or a request gets lost (which cannot happen)? > > > Unless there is a reason to keep seqnumber, my vote is to take it out altogether. > > If there is a reason to keep seqnumber, then we need to describe what a server does if it gets a request "out of sequence" and what a client does if it gets a response "out of sequence." > > Also, if we keep it, I would offer having two attributes that are unrelated having the same name is confusing at best, and will lead to implementation errors at worst. Thus, I would propose we give them different names, like reqseq and respseq. > > > > This is the LAST issue holding up publication. Prompt discussion and resolution is strongly desired. > > > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl -- Chris Boulton CTO & Co-founder NS-Technologies m: +44.7876.476681 --------------090109010806060706080504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
All,

After some discussion we have agreed that the text needs to change slightly to address the comment submitted and other queries we have received.  The change would result in subscription reading something like:

 seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      subscription command.  The first subscription MUST contain a non-zero number
      'seqnumber', and following subscriptions MUST contain a higher number that the
      previous 'seqnumber' value.  If a subsequent 'seqnumber' is not higher, a XXX response code is generated
as per section 5.1.4.  The attribute MUST be present.

This also applies to the notification text in section 5.1.5 and the following text is proposed:

seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      notification update.  The first notification update MUST contain a non-zero number
      'seqnumber', and following notification updates MUST contain a higher number that the
      previous 'seqnumber' value.  If a subsequent 'seqnumber' is not higher the situation should
      be considered an error by the entity receiving the notification update.  It is implementation
     specific how the receiving entity deals with this situation.  The attribute MUST be present.

Please let me know if you are OK with these changes.

Thanks.

Chris.


On 12/02/2013 23:02, Eric Burger wrote:
The MRB document talks about a seqnumber in a subscription request and notification response. For your laziness, I have included the entirety of the text defining both uses:

5.1.3.1.  <subscription>
[…]
   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      subscription command.  The first subscription MUST have 1 as
      'seqnumber', and following subscriptions MUST increment by 1 the
      previous 'seqnumber' value.  The attribute MUST be present.

[…]

5.1.5.  <mrbnotification>
[…]
   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      notification update.  The first notification MUST have 1 as
      'seqnumber', and following notifications MUST increment by 1 the
      previous 'seqnumber' value.  The attribute MUST be present.

   It's important to point out that the 'seqnumber' that appears in a
   <mrbnotification> is not related to the 'seqnumber' appearing in a
   <mrbsubscription>.  In fact, the latter is associated with
   subscriptions and would increase at every command issued by the MRB,
   while the former is associated with the asynchronous notifications
   the Media Server would trigger according to the subscription, and as
   such would increase at every notification message to enable the MRB
   keep track of them.
[…]


The AD's are having trouble wrapping their heads around the use of seqnumber. Upon closer inspection, this chair has trouble wrapping his head around the utility of seqnumber.

On the subscribe side, what does it mean in a TCP/DTLS environment, where there is no issue of out-of-sequence request delivery, for there to be an out-of-sequence request? Can anyone tell me the value of seqnumber in this environment? In particular, what does a server do if it gets an out of order request (which cannot happen) or a request gets lost (which cannot happen)?

On the notification side, I *think* I *might* see a value of having monotonically increasing response sequence numbers. If for some reason the server loses a request, the client might figure out that, for a given id, no response ever came. However, in a TCP/DTLS environment, where there is no issue of out-of-sequence notification delivery, what does it mean for the client to receive an out-of-order response (which cannot happen) or a request gets lost (which cannot happen)?

<chair hat off>
Unless there is a reason to keep seqnumber, my vote is to take it out altogether.

If there is a reason to keep seqnumber, then we need to describe what a server does if it gets a request "out of sequence" and what a client does if it gets a response "out of sequence."

Also, if we keep it, I would offer having two attributes that are unrelated having the same name is confusing at best, and will lead to implementation errors at worst. Thus, I would propose we give them different names, like reqseq and respseq.


<chair hat on>
This is the LAST issue holding up publication.  Prompt discussion and resolution is strongly desired.


_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl


--
Chris Boulton
CTO & Co-founder
NS-Technologies
m: +44.7876.476681
--------------090109010806060706080504-- From smcg.stds01@mcglashan.org Wed Feb 13 05:06:55 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AEE21F885C for ; Wed, 13 Feb 2013 05:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gUH05aeLaOB for ; Wed, 13 Feb 2013 05:06:54 -0800 (PST) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by ietfa.amsl.com (Postfix) with ESMTP id C96CC21F8842 for ; Wed, 13 Feb 2013 05:06:53 -0800 (PST) Received: from [192.168.0.34] (host81-132-170-45.range81-132.btcentralplus.com [81.132.170.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by csmtp2.one.com (Postfix) with ESMTPSA id 653C0301769F; Wed, 13 Feb 2013 13:06:50 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_B44C8E47-3D2C-4466-B83F-85D7F6B7BAE5" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Scott McGlashan In-Reply-To: <511B8D9D.6070506@ns-technologies.com> Date: Wed, 13 Feb 2013 13:06:49 +0000 Message-Id: <2BA7543D-69BB-446F-8685-0C98CDBEB2BB@mcglashan.org> References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> <511B8D9D.6070506@ns-technologies.com> To: Chris Boulton X-Mailer: Apple Mail (2.1499) Cc: mediactrl@ietf.org Subject: Re: [MEDIACTRL] MRB seqnumber X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:06:55 -0000 --Apple-Mail=_B44C8E47-3D2C-4466-B83F-85D7F6B7BAE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sounds good Chris. +1 from me. thanks Scott On 13 Feb 2013, at 12:57, Chris Boulton = wrote: > All, >=20 > After some discussion we have agreed that the text needs to change = slightly to address the comment submitted and other queries we have = received. The change would result in subscription reading something = like: >=20 > seqnumber: indicates a sequence number to be used in conjunction > with the subscription session id to identify a specific > subscription command. The first subscription MUST contain a = non-zero number=20 > 'seqnumber', and following subscriptions MUST contain a higher = number that the > previous 'seqnumber' value. If a subsequent 'seqnumber' is not = higher, a XXX response code is generated > as per section 5.1.4. The attribute MUST be present. >=20 > This also applies to the notification text in section 5.1.5 and the = following text is proposed: >=20 > seqnumber: indicates a sequence number to be used in conjunction > with the subscription session id to identify a specific > notification update. The first notification update MUST contain = a non-zero number=20 > 'seqnumber', and following notification updates MUST contain a = higher number that the > previous 'seqnumber' value. If a subsequent 'seqnumber' is not = higher the situation should > be considered an error by the entity receiving the notification = update. It is implementation > specific how the receiving entity deals with this situation. The = attribute MUST be present. >=20 > Please let me know if you are OK with these changes. >=20 > Thanks. >=20 > Chris. >=20 >=20 > On 12/02/2013 23:02, Eric Burger wrote: >> The MRB document talks about a seqnumber in a subscription request = and notification response. For your laziness, I have included the = entirety of the text defining both uses: >>=20 >> 5.1.3.1. >> [=85] >> seqnumber: indicates a sequence number to be used in conjunction >> with the subscription session id to identify a specific >> subscription command. The first subscription MUST have 1 as >> 'seqnumber', and following subscriptions MUST increment by 1 = the >> previous 'seqnumber' value. The attribute MUST be present. >>=20 >> [=85] >>=20 >> 5.1.5. >> [=85] >> seqnumber: indicates a sequence number to be used in conjunction >> with the subscription session id to identify a specific >> notification update. The first notification MUST have 1 as >> 'seqnumber', and following notifications MUST increment by 1 = the >> previous 'seqnumber' value. The attribute MUST be present. >>=20 >> It's important to point out that the 'seqnumber' that appears in a >> is not related to the 'seqnumber' appearing in a >> . In fact, the latter is associated with >> subscriptions and would increase at every command issued by the = MRB, >> while the former is associated with the asynchronous notifications >> the Media Server would trigger according to the subscription, and = as >> such would increase at every notification message to enable the = MRB >> keep track of them. >> [=85] >>=20 >>=20 >> The AD's are having trouble wrapping their heads around the use of = seqnumber. Upon closer inspection, this chair has trouble wrapping his = head around the utility of seqnumber. >>=20 >> On the subscribe side, what does it mean in a TCP/DTLS environment, = where there is no issue of out-of-sequence request delivery, for there = to be an out-of-sequence request? Can anyone tell me the value of = seqnumber in this environment? In particular, what does a server do if = it gets an out of order request (which cannot happen) or a request gets = lost (which cannot happen)? >>=20 >> On the notification side, I *think* I *might* see a value of having = monotonically increasing response sequence numbers. If for some reason = the server loses a request, the client might figure out that, for a = given id, no response ever came. However, in a TCP/DTLS environment, = where there is no issue of out-of-sequence notification delivery, what = does it mean for the client to receive an out-of-order response (which = cannot happen) or a request gets lost (which cannot happen)? >>=20 >> >> Unless there is a reason to keep seqnumber, my vote is to take it out = altogether. >>=20 >> If there is a reason to keep seqnumber, then we need to describe what = a server does if it gets a request "out of sequence" and what a client = does if it gets a response "out of sequence." >>=20 >> Also, if we keep it, I would offer having two attributes that are = unrelated having the same name is confusing at best, and will lead to = implementation errors at worst. Thus, I would propose we give them = different names, like reqseq and respseq. >>=20 >>=20 >> >> This is the LAST issue holding up publication. Prompt discussion and = resolution is strongly desired. >>=20 >>=20 >> _______________________________________________ >> MEDIACTRL mailing list >> MEDIACTRL@ietf.org >> https://www.ietf.org/mailman/listinfo/mediactrl >> Supplemental Web Site: >> http://www.standardstrack.com/ietf/mediactrl >=20 >=20 > --=20 > Chris Boulton > CTO & Co-founder > NS-Technologies > m: +44.7876.476681 > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl --Apple-Mail=_B44C8E47-3D2C-4466-B83F-85D7F6B7BAE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 chris-standards@ns-tec= hnologies.com> wrote:
=20 =20
All,

After some discussion we have agreed that the text needs to change slightly to address the comment submitted and other queries we have received.  The change would result in subscription = reading something like:

 seqnumber:  indicates a sequence number to be used in = conjunction
      with the subscription session id to = identify a specific
      subscription command.  The = first subscription MUST contain a non-zero number
      'seqnumber', and following = subscriptions MUST contain a higher number that the
      previous 'seqnumber' value.  = If a subsequent 'seqnumber' is not higher, a XXX response code is generated
as per section 5.1.4.  The attribute MUST be present.

This also applies to the notification text in section 5.1.5 and the following text is proposed:

seqnumber:  indicates a sequence number to be used in = conjunction
      with the subscription session id to = identify a specific
      notification update.  The = first notification update MUST contain a non-zero number
      'seqnumber', and following = notification updates MUST contain a higher number that the
      previous 'seqnumber' value.  = If a subsequent 'seqnumber' is not higher the situation should
      be considered an error by the = entity receiving the notification update.  It is implementation
     specific how the receiving entity deals = with this situation.  The attribute MUST be present.

Please let me know if you are OK with these changes.

Thanks.

Chris.


On 12/02/2013 23:02, Eric Burger wrote:
The MRB document talks about a seqnumber in a =
subscription request and notification response. For your laziness, I =
have included the entirety of the text defining both uses:

5.1.3.1.  <subscription>
[=85]
   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      subscription command.  The first subscription MUST have 1 as
      'seqnumber', and following subscriptions MUST increment by 1 the
      previous 'seqnumber' value.  The attribute MUST be present.

[=85]

5.1.5.  <mrbnotification>
[=85]
   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      notification update.  The first notification MUST have 1 as
      'seqnumber', and following notifications MUST increment by 1 the
      previous 'seqnumber' value.  The attribute MUST be present.

   It's important to point out that the 'seqnumber' that appears in a
   <mrbnotification> is not related to the 'seqnumber' appearing =
in a
   <mrbsubscription>.  In fact, the latter is associated with
   subscriptions and would increase at every command issued by the MRB,
   while the former is associated with the asynchronous notifications
   the Media Server would trigger according to the subscription, and as
   such would increase at every notification message to enable the MRB
   keep track of them.
[=85]


The AD's are having trouble wrapping their heads around the use of =
seqnumber. Upon closer inspection, this chair has trouble wrapping his =
head around the utility of seqnumber.

On the subscribe side, what does it mean in a TCP/DTLS environment, =
where there is no issue of out-of-sequence request delivery, for there =
to be an out-of-sequence request? Can anyone tell me the value of =
seqnumber in this environment? In particular, what does a server do if =
it gets an out of order request (which cannot happen) or a request gets =
lost (which cannot happen)?

On the notification side, I *think* I *might* see a value of having =
monotonically increasing response sequence numbers. If for some reason =
the server loses a request, the client might figure out that, for a =
given id, no response ever came. However, in a TCP/DTLS environment, =
where there is no issue of out-of-sequence notification delivery, what =
does it mean for the client to receive an out-of-order response (which =
cannot happen) or a request gets lost (which cannot happen)?

<chair hat off>
Unless there is a reason to keep seqnumber, my vote is to take it out =
altogether.

If there is a reason to keep seqnumber, then we need to describe what a =
server does if it gets a request "out of sequence" and what a client =
does if it gets a response "out of sequence."

Also, if we keep it, I would offer having two attributes that are =
unrelated having the same name is confusing at best, and will lead to =
implementation errors at worst. Thus, I would propose we give them =
different names, like reqseq and respseq.


<chair hat on>
This is the LAST issue holding up publication.  Prompt discussion and =
resolution is strongly desired.


_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.=
org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standards=
track.com/ietf/mediactrl


--
Chris Boulton
CTO & Co-founder
NS-Technologies
m: +44.7876.476681
_______________________________________________
MEDIACTRL mailing = list
MEDIACTRL@ietf.org
https://www.i= etf.org/mailman/listinfo/mediactrl
Supplemental Web = Site:
http://www.standardstrack.com/ietf/mediactrl
= --Apple-Mail=_B44C8E47-3D2C-4466-B83F-85D7F6B7BAE5-- From lorenzo@meetecho.com Thu Feb 14 02:11:54 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC0221F871E for ; Thu, 14 Feb 2013 02:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDrcEy9umjwy for ; Thu, 14 Feb 2013 02:11:52 -0800 (PST) Received: from smtpdg4.aruba.it (smtpdg222.aruba.it [62.149.158.222]) by ietfa.amsl.com (Postfix) with ESMTP id 3521921F8681 for ; Thu, 14 Feb 2013 02:11:44 -0800 (PST) Received: from rainpc ([79.12.154.50]) by smtpcmd02.ad.aruba.it with bizsmtp id 0ABh1l00k15WMEv01ABhjC; Thu, 14 Feb 2013 11:11:42 +0100 Date: Thu, 14 Feb 2013 11:11:41 +0100 From: Lorenzo Miniero To: Chris Boulton Message-ID: <20130214111141.1be4b19a@rainpc> In-Reply-To: <511B8D9D.6070506@ns-technologies.com> References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> <511B8D9D.6070506@ns-technologies.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.13; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mediactrl@ietf.org Subject: Re: [MEDIACTRL] MRB seqnumber X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:11:54 -0000 On Wed, 13 Feb 2013 12:57:01 +0000 Chris Boulton wrote: > All, > > After some discussion we have agreed that the text needs to change > slightly to address the comment submitted and other queries we have > received. The change would result in subscription reading something like: > > seqnumber: indicates a sequence number to be used in conjunction > with the subscription session id to identify a specific > subscription command. The first subscription MUST contain a > non-zero number > 'seqnumber', and following subscriptions MUST contain a higher > number that the > previous 'seqnumber' value. If a subsequent 'seqnumber' is not > higher, a XXX response code is generated > as per section 5.1.4. The attribute MUST be present. > > This also applies to the notification text in section 5.1.5 and the > following text is proposed: > > seqnumber: indicates a sequence number to be used in conjunction > with the subscription session id to identify a specific > notification update. The first notification update MUST contain > a non-zero number > 'seqnumber', and following notification updates MUST contain a > higher number that the > previous 'seqnumber' value. If a subsequent 'seqnumber' is not > higher the situation should > be considered an error by the entity receiving the notification > update. It is implementation > specific how the receiving entity deals with this situation. The > attribute MUST be present. > > Please let me know if you are OK with these changes. > Of course I support them all: +1 from me as well. L. > Thanks. > > Chris. > > > On 12/02/2013 23:02, Eric Burger wrote: > > The MRB document talks about a seqnumber in a subscription request and notification response. For your laziness, I have included the entirety of the text defining both uses: > > > > 5.1.3.1. > > [...] > > seqnumber: indicates a sequence number to be used in conjunction > > with the subscription session id to identify a specific > > subscription command. The first subscription MUST have 1 as > > 'seqnumber', and following subscriptions MUST increment by 1 the > > previous 'seqnumber' value. The attribute MUST be present. > > > > [...] > > > > 5.1.5. > > [...] > > seqnumber: indicates a sequence number to be used in conjunction > > with the subscription session id to identify a specific > > notification update. The first notification MUST have 1 as > > 'seqnumber', and following notifications MUST increment by 1 the > > previous 'seqnumber' value. The attribute MUST be present. > > > > It's important to point out that the 'seqnumber' that appears in a > > is not related to the 'seqnumber' appearing in a > > . In fact, the latter is associated with > > subscriptions and would increase at every command issued by the MRB, > > while the former is associated with the asynchronous notifications > > the Media Server would trigger according to the subscription, and as > > such would increase at every notification message to enable the MRB > > keep track of them. > > [...] > > > > > > The AD's are having trouble wrapping their heads around the use of seqnumber. Upon closer inspection, this chair has trouble wrapping his head around the utility of seqnumber. > > > > On the subscribe side, what does it mean in a TCP/DTLS environment, where there is no issue of out-of-sequence request delivery, for there to be an out-of-sequence request? Can anyone tell me the value of seqnumber in this environment? In particular, what does a server do if it gets an out of order request (which cannot happen) or a request gets lost (which cannot happen)? > > > > On the notification side, I *think* I *might* see a value of having monotonically increasing response sequence numbers. If for some reason the server loses a request, the client might figure out that, for a given id, no response ever came. However, in a TCP/DTLS environment, where there is no issue of out-of-sequence notification delivery, what does it mean for the client to receive an out-of-order response (which cannot happen) or a request gets lost (which cannot happen)? > > > > > > Unless there is a reason to keep seqnumber, my vote is to take it out altogether. > > > > If there is a reason to keep seqnumber, then we need to describe what a server does if it gets a request "out of sequence" and what a client does if it gets a response "out of sequence." > > > > Also, if we keep it, I would offer having two attributes that are unrelated having the same name is confusing at best, and will lead to implementation errors at worst. Thus, I would propose we give them different names, like reqseq and respseq. > > > > > > > > This is the LAST issue holding up publication. Prompt discussion and resolution is strongly desired. > > > > > > _______________________________________________ > > MEDIACTRL mailing list > > MEDIACTRL@ietf.org > > https://www.ietf.org/mailman/listinfo/mediactrl > > Supplemental Web Site: > > http://www.standardstrack.com/ietf/mediactrl > > > -- > Chris Boulton > CTO & Co-founder > NS-Technologies > m: +44.7876.476681 -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From spromano@unina.it Thu Feb 14 02:37:25 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B25021F865B for ; Thu, 14 Feb 2013 02:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlN5nwLQF5mo for ; Thu, 14 Feb 2013 02:37:24 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id C8EFA21F8654 for ; Thu, 14 Feb 2013 02:37:23 -0800 (PST) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r1EAbKN2004951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 11:37:20 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_808EC88B-DEAF-40D3-86A9-9426BBA3A9DC" From: Simon Pietro Romano In-Reply-To: <20130214111141.1be4b19a@rainpc> Date: Thu, 14 Feb 2013 11:37:20 +0100 Message-Id: References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> <511B8D9D.6070506@ns-technologies.com> <20130214111141.1be4b19a@rainpc> To: Lorenzo Miniero X-Mailer: Apple Mail (2.1283) Cc: mediactrl@ietf.org Subject: Re: [MEDIACTRL] MRB seqnumber X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:37:25 -0000 --Apple-Mail=_808EC88B-DEAF-40D3-86A9-9426BBA3A9DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 from here. Simon Il giorno 14/feb/2013, alle ore 11:11, Lorenzo Miniero ha scritto: > On Wed, 13 Feb 2013 12:57:01 +0000 > Chris Boulton wrote: >=20 >> All, >>=20 >> After some discussion we have agreed that the text needs to change=20 >> slightly to address the comment submitted and other queries we have=20= >> received. The change would result in subscription reading something = like: >>=20 >> seqnumber: indicates a sequence number to be used in conjunction >> with the subscription session id to identify a specific >> subscription command. The first subscription MUST contain a=20 >> non-zero number >> 'seqnumber', and following subscriptions MUST contain a higher=20= >> number that the >> previous 'seqnumber' value. If a subsequent 'seqnumber' is not=20= >> higher, a XXX response code is generated >> as per section 5.1.4. The attribute MUST be present. >>=20 >> This also applies to the notification text in section 5.1.5 and the=20= >> following text is proposed: >>=20 >> seqnumber: indicates a sequence number to be used in conjunction >> with the subscription session id to identify a specific >> notification update. The first notification update MUST = contain=20 >> a non-zero number >> 'seqnumber', and following notification updates MUST contain a=20= >> higher number that the >> previous 'seqnumber' value. If a subsequent 'seqnumber' is not=20= >> higher the situation should >> be considered an error by the entity receiving the notification=20= >> update. It is implementation >> specific how the receiving entity deals with this situation. The=20= >> attribute MUST be present. >>=20 >> Please let me know if you are OK with these changes. >>=20 >=20 >=20 > Of course I support them all: +1 from me as well. >=20 > L. >=20 >> Thanks. >>=20 >> Chris. >>=20 >>=20 >> On 12/02/2013 23:02, Eric Burger wrote: >>> The MRB document talks about a seqnumber in a subscription request = and notification response. For your laziness, I have included the = entirety of the text defining both uses: >>>=20 >>> 5.1.3.1. >>> [...] >>> seqnumber: indicates a sequence number to be used in conjunction >>> with the subscription session id to identify a specific >>> subscription command. The first subscription MUST have 1 as >>> 'seqnumber', and following subscriptions MUST increment by 1 = the >>> previous 'seqnumber' value. The attribute MUST be present. >>>=20 >>> [...] >>>=20 >>> 5.1.5. >>> [...] >>> seqnumber: indicates a sequence number to be used in conjunction >>> with the subscription session id to identify a specific >>> notification update. The first notification MUST have 1 as >>> 'seqnumber', and following notifications MUST increment by 1 = the >>> previous 'seqnumber' value. The attribute MUST be present. >>>=20 >>> It's important to point out that the 'seqnumber' that appears in = a >>> is not related to the 'seqnumber' appearing in = a >>> . In fact, the latter is associated with >>> subscriptions and would increase at every command issued by the = MRB, >>> while the former is associated with the asynchronous = notifications >>> the Media Server would trigger according to the subscription, and = as >>> such would increase at every notification message to enable the = MRB >>> keep track of them. >>> [...] >>>=20 >>>=20 >>> The AD's are having trouble wrapping their heads around the use of = seqnumber. Upon closer inspection, this chair has trouble wrapping his = head around the utility of seqnumber. >>>=20 >>> On the subscribe side, what does it mean in a TCP/DTLS environment, = where there is no issue of out-of-sequence request delivery, for there = to be an out-of-sequence request? Can anyone tell me the value of = seqnumber in this environment? In particular, what does a server do if = it gets an out of order request (which cannot happen) or a request gets = lost (which cannot happen)? >>>=20 >>> On the notification side, I *think* I *might* see a value of having = monotonically increasing response sequence numbers. If for some reason = the server loses a request, the client might figure out that, for a = given id, no response ever came. However, in a TCP/DTLS environment, = where there is no issue of out-of-sequence notification delivery, what = does it mean for the client to receive an out-of-order response (which = cannot happen) or a request gets lost (which cannot happen)? >>>=20 >>> >>> Unless there is a reason to keep seqnumber, my vote is to take it = out altogether. >>>=20 >>> If there is a reason to keep seqnumber, then we need to describe = what a server does if it gets a request "out of sequence" and what a = client does if it gets a response "out of sequence." >>>=20 >>> Also, if we keep it, I would offer having two attributes that are = unrelated having the same name is confusing at best, and will lead to = implementation errors at worst. Thus, I would propose we give them = different names, like reqseq and respseq. >>>=20 >>>=20 >>> >>> This is the LAST issue holding up publication. Prompt discussion = and resolution is strongly desired. >>>=20 >>>=20 >>> _______________________________________________ >>> MEDIACTRL mailing list >>> MEDIACTRL@ietf.org >>> https://www.ietf.org/mailman/listinfo/mediactrl >>> Supplemental Web Site: >>> http://www.standardstrack.com/ietf/mediactrl >>=20 >>=20 >> --=20 >> Chris Boulton >> CTO & Co-founder >> NS-Technologies >> m: +44.7876.476681 >=20 >=20 > --=20 > Lorenzo Miniero, COB >=20 > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_808EC88B-DEAF-40D3-86A9-9426BBA3A9DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 +1 = from here.

Simon

Il giorno = 14/feb/2013, alle ore 11:11, Lorenzo Miniero ha scritto:

On = Wed, 13 Feb 2013 12:57:01 +0000
Chris Boulton <chris-standards@ns-tec= hnologies.com> wrote:

All,

After some = discussion we have agreed that the text needs to change =
slightly to address the = comment submitted and other queries we have
received.  The change would result in subscription = reading something like:

=  seqnumber:  indicates a sequence number to be used in = conjunction
=       with the subscription session id to = identify a specific
=       subscription command.  The = first subscription MUST contain a
non-zero number
=       'seqnumber', and following = subscriptions MUST contain a higher
number that the
=       previous 'seqnumber' value.  If = a subsequent 'seqnumber' is not
higher, a XXX response code is = generated
as per section = 5.1.4.  The attribute MUST be present.

This also = applies to the notification text in section 5.1.5 and the =
following text is = proposed:

seqnumber: =  indicates a sequence number to be used in = conjunction
=       with the subscription session id to = identify a specific
=       notification update.  The first = notification update MUST contain
a non-zero number
=       'seqnumber', and following = notification updates MUST contain a
higher number that the
      previous 'seqnumber' = value.  If a subsequent 'seqnumber' is not =
higher the situation = should
=       be considered an error by the entity = receiving the notification
update.  It is = implementation
=      specific how the receiving entity deals = with this situation. The
attribute MUST be present.

Please let me = know if you are OK with these changes.



Of course I support them all: +1 = from me as well.

L.

Thanks.

Chris.


On 12/02/2013 = 23:02, Eric Burger wrote:
The MRB document talks about a = seqnumber in a subscription request and notification response. For your = laziness, I have included the entirety of the text defining both = uses:

5.1.3.1. =  <subscription>
[...]
   seqnumber: =  indicates a sequence number to be used in = conjunction
=       with the subscription session id to = identify a specific
=       subscription command.  The = first subscription MUST have 1 = as
      'seqnumber', and = following subscriptions MUST increment by 1 = the
      previous 'seqnumber' = value.  The attribute MUST be = present.

[...]

5.1.5. =  <mrbnotification>
[...]
   seqnumber: =  indicates a sequence number to be used in = conjunction
=       with the subscription session id to = identify a specific
=       notification update.  The first = notification MUST have 1 as
=       'seqnumber', and following = notifications MUST increment by 1 = the
      previous 'seqnumber' = value.  The attribute MUST be = present.

   It's = important to point out that the 'seqnumber' that appears in = a
   <mrbnotification> is not related = to the 'seqnumber' appearing in = a
   <mrbsubscription>.  In fact, = the latter is associated with
   subscriptions = and would increase at every command issued by the = MRB,
   while the former is associated with the = asynchronous notifications
   the Media = Server would trigger according to the subscription, and = as
   such would increase at every = notification message to enable the = MRB
   keep track of = them.
[...]


The AD's are having trouble = wrapping their heads around the use of seqnumber. Upon closer = inspection, this chair has trouble wrapping his head around the utility = of seqnumber.

On the subscribe side, what does = it mean in a TCP/DTLS environment, where there is no issue of = out-of-sequence request delivery, for there to be an out-of-sequence = request? Can anyone tell me the value of seqnumber in this environment? = In particular, what does a server do if it gets an out of order request = (which cannot happen) or a request gets lost (which cannot = happen)?

On the notification side, I = *think* I *might* see a value of having monotonically increasing = response sequence numbers. If for some reason the server loses a = request, the client might figure out that, for a given id, no response = ever came. However, in a TCP/DTLS environment, where there is no issue = of out-of-sequence notification delivery, what does it mean for the = client to receive an out-of-order response (which cannot happen) or a = request gets lost (which cannot = happen)?

<chair hat = off>
Unless there is a reason to keep seqnumber, my vote is to = take it out altogether.

If there is a reason to keep = seqnumber, then we need to describe what a server does if it gets a = request "out of sequence" and what a client does if it gets a response = "out of sequence."

Also, if we keep it, I would = offer having two attributes that are unrelated having the same name is = confusing at best, and will lead to implementation errors at worst. = Thus, I would propose we give them different names, like reqseq and = respseq.


<chair hat = on>
This is the LAST issue holding up publication. =  Prompt discussion and resolution is strongly = desired.


_______________________________________________
MEDIACTRL mailing = list
MEDIACTRL@ietf.org
=
https://www.ietf.= org/mailman/listinfo/mediactrl
Supplemental Web = Site:
http://www.standards= track.com/ietf/mediactrl


-- =
Chris = Boulton
CTO & = Co-founder
NS-Technologies = <http://www.ns-technologies.com= >
m: = +44.7876.476681


--
Lorenzo Miniero, = COB

Meetecho s.r.l.
Web Conferencing and Collaboration = Tools
http://www.meetecho.com
__________= _____________________________________
MEDIACTRL mailing = list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediac= trl
Supplemental Web = Site:
http://www.standardstrack.com/ietf/mediactrl


      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_808EC88B-DEAF-40D3-86A9-9426BBA3A9DC-- From eburger@cs.georgetown.edu Thu Feb 14 08:43:05 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B545C21F8614 for ; Thu, 14 Feb 2013 08:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qYkqqDc4FBI for ; Thu, 14 Feb 2013 08:43:04 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id D0CD821F85EA for ; Thu, 14 Feb 2013 08:43:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id F0AED433E6 for ; Thu, 14 Feb 2013 11:43:02 -0500 (EST) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ktiFQsWpD3T for ; Thu, 14 Feb 2013 11:43:01 -0500 (EST) Received: from [141.161.20.235] (unknown [141.161.20.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 4785F43396 for ; Thu, 14 Feb 2013 11:43:01 -0500 (EST) From: Burger Eric Content-Type: multipart/alternative; boundary="Apple-Mail=_5D531292-E711-4071-BB3A-E702BB4728CB" Message-Id: <896AC59D-662C-4EA7-AF31-47535841D132@cs.georgetown.edu> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Thu, 14 Feb 2013 11:43:05 -0500 References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> <511B8D9D.6070506@ns-technologies.com> <20130214111141.1be4b19a@rainpc> To: "mediactrl@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 14 Feb 2013 08:49:38 -0800 Subject: Re: [MEDIACTRL] MRB seqnumber X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 16:43:05 -0000 --Apple-Mail=_5D531292-E711-4071-BB3A-E702BB4728CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Me, too. On Feb 14, 2013, at 5:37 AM, Simon Pietro Romano = wrote: > +1 from here. >=20 > Simon >=20 > Il giorno 14/feb/2013, alle ore 11:11, Lorenzo Miniero ha scritto: >=20 >> On Wed, 13 Feb 2013 12:57:01 +0000 >> Chris Boulton wrote: >>=20 >>> All, >>>=20 >>> After some discussion we have agreed that the text needs to change=20= >>> slightly to address the comment submitted and other queries we have=20= >>> received. The change would result in subscription reading something = like: >>>=20 >>> seqnumber: indicates a sequence number to be used in conjunction >>> with the subscription session id to identify a specific >>> subscription command. The first subscription MUST contain a=20= >>> non-zero number >>> 'seqnumber', and following subscriptions MUST contain a higher=20= >>> number that the >>> previous 'seqnumber' value. If a subsequent 'seqnumber' is = not=20 >>> higher, a XXX response code is generated >>> as per section 5.1.4. The attribute MUST be present. >>>=20 >>> This also applies to the notification text in section 5.1.5 and the=20= >>> following text is proposed: >>>=20 >>> seqnumber: indicates a sequence number to be used in conjunction >>> with the subscription session id to identify a specific >>> notification update. The first notification update MUST = contain=20 >>> a non-zero number >>> 'seqnumber', and following notification updates MUST contain a=20= >>> higher number that the >>> previous 'seqnumber' value. If a subsequent 'seqnumber' is = not=20 >>> higher the situation should >>> be considered an error by the entity receiving the = notification=20 >>> update. It is implementation >>> specific how the receiving entity deals with this situation. = The=20 >>> attribute MUST be present. >>>=20 >>> Please let me know if you are OK with these changes. >>>=20 >>=20 >>=20 >> Of course I support them all: +1 from me as well. >>=20 >> L. >>=20 >>> Thanks. >>>=20 >>> Chris. >>>=20 >>>=20 >>> On 12/02/2013 23:02, Eric Burger wrote: >>>> The MRB document talks about a seqnumber in a subscription request = and notification response. For your laziness, I have included the = entirety of the text defining both uses: >>>>=20 >>>> 5.1.3.1. >>>> [...] >>>> seqnumber: indicates a sequence number to be used in = conjunction >>>> with the subscription session id to identify a specific >>>> subscription command. The first subscription MUST have 1 as >>>> 'seqnumber', and following subscriptions MUST increment by 1 = the >>>> previous 'seqnumber' value. The attribute MUST be present. >>>>=20 >>>> [...] >>>>=20 >>>> 5.1.5. >>>> [...] >>>> seqnumber: indicates a sequence number to be used in = conjunction >>>> with the subscription session id to identify a specific >>>> notification update. The first notification MUST have 1 as >>>> 'seqnumber', and following notifications MUST increment by 1 = the >>>> previous 'seqnumber' value. The attribute MUST be present. >>>>=20 >>>> It's important to point out that the 'seqnumber' that appears in = a >>>> is not related to the 'seqnumber' appearing in = a >>>> . In fact, the latter is associated with >>>> subscriptions and would increase at every command issued by the = MRB, >>>> while the former is associated with the asynchronous = notifications >>>> the Media Server would trigger according to the subscription, = and as >>>> such would increase at every notification message to enable the = MRB >>>> keep track of them. >>>> [...] >>>>=20 >>>>=20 >>>> The AD's are having trouble wrapping their heads around the use of = seqnumber. Upon closer inspection, this chair has trouble wrapping his = head around the utility of seqnumber. >>>>=20 >>>> On the subscribe side, what does it mean in a TCP/DTLS environment, = where there is no issue of out-of-sequence request delivery, for there = to be an out-of-sequence request? Can anyone tell me the value of = seqnumber in this environment? In particular, what does a server do if = it gets an out of order request (which cannot happen) or a request gets = lost (which cannot happen)? >>>>=20 >>>> On the notification side, I *think* I *might* see a value of having = monotonically increasing response sequence numbers. If for some reason = the server loses a request, the client might figure out that, for a = given id, no response ever came. However, in a TCP/DTLS environment, = where there is no issue of out-of-sequence notification delivery, what = does it mean for the client to receive an out-of-order response (which = cannot happen) or a request gets lost (which cannot happen)? >>>>=20 >>>> >>>> Unless there is a reason to keep seqnumber, my vote is to take it = out altogether. >>>>=20 >>>> If there is a reason to keep seqnumber, then we need to describe = what a server does if it gets a request "out of sequence" and what a = client does if it gets a response "out of sequence." >>>>=20 >>>> Also, if we keep it, I would offer having two attributes that are = unrelated having the same name is confusing at best, and will lead to = implementation errors at worst. Thus, I would propose we give them = different names, like reqseq and respseq. >>>>=20 >>>>=20 >>>> >>>> This is the LAST issue holding up publication. Prompt discussion = and resolution is strongly desired. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEDIACTRL mailing list >>>> MEDIACTRL@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mediactrl >>>> Supplemental Web Site: >>>> http://www.standardstrack.com/ietf/mediactrl >>>=20 >>>=20 >>> --=20 >>> Chris Boulton >>> CTO & Co-founder >>> NS-Technologies >>> m: +44.7876.476681 >>=20 >>=20 >> --=20 >> Lorenzo Miniero, COB >>=20 >> Meetecho s.r.l. >> Web Conferencing and Collaboration Tools >> http://www.meetecho.com >> _______________________________________________ >> MEDIACTRL mailing list >> MEDIACTRL@ietf.org >> https://www.ietf.org/mailman/listinfo/mediactrl >> Supplemental Web Site: >> http://www.standardstrack.com/ietf/mediactrl >>=20 >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico = II > Computer Engineering Department=20 > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( = ( ) > \_) ) = / > = (_/ >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl --Apple-Mail=_5D531292-E711-4071-BB3A-E702BB4728CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Me, = too.

On Feb 14, 2013, at 5:37 AM, Simon Pietro Romano = <spromano@unina.it> = wrote:

+1 from = here.

Simon

Il giorno = 14/feb/2013, alle ore 11:11, Lorenzo Miniero ha scritto:

On Wed, 13 = Feb 2013 12:57:01 +0000
Chris Boulton <chris-standards@ns-tec= hnologies.com> wrote:

All,

After some = discussion we have agreed that the text needs to change =
slightly to address the = comment submitted and other queries we have
received.  The change would result in subscription = reading something like:

=  seqnumber:  indicates a sequence number to be used in = conjunction
=       with the subscription session id to = identify a specific
=       subscription command.  The = first subscription MUST contain a
non-zero number
=       'seqnumber', and following = subscriptions MUST contain a higher
number that the
=       previous 'seqnumber' value.  If = a subsequent 'seqnumber' is not
higher, a XXX response code is = generated
as per section = 5.1.4.  The attribute MUST be present.

This also = applies to the notification text in section 5.1.5 and the =
following text is = proposed:

seqnumber: =  indicates a sequence number to be used in = conjunction
=       with the subscription session id to = identify a specific
=       notification update.  The first = notification update MUST contain
a non-zero number
=       'seqnumber', and following = notification updates MUST contain a
higher number that the
      previous 'seqnumber' = value.  If a subsequent 'seqnumber' is not =
higher the situation = should
=       be considered an error by the entity = receiving the notification
update.  It is = implementation
=      specific how the receiving entity deals = with this situation. The
attribute MUST be present.

Please let me = know if you are OK with these changes.



Of course I support them all: +1 = from me as well.

L.

Thanks.

Chris.


On 12/02/2013 = 23:02, Eric Burger wrote:
The MRB document talks about a = seqnumber in a subscription request and notification response. For your = laziness, I have included the entirety of the text defining both = uses:

5.1.3.1. =  <subscription>
[...]
   seqnumber: =  indicates a sequence number to be used in = conjunction
=       with the subscription session id to = identify a specific
=       subscription command.  The = first subscription MUST have 1 = as
      'seqnumber', and = following subscriptions MUST increment by 1 = the
      previous 'seqnumber' = value.  The attribute MUST be = present.

[...]

5.1.5. =  <mrbnotification>
[...]
   seqnumber: =  indicates a sequence number to be used in = conjunction
=       with the subscription session id to = identify a specific
=       notification update.  The first = notification MUST have 1 as
=       'seqnumber', and following = notifications MUST increment by 1 = the
      previous 'seqnumber' = value.  The attribute MUST be = present.

   It's = important to point out that the 'seqnumber' that appears in = a
   <mrbnotification> is not related = to the 'seqnumber' appearing in = a
   <mrbsubscription>.  In fact, = the latter is associated with
   subscriptions = and would increase at every command issued by the = MRB,
   while the former is associated with the = asynchronous notifications
   the Media = Server would trigger according to the subscription, and = as
   such would increase at every = notification message to enable the = MRB
   keep track of = them.
[...]


The AD's are having trouble = wrapping their heads around the use of seqnumber. Upon closer = inspection, this chair has trouble wrapping his head around the utility = of seqnumber.

On the subscribe side, what does = it mean in a TCP/DTLS environment, where there is no issue of = out-of-sequence request delivery, for there to be an out-of-sequence = request? Can anyone tell me the value of seqnumber in this environment? = In particular, what does a server do if it gets an out of order request = (which cannot happen) or a request gets lost (which cannot = happen)?

On the notification side, I = *think* I *might* see a value of having monotonically increasing = response sequence numbers. If for some reason the server loses a = request, the client might figure out that, for a given id, no response = ever came. However, in a TCP/DTLS environment, where there is no issue = of out-of-sequence notification delivery, what does it mean for the = client to receive an out-of-order response (which cannot happen) or a = request gets lost (which cannot = happen)?

<chair hat = off>
Unless there is a reason to keep seqnumber, my vote is to = take it out altogether.

If there is a reason to keep = seqnumber, then we need to describe what a server does if it gets a = request "out of sequence" and what a client does if it gets a response = "out of sequence."

Also, if we keep it, I would = offer having two attributes that are unrelated having the same name is = confusing at best, and will lead to implementation errors at worst. = Thus, I would propose we give them different names, like reqseq and = respseq.


<chair hat = on>
This is the LAST issue holding up publication. =  Prompt discussion and resolution is strongly = desired.


_______________________________________________
MEDIACTRL mailing = list
MEDIACTRL@ietf.org
=
https://www.ietf.= org/mailman/listinfo/mediactrl
Supplemental Web = Site:
http://www.standards= track.com/ietf/mediactrl


-- =
Chris = Boulton
CTO & = Co-founder
NS-Technologies = <http://www.ns-technologies.com>
m: = +44.7876.476681


--
Lorenzo Miniero, = COB

Meetecho s.r.l.
Web Conferencing and Collaboration = Tools
http://www.meetecho.com
_________= ______________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.i= etf.org/mailman/listinfo/mediactrl
Supplemental Web = Site:
http://www.standardstrack.com/ietf/mediactrl

=

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/




=
_______________________________________________
MEDIACT= RL mailing list
MEDIACTRL@ietf.org
https://www.i= etf.org/mailman/listinfo/mediactrl
Supplemental Web = Site:
http://www.standardstrack.com/ietf/mediactrl= --Apple-Mail=_5D531292-E711-4071-BB3A-E702BB4728CB-- From tobia.castaldi@unina.it Fri Feb 15 04:00:25 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B5721F8602 for ; Fri, 15 Feb 2013 04:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2HojZ0TY038 for ; Fri, 15 Feb 2013 04:00:23 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0C21F8B34 for ; Fri, 15 Feb 2013 04:00:11 -0800 (PST) Received: from [143.225.229.175] ([143.225.229.175]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r1FC081p006217 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 15 Feb 2013 13:00:10 +0100 Message-ID: <511E2344.4040902@unina.it> Date: Fri, 15 Feb 2013 13:00:04 +0100 From: Tobia Castaldi UniNa User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mediactrl@ietf.org References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> <511B8D9D.6070506@ns-technologies.com> <20130214111141.1be4b19a@rainpc> <896AC59D-662C-4EA7-AF31-47535841D132@cs.georgetown.edu> In-Reply-To: <896AC59D-662C-4EA7-AF31-47535841D132@cs.georgetown.edu> Content-Type: multipart/alternative; boundary="------------000506060903060609040600" Subject: Re: [MEDIACTRL] MRB seqnumber X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 12:00:25 -0000 This is a multi-part message in MIME format. --------------000506060903060609040600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit +1 Tobia Il 14/02/2013 17.43, Burger Eric ha scritto: > Me, too. > > On Feb 14, 2013, at 5:37 AM, Simon Pietro Romano > wrote: > >> +1 from here. >> >> Simon >> >> Il giorno 14/feb/2013, alle ore 11:11, Lorenzo Miniero ha scritto: >> >>> On Wed, 13 Feb 2013 12:57:01 +0000 >>> Chris Boulton >> > wrote: >>> >>>> All, >>>> >>>> After some discussion we have agreed that the text needs to change >>>> slightly to address the comment submitted and other queries we have >>>> received. The change would result in subscription reading >>>> something like: >>>> >>>> seqnumber: indicates a sequence number to be used in conjunction >>>> with the subscription session id to identify a specific >>>> subscription command. The first subscription MUST contain a >>>> non-zero number >>>> 'seqnumber', and following subscriptions MUST contain a higher >>>> number that the >>>> previous 'seqnumber' value. If a subsequent 'seqnumber' is not >>>> higher, a XXX response code is generated >>>> as per section 5.1.4. The attribute MUST be present. >>>> >>>> This also applies to the notification text in section 5.1.5 and the >>>> following text is proposed: >>>> >>>> seqnumber: indicates a sequence number to be used in conjunction >>>> with the subscription session id to identify a specific >>>> notification update. The first notification update MUST contain >>>> a non-zero number >>>> 'seqnumber', and following notification updates MUST contain a >>>> higher number that the >>>> previous 'seqnumber' value. If a subsequent 'seqnumber' is not >>>> higher the situation should >>>> be considered an error by the entity receiving the notification >>>> update. It is implementation >>>> specific how the receiving entity deals with this situation. The >>>> attribute MUST be present. >>>> >>>> Please let me know if you are OK with these changes. >>>> >>> >>> >>> Of course I support them all: +1 from me as well. >>> >>> L. >>> >>>> Thanks. >>>> >>>> Chris. >>>> >>>> >>>> On 12/02/2013 23:02, Eric Burger wrote: >>>>> The MRB document talks about a seqnumber in a subscription request >>>>> and notification response. For your laziness, I have included the >>>>> entirety of the text defining both uses: >>>>> >>>>> 5.1.3.1. >>>>> [...] >>>>> seqnumber: indicates a sequence number to be used in conjunction >>>>> with the subscription session id to identify a specific >>>>> subscription command. The first subscription MUST have 1 as >>>>> 'seqnumber', and following subscriptions MUST increment by 1 the >>>>> previous 'seqnumber' value. The attribute MUST be present. >>>>> >>>>> [...] >>>>> >>>>> 5.1.5. >>>>> [...] >>>>> seqnumber: indicates a sequence number to be used in conjunction >>>>> with the subscription session id to identify a specific >>>>> notification update. The first notification MUST have 1 as >>>>> 'seqnumber', and following notifications MUST increment by 1 the >>>>> previous 'seqnumber' value. The attribute MUST be present. >>>>> >>>>> It's important to point out that the 'seqnumber' that appears in a >>>>> is not related to the 'seqnumber' appearing in a >>>>> . In fact, the latter is associated with >>>>> subscriptions and would increase at every command issued by the >>>>> MRB, >>>>> while the former is associated with the asynchronous notifications >>>>> the Media Server would trigger according to the subscription, >>>>> and as >>>>> such would increase at every notification message to enable the MRB >>>>> keep track of them. >>>>> [...] >>>>> >>>>> >>>>> The AD's are having trouble wrapping their heads around the use of >>>>> seqnumber. Upon closer inspection, this chair has trouble wrapping >>>>> his head around the utility of seqnumber. >>>>> >>>>> On the subscribe side, what does it mean in a TCP/DTLS >>>>> environment, where there is no issue of out-of-sequence request >>>>> delivery, for there to be an out-of-sequence request? Can anyone >>>>> tell me the value of seqnumber in this environment? In particular, >>>>> what does a server do if it gets an out of order request (which >>>>> cannot happen) or a request gets lost (which cannot happen)? >>>>> >>>>> On the notification side, I *think* I *might* see a value of >>>>> having monotonically increasing response sequence numbers. If for >>>>> some reason the server loses a request, the client might figure >>>>> out that, for a given id, no response ever came. However, in a >>>>> TCP/DTLS environment, where there is no issue of out-of-sequence >>>>> notification delivery, what does it mean for the client to receive >>>>> an out-of-order response (which cannot happen) or a request gets >>>>> lost (which cannot happen)? >>>>> >>>>> >>>>> Unless there is a reason to keep seqnumber, my vote is to take it >>>>> out altogether. >>>>> >>>>> If there is a reason to keep seqnumber, then we need to describe >>>>> what a server does if it gets a request "out of sequence" and what >>>>> a client does if it gets a response "out of sequence." >>>>> >>>>> Also, if we keep it, I would offer having two attributes that are >>>>> unrelated having the same name is confusing at best, and will lead >>>>> to implementation errors at worst. Thus, I would propose we give >>>>> them different names, like reqseq and respseq. >>>>> >>>>> >>>>> >>>>> This is the LAST issue holding up publication. Prompt discussion >>>>> and resolution is strongly desired. >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEDIACTRL mailing list >>>>> MEDIACTRL@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mediactrl >>>>> Supplemental Web Site: >>>>> http://www.standardstrack.com/ietf/mediactrl >>>> >>>> >>>> -- >>>> Chris Boulton >>>> CTO & Co-founder >>>> NS-Technologies >>> > >>>> m: +44.7876.476681 >>> >>> >>> -- >>> Lorenzo Miniero, COB >>> >>> Meetecho s.r.l. >>> Web Conferencing and Collaboration Tools >>> http://www.meetecho.com >>> _______________________________________________ >>> MEDIACTRL mailing list >>> MEDIACTRL@ietf.org >>> https://www.ietf.org/mailman/listinfo/mediactrl >>> Supplemental Web Site: >>> http://www.standardstrack.com/ietf/mediactrl >>> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> _______________________________________________ >> MEDIACTRL mailing list >> MEDIACTRL@ietf.org >> https://www.ietf.org/mailman/listinfo/mediactrl >> Supplemental Web Site: >> http://www.standardstrack.com/ietf/mediactrl > > > > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl --------------000506060903060609040600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1
Tobia

Il 14/02/2013 17.43, Burger Eric ha scritto:
Me, too.

On Feb 14, 2013, at 5:37 AM, Simon Pietro Romano <spromano@unina.it> wrote:

+1 from here.

Simon

Il giorno 14/feb/2013, alle ore 11:11, Lorenzo Miniero ha scritto:

On Wed, 13 Feb 2013 12:57:01 +0000
Chris Boulton <chris-standards@ns-technologies.com> wrote:

All,

After some discussion we have agreed that the text needs to change
slightly to address the comment submitted and other queries we have
received.  The change would result in subscription reading something like:

 seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      subscription command.  The first subscription MUST contain a
non-zero number
      'seqnumber', and following subscriptions MUST contain a higher
number that the
      previous 'seqnumber' value.  If a subsequent 'seqnumber' is not
higher, a XXX response code is generated
as per section 5.1.4.  The attribute MUST be present.

This also applies to the notification text in section 5.1.5 and the
following text is proposed:

seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      notification update.  The first notification update MUST contain
a non-zero number
      'seqnumber', and following notification updates MUST contain a
higher number that the
      previous 'seqnumber' value.  If a subsequent 'seqnumber' is not
higher the situation should
      be considered an error by the entity receiving the notification
update.  It is implementation
     specific how the receiving entity deals with this situation. The
attribute MUST be present.

Please let me know if you are OK with these changes.



Of course I support them all: +1 from me as well.

L.

Thanks.

Chris.


On 12/02/2013 23:02, Eric Burger wrote:
The MRB document talks about a seqnumber in a subscription request and notification response. For your laziness, I have included the entirety of the text defining both uses:

5.1.3.1.  <subscription>
[...]
   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      subscription command.  The first subscription MUST have 1 as
      'seqnumber', and following subscriptions MUST increment by 1 the
      previous 'seqnumber' value.  The attribute MUST be present.

[...]

5.1.5.  <mrbnotification>
[...]
   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      notification update.  The first notification MUST have 1 as
      'seqnumber', and following notifications MUST increment by 1 the
      previous 'seqnumber' value.  The attribute MUST be present.

   It's important to point out that the 'seqnumber' that appears in a
   <mrbnotification> is not related to the 'seqnumber' appearing in a
   <mrbsubscription>.  In fact, the latter is associated with
   subscriptions and would increase at every command issued by the MRB,
   while the former is associated with the asynchronous notifications
   the Media Server would trigger according to the subscription, and as
   such would increase at every notification message to enable the MRB
   keep track of them.
[...]


The AD's are having trouble wrapping their heads around the use of seqnumber. Upon closer inspection, this chair has trouble wrapping his head around the utility of seqnumber.

On the subscribe side, what does it mean in a TCP/DTLS environment, where there is no issue of out-of-sequence request delivery, for there to be an out-of-sequence request? Can anyone tell me the value of seqnumber in this environment? In particular, what does a server do if it gets an out of order request (which cannot happen) or a request gets lost (which cannot happen)?

On the notification side, I *think* I *might* see a value of having monotonically increasing response sequence numbers. If for some reason the server loses a request, the client might figure out that, for a given id, no response ever came. However, in a TCP/DTLS environment, where there is no issue of out-of-sequence notification delivery, what does it mean for the client to receive an out-of-order response (which cannot happen) or a request gets lost (which cannot happen)?

<chair hat off>
Unless there is a reason to keep seqnumber, my vote is to take it out altogether.

If there is a reason to keep seqnumber, then we need to describe what a server does if it gets a request "out of sequence" and what a client does if it gets a response "out of sequence."

Also, if we keep it, I would offer having two attributes that are unrelated having the same name is confusing at best, and will lead to implementation errors at worst. Thus, I would propose we give them different names, like reqseq and respseq.


<chair hat on>
This is the LAST issue holding up publication.  Prompt discussion and resolution is strongly desired.


_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl


--
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681


--
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl


                             _\\|//_
                                  ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                      Computer Engineering Department 
             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it

    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                 \ (            (   )
                                  \_)          ) /
                                                                       (_/





_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl



_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

--------------000506060903060609040600-- From internet-drafts@ietf.org Sun Feb 17 23:40:53 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEF721F8B83; Sun, 17 Feb 2013 23:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyED4O3EOrXa; Sun, 17 Feb 2013 23:40:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9DB21F8BB5; Sun, 17 Feb 2013 23:40:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218074052.25391.82191.idtracker@ietfa.amsl.com> Date: Sun, 17 Feb 2013 23:40:52 -0800 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-mrb-19.txt X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 07:40:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Media Server Control Working Group of the= IETF. Title : Media Resource Brokering Author(s) : Chris Boulton Lorenzo Miniero Gary Munson Filename : draft-ietf-mediactrl-mrb-19.txt Pages : 142 Date : 2013-02-17 Abstract: The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-mrb-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Thu Feb 21 13:28:10 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A937621F8F51; Thu, 21 Feb 2013 13:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9mQfKPbpb+S; Thu, 21 Feb 2013 13:28:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366AA21F8F54; Thu, 21 Feb 2013 13:28:01 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130221212801.21496.30133.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 13:28:01 -0800 Cc: mediactrl mailing list , mediactrl chair , RFC Editor Subject: [MEDIACTRL] Protocol Action: 'Media Resource Brokering' to Proposed Standard (draft-ietf-mediactrl-mrb-19.txt) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 21:28:10 -0000 The IESG has approved the following document: - 'Media Resource Brokering' (draft-ietf-mediactrl-mrb-19.txt) as Proposed Standard This document is the product of the Media Server Control Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ Technical Summary The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. Working Group Summary The working group consensus on this document is solid. Two WGLCs were held, one after the initial consensus on the document, and one after extensive review and implementation experience dictated a number of small improvements to the protocol and its description. Document Quality The protocol described in this document has been implemented by several major vendors. The description has also been carefully reviewed by someone not involved in its writing or implementation. Personnel Dale Worley is the document's shepherd. Robert Sparks is the responsible AD. From iesg-secretary@ietf.org Thu Feb 21 13:28:10 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0D521F8F5C for ; Thu, 21 Feb 2013 13:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG3t46uPd0RF; Thu, 21 Feb 2013 13:28:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3563321F8F58; Thu, 21 Feb 2013 13:28:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-mediactrl-mrb X-IETF-Draft-revision: 19 Message-ID: <20130221212804.21496.85472.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 13:28:04 -0800 Cc: mediactrl mailing list , mediactrl chair , RFC Editor Subject: [MEDIACTRL] Protocol Action: 'Media Resource Brokering' to Proposed Standard (draft-ietf-mediactrl-mrb-19.txt) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 21:28:12 -0000 The IESG has approved the following document: - 'Media Resource Brokering' (draft-ietf-mediactrl-mrb-19.txt) as Proposed Standard This document is the product of the Media Server Control Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ Technical Summary The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. Working Group Summary The working group consensus on this document is solid. Two WGLCs were held, one after the initial consensus on the document, and one after extensive review and implementation experience dictated a number of small improvements to the protocol and its description. Document Quality The protocol described in this document has been implemented by several major vendors. The description has also been carefully reviewed by someone not involved in its writing or implementation. Personnel Dale Worley is the document's shepherd. Robert Sparks is the responsible AD. From spencer@wonderhamster.org Thu Feb 21 14:02:59 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD4D21F8934 for ; Thu, 21 Feb 2013 14:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiaDTYpIX4Zi for ; Thu, 21 Feb 2013 14:02:58 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 77F8121F890F for ; Thu, 21 Feb 2013 14:02:52 -0800 (PST) Received: from [192.168.1.79] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net [99.108.174.213]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MAxqe-1TymsA1ZuG-00AAX0; Thu, 21 Feb 2013 17:02:51 -0500 Message-ID: <51269985.4070804@wonderhamster.org> Date: Thu, 21 Feb 2013 16:02:45 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mediactrl mailing list References: <20130221212804.21496.85472.idtracker@ietfa.amsl.com> In-Reply-To: <20130221212804.21496.85472.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130221212804.21496.85472.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:Fwd2S6gpeCnYGGZ6RaPWtedQVk4Zno9z0otyLymqaNl jDdmOo3PYT3/UFHhUwrpe0YuB8cuTrptrMyX841m+Ej7GhipLc 20AW4TFZTtWm4QTWvI3HHQxNBPtaCF+n5TratzFj0XzflrymYC lUWpCH0A2zJHPFICHJ8tmhGt8fymxBVipOh6LI9DhBXuJH+yc9 j7wJ6Ii9nEWvgqgrL4AQUlgUhkWXaS4hfGcnBwCXvtbGi4jLpk wiaWbe8MYcm/1BLNuqHYwVgwRCTV4jwMWPL3S2yx10Qq/pdhD9 YFAHnnK9+w/rDvFlwXP8Je+Va+/G1nQMh82rbQyQSY42hCr3Zl vOwdw5LnXvVYPal25SOZ1V9Iulc2+XlVwAoPAbxWO Subject: [MEDIACTRL] Fwd: Protocol Action: 'Media Resource Brokering' to Proposed Standard (draft-ietf-mediactrl-mrb-19.txt) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:02:59 -0000 You made it! Congratulations! Spencer, the retired previous co-chair ... -------- Original Message -------- Subject: [MEDIACTRL] Protocol Action: 'Media Resource Brokering' to Proposed Standard (draft-ietf-mediactrl-mrb-19.txt) Date: Thu, 21 Feb 2013 13:28:04 -0800 From: The IESG Reply-To: noreply@ietf.org To: IANA CC: mediactrl mailing list , mediactrl chair , RFC Editor The IESG has approved the following document: - 'Media Resource Brokering' (draft-ietf-mediactrl-mrb-19.txt) as Proposed Standard This document is the product of the Media Server Control Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ Technical Summary The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. Working Group Summary The working group consensus on this document is solid. Two WGLCs were held, one after the initial consensus on the document, and one after extensive review and implementation experience dictated a number of small improvements to the protocol and its description. Document Quality The protocol described in this document has been implemented by several major vendors. The description has also been carefully reviewed by someone not involved in its writing or implementation. Personnel Dale Worley is the document's shepherd. Robert Sparks is the responsible AD. _______________________________________________ MEDIACTRL mailing list MEDIACTRL@ietf.org https://www.ietf.org/mailman/listinfo/mediactrl Supplemental Web Site: http://www.standardstrack.com/ietf/mediactrl From eburger@standardstrack.com Fri Feb 22 06:08:10 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A09E21F8CAB for ; Fri, 22 Feb 2013 06:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGacKjX+tVUv for ; Fri, 22 Feb 2013 06:08:09 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id A1D7421F893F for ; Fri, 22 Feb 2013 06:08:09 -0800 (PST) Received: from [141.161.20.235] (port=52951) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U8tI2-0007vt-Rk; Fri, 22 Feb 2013 06:07:54 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: <51269985.4070804@wonderhamster.org> Date: Fri, 22 Feb 2013 09:08:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6D89AEC6-FD23-46AC-87A4-41433813454F@standardstrack.com> References: <20130221212804.21496.85472.idtracker@ietfa.amsl.com> <51269985.4070804@wonderhamster.org> To: Spencer Dawkins X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: mediactrl mailing list Subject: Re: [MEDIACTRL] Protocol Action: 'Media Resource Brokering' to Proposed Standard (draft-ietf-mediactrl-mrb-19.txt) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:08:10 -0000 Thanks! On Feb 21, 2013, at 5:02 PM, Spencer Dawkins = wrote: > You made it! Congratulations! >=20 > Spencer, the retired previous co-chair ... >=20 > -------- Original Message -------- > Subject: [MEDIACTRL] Protocol Action: 'Media Resource Brokering' to = Proposed Standard (draft-ietf-mediactrl-mrb-19.txt) > Date: Thu, 21 Feb 2013 13:28:04 -0800 > From: The IESG > Reply-To: noreply@ietf.org > To: IANA > CC: mediactrl mailing list , mediactrl chair = , RFC Editor = >=20 > The IESG has approved the following document: > - 'Media Resource Brokering' > (draft-ietf-mediactrl-mrb-19.txt) as Proposed Standard >=20 > This document is the product of the Media Server Control Working = Group. >=20 > The IESG contact persons are Robert Sparks and Gonzalo Camarillo. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > The MediaCtrl work group in the IETF has proposed an architecture for > controlling media services. The Session Initiation Protocol (SIP) is > used as the signalling protocol which provides many inherent > capabilities for message routing. In addition to such signalling > properties, a need exists for intelligent, application level media > service selection based on non-static signalling properties. This is > especially true when considered in conjunction with deployment > architectures that include 1:M and M:N combinations of Application > Servers and Media Servers. This document introduces a Media Resource > Broker (MRB) entity which manages the availability of Media Servers > and the media resource demands of Application Servers. The document > includes potential deployment options for an MRB and appropriate > interfaces to Application Servers and Media Servers. >=20 > Working Group Summary >=20 > The working group consensus on this document is solid. Two > WGLCs were held, one after the initial consensus on the > document, and one after extensive review and implementation > experience dictated a number of small improvements to the > protocol and its description. >=20 > Document Quality >=20 > The protocol described in this document has been implemented > by several major vendors. The description has also been > carefully reviewed by someone not involved in its writing or > implementation. >=20 > Personnel >=20 > Dale Worley is the document's shepherd. > Robert Sparks is the responsible AD. > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl >=20 >=20 >=20 > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl