http://permalink.gmane.org/gmane.ietf.avt hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.avt/14442 <pre>Hi, I think we are making progress on this. O/A is challenging to describe in sufficient detail. I can try to find time for a phone call if you think that would significantly speed up the progress. Contact me of list in that case. Comments inline. On 2013-05-13 22:38, Kevin Gross wrote: Yes, I understand the need to discuss when you have a mediaclk the need for having certain types of reference clocks etc. However, usage of the reference clock alone is not clear, neither what is allowed to include, nor how to interpret the answer, and what is allowed in the answer. This must be clarified. Please do. Ok, then I guess the specification should be clear that you shall include a value that says, we don't have a common clock, to separate that from the case of I don't know what this a=ts-refclk is. Although the actual implications may be the same. Yes, I just meant this as a hint that I think the above text proposal should be inserted prior to the above paragraph. Sorry for not being clear. Sure, but </pre> Magnus Westerlund 2013-05-14T08:15:27 http://permalink.gmane.org/gmane.ietf.avt/14441 <pre>Thanks for your continued help improving this. Let me know what you think about my answers and proposed revisions below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt;, www.X192.org On Mon, May 13, 2013 at 2:45 AM, Magnus Westerlund &lt; magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: Reference clock requirements are discussed in parallel with media clock in the paragraphs that follow. The meaning of multiple reference clock specifications is described in section 4.2 and now also 4.3. I think it would be useful to reiterate and expand on the meaning of this in the context of offer/answer as you have suggested. I don't think it is useful for an answer to contain a reference clock specification that is not in the offer. This proposed semantic doesn't fit the normal offer/answer paradigm where the answer describes the connection that will actually be made. When there is no common reference clock, the connection that is made is without a reference clock. d</pre> Kevin Gross 2013-05-13T20:38:20 http://permalink.gmane.org/gmane.ietf.avt/14440 <pre>Hi, I have reivewed the changes and I don't think Section 6.1 nor 6.2 is clear. Intro and the clarification of the relationship between media clock and reference clock is good. "Usage of reference clock and media clock signalling in offer/answer allows the offerer to declare the reference clock and media clock in use and allows the answerer to acknowledge that a connection according to these declarations will be successful or, in limited cases described below, specify a simplified synchronization mode." This implies that the rules also for reference clock handling is to be specified. That is not the case. There is no explanation what an Reference clock offer means and what the limiations on that offer is, nor what the answerer should send back. To my understanding something like this is needed. An offer MAY include multiple a=ts-refclk attributes, however if there is more than one attribute, they MUST be for multiple instances of the same clock type and reference type and be possible to use</pre> Magnus Westerlund 2013-05-13T08:45:19 http://permalink.gmane.org/gmane.ietf.avt/14439 <pre>Due to some strange list issues, I forward this on behalf of Kevin. ---------- Forwarded message ---------- From: Kevin Gross &lt;kevin.gross&lt; at &gt;avanw.com&gt; Date: Wed, May 8, 2013 at 4:58 PM Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt To: "avt&lt; at &gt;ietf.org" &lt;avt&lt; at &gt;ietf.org&gt; This version addresses comments brought up in WGLC as well as issues identified by the authors. The following changes are included. 1. References changed to symbolic due to problems with numbered references in new xml2rfc tool 2. Capitalize normative language 3. Clarify meaning of interchangeable reference clocks 4. Allow specification of multiple 1588 clock sources as is allowed for NTP servers 5. Use consistent "Timestamp reference clock" terminology 6. Remove some lingering synchronization confidence discussion and example 7. Relax definition for mediaclk-ext to allow more complex extensions 8. Rework section 6 (Signalling Considerations) to address comments from Magnus and Roni 9. Specify extension policy fo</pre> Magnus Westerlund 2013-05-13T07:09:25 http://permalink.gmane.org/gmane.ietf.avt/14438 <pre>Roni, With regards to items 5 &amp; 6. 5. Please review my changes to section 8 in the newly published version 04 of the draft. If these changes do not satisfy your request, please cite an example of a policy specification I can work from to improve this further. 6. While the formatting is slightly different, I believe our draft contains all the information in the example you cite and we have the requirements in RFC 5226 section 5.1 covered. I can reformat the section to look more the example you cite but I don't think that would be a material improvement. If we're going to make improvements here I need more specifics on what exactly is not in compliance. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt;, www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Kevin Gross 2013-05-08T23:01:00 http://permalink.gmane.org/gmane.ietf.avt/14437 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : RTP Clock Source Signalling Author(s) : Aidan Williams Kevin Gross Ray van Brandenburg Hans Stokking Filename : draft-ietf-avtcore-clksrc-04.txt Pages : 23 Date : 2013-05-08 Abstract: NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-04 A diff from the prev</pre> internet-drafts< at >ietf.org 2013-05-08T22:49:37 http://permalink.gmane.org/gmane.ietf.avt/14436 <pre>Hi, I have reviewed draft-ietf-avtcore-aria-srtp-01 and have some comments. Please review these and don't hesitate to ask for clarification or disagree with them. 1) Section 2: (1) ARIA in Counter Mode, (2) ARIA in Counter with CBC-MAC (CCM) Mode and (3) ARIA in Galois/Counter Mode (GCM). As you in the next heading are using ARIA-CTR shouldn't (CTR) be added as acronym for (1)? 2) Section 2.1 and 4: What are the security implications of using a 256 bit key length for the crypto but have as weak integrity protection as SAH1 32 bits? I think you need to discuss the implications of this, it doesn't appear to be particular balanced. 3) Section 2.2: The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as that of AES-CCM and AES-GCM. Looking in AES-GCM it appears to define a generic AEAD procedures for SRTP cipher suit</pre> Magnus Westerlund 2013-05-08T14:07:33 http://permalink.gmane.org/gmane.ietf.avt/14435 <pre>This version of the draft has some editorial fixes and makes various minor clarifications. I believe it's ready for another WG last call, along with draft-ietf-avtcore-rtp-security-options. Colin On 7 May 2013, at 13:20, Internet-Drafts&lt; at &gt;ietf.org wrote: </pre> Colin Perkins 2013-05-07T12:26:18 http://permalink.gmane.org/gmane.ietf.avt/14433 <pre>Hi, see inline. On 2013-05-07 02:58, Kevin Gross wrote: Yes, I know I didn't specify the mediaclk. This actually lets me add an additional question here. My understanding is that the offerer's a=ts-refclk above indicates which type of clock it has for determine the NTP timestamp in its RTCP SR packets. However, is it always clear who the offerer is. In the RTCP domain, the actual used clock is bound to one or even more CNAMEs. Should this be explicitly expressed? Agreed. Ok, lets fix this issue. Agree that it doesn't apply as no a=mediaclk is specified. Yes, but it doesn't say anything of what the rules are beyond deriving a default value. That needs to be changed as below discussion indicates. Please be explicit about this exception. I suggest that you are very explicit, especially when discussing clocks that have identifiers on how they are to be compared. Yes, please ensure that there are explicit rules. I also think you need to be explicit about when multiple attributes may occur. I see</pre> Magnus Westerlund 2013-05-07T11:47:48 http://permalink.gmane.org/gmane.ietf.avt/14432 <pre>Kevin, My mistake. Roni From: Kevin Gross [mailto:kevin.gross&lt; at &gt;avanw.com] Sent: 07 May, 2013 2:32 AM To: Roni Even Cc: Magnus Westerlund; IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 The intention is that after "ntp=", there is EITHER a server address (with optional port number) OR "traceable". I believe that's what the code (specifically =/) specifies. If not, please set me straight. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Sun, May 5, 2013 at 3:15 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: Hi Kevin, On comment 2. The syntax is timestamp-refclk = "a=ts-refclk:" clksrc CRLF clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext ntp = "ntp=" ntp-server-addr ntp-server-addr = host [ ":" port ] ntp-server-addr =/ "traceable" this is why I expected a host address Roni From: Kevin Gross [mailto:kevin.gross&lt; at &gt;avanw.co</pre> Roni Even 2013-05-06T23:41:59 http://permalink.gmane.org/gmane.ietf.avt/14431 <pre>The intention is that after "ntp=", there is EITHER a server address (with optional port number) OR "traceable". I believe that's what the code (specifically =/) specifies. If not, please set me straight. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt;, www.X192.org On Sun, May 5, 2013 at 3:15 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Kevin Gross 2013-05-06T23:32:03 http://permalink.gmane.org/gmane.ietf.avt/14430 <pre>Hi, Rereading the O/A I think I understand what my misunderstandings are. However, that still makes me unclear if even the basic cases for a=ts-refclk can be announced by each side. Lets do an example: A: sends an Offer: v=0 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 s=SDP Seminar i=A Seminar on the session description protocol c=IN IP4 233.252.0.1/64 t=2873397496 2873404696 a=ts-refclk:gps m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 Where A is simply telling that his reference clock is GPS based. The other party wants to inform similar that its clock is NTP based and uses the official swedish time from "ntp1.sp.se" is in the answer. The below O/A rules doesn't appear to answer if that can be done or not. 6.1. Usage in Offer/Answer An answer to an offer with direct-referenced media clock and reference clock specification must include the same media clock and reference clock signalling in which case a connection is established using the specified sync</pre> Magnus Westerlund 2013-05-06T14:45:24 http://permalink.gmane.org/gmane.ietf.avt/14429 <pre>WG, (as individual contributor) This update of the RTP security options has a number of improvements. 1. It discusses known usage or inclusion in standard specs of different choices. 2. It has two new examples, PSS and RTSP 2.0. 3. A section on identity. I think this is good enough for its purpose and would really appreciate some feedback on it. Both from people knowing security and people who don't. Cheers Magnus Westerlund On 2013-05-06 11:40, internet-drafts&lt; at &gt;ietf.org wrote: </pre> Magnus Westerlund 2013-05-06T09:48:37 http://permalink.gmane.org/gmane.ietf.avt/14428 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Options for Securing RTP Sessions Author(s) : Magnus Westerlund Colin Perkins Filename : draft-ietf-avtcore-rtp-security-options-03.txt Pages : 32 Date : 2013-05-06 Abstract: The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for develo</pre> internet-drafts< at >ietf.org 2013-05-06T09:40:39 http://permalink.gmane.org/gmane.ietf.avt/14427 <pre>Kevin, Also a=ts-refclk:ntp=traceable probably a=ts-refclk:ntp= host /traceable Roni From: Kevin Gross [mailto:kevin.gross&lt; at &gt;avanw.com] Sent: 05 May, 2013 7:03 AM To: Roni Even Cc: Magnus Westerlund; IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 Roni, Thanks for the review. See below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: Hi Kevin, I looked at the document and at Magnus comment. I am not sure if the document allows offering and two reference clocks. I am not sure what is meant in section 4.2 “Two or more NTP servers may be listed at the same level in the session description to indicate that they are interchangeable. RTP senders or receivers can use any of the listed NTP servers to govern a local clock that is equivalent to a local clock slaved to a different server.” When you sa</pre> Roni Even 2013-05-05T09:18:22 http://permalink.gmane.org/gmane.ietf.avt/14426 <pre>Hi Kevin, On comment 2. The syntax is timestamp-refclk = "a=ts-refclk:" clksrc CRLF clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext ntp = "ntp=" ntp-server-addr ntp-server-addr = host [ ":" port ] ntp-server-addr =/ "traceable" this is why I expected a host address Roni From: Kevin Gross [mailto:kevin.gross&lt; at &gt;avanw.com] Sent: 05 May, 2013 7:03 AM To: Roni Even Cc: Magnus Westerlund; IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 Roni, Thanks for the review. See below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: Hi Kevin, I looked at the document and at Magnus comment. I am not sure if the document allows offering and two reference clocks. I am not sure what is meant in section 4.2 “Two or more NTP servers may be listed at the same </pre> Roni Even 2013-05-05T09:15:37 http://permalink.gmane.org/gmane.ietf.avt/14425 <pre>Roni, Thanks for the review. See below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt;, www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: What we're trying to say is that you're allowed to list multiple clock sources with the understanding that all listed clocks deliver the same time. Any of the clocks can be used interchangeably and synchronization is assured. This capability is intended to support fault-tolerant clock distribution scenarios. For backwards compatibility, when no clock attribute is specified in a description, it has a specific meaning (e.g. local time reference or free-running media clock). For this reason, the answer must echo the offer's clock attribute. This is acknowledgement to the offerer that answerer recognises and supports the clksrc attributes. Basically, yes, although I admit it is a bit strange. IEEE 1588-2002 (clause 6.2.5.1) domain names are 16 character fixed-length strings</pre> Kevin Gross 2013-05-05T04:02:32 http://permalink.gmane.org/gmane.ietf.avt/14424 <pre>Magnus, I believe what we have defined in the draft is the declarative model you have minimally requested. I believe this gives more functionality than you're assuming it does. When used on an engineered network, there will generally be a well-known time source and as such, offers will be compatible with answers. When used on less constrained networks, devices may use a "traceable" clock where the specifics of the exact source of the clock do not need to be exactly matched to make a successful connection. You appear to be proposing that we invent our own multiple-choice negotiation scheme. In writing the offer-answer description I assumed that it would be preferable to use an existing and general scheme for this than new attribute-specific SDP syntax and semantics. Is there something I am missing? I appreciate that we can't assume all user agents will implement RFC 5939 but 5939 is backwards compatible with a declarative fallback mode for those agents. RFC 5939 allows you to specify potential configuratio</pre> Kevin Gross 2013-05-05T03:29:03 http://permalink.gmane.org/gmane.ietf.avt/14423 <pre> This generally looks good, and I had only one comment: if I'm reading RFC 5576 correctly, this draft needs to include IANA registrations for "att-field (source level)" for the SDP attributes, to allow them to be used in the a=ssrc: lines. Making this change will probably also requires changes to the ABNF, to cleanly separate the syntax for "a=..." and "a=ssrc: ..." forms so they can be separately referenced. </pre> Colin Perkins 2013-05-03T16:26:36 http://permalink.gmane.org/gmane.ietf.avt/14422 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T17:15:16 http://permalink.gmane.org/gmane.ietf.avt/14421 <pre>Hi Kevin, I looked at the document and at Magnus comment. I am not sure if the document allows offering and two reference clocks. I am not sure what is meant in section 4.2 “Two or more NTP servers may be listed at the same level in the session description to indicate that they are interchangeable. RTP senders or receivers can use any of the listed NTP servers to govern a local clock that is equivalent to a local clock slaved to a different server.” When you say interchangeable and how it relates to Magnus proposal to allow negotiation. I also assume that the information in offer/answer and in declarative SDP is used to provide sender information and not receiver one so is there a reason to have the same media clock in both direction when using conversional (offer/answer) application Other comments 1. ptp-domain-name = "domain-name=" 16ptp-domain-char – did you mean exactly 16 charaters? 2. In figure 2 a=ts-refclk:ntp=traceable – do you need also to specify the ser</pre> Roni Even 2013-04-24T14:01:09 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.avt