Re: IETF Meeting in South America
On 5/27/2013 11:38 PM, Christian O'Flaherty wrote: I would like to follow up on this proposal. Having a meeting in South America scheduled two or three years in advance will let us engage local organisations and individuals on a project. We did several activities in the region trying to encourage IETF participation, but we're going to be much more effective if they're part of a plan with a strong commitment (and effort) from the IETF community. Such a project sounds like an excellent idea and it could be interesting to pursue it with coordination from the IETF community. One point worth noting is that the primary work of the IETF is conducted over email. Consequently, the project does not require an in-person meeting with the IETF community. In fact, relying on an in-person meeting for the effort is counter-productive training for being effective in the IETF. I don't mean that such meetings aren't useful, but that I believe they are secondary to the work that is done over the rest of the time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
while i appreciate joe's listening to my other comments on the draft, i still strongly object to publication of this draft as an rfc for the reasons made very clear in the sec cons. please read the summary section of rfc 2804. While the RFC should not be materially misleading, I don't think there is a requirement for Informational RFCs to guarantee any particular level or security or privacy. that the draft now tries to slide by as info does not change that it specified protocol elements and how they are to be used. and the draft makes very clear that this is juristiction specific and a serious privacy problem. RFC 2804 is about i am very well aware what 2804 contains RFC 2804 doesn't seem to me to be particularly applicable. i disagree. i believe the first two bullets in section one are very applicable to joe's draft. - The IETF, an international standards body, believes itself to be the wrong forum for designing protocol or equipment features that address needs arising from the laws of individual countries, because these laws vary widely across the areas that IETF standards are deployed in. Bodies whose scope of authority correspond to a single regime of jurisdiction are more appropriate for this task. - The IETF sets standards for communications that pass across networks that may be owned, operated and maintained by people from numerous jurisdictions with numerous requirements for privacy. In light of these potentially divergent requirements, the IETF believes that the operation of the Internet and the needs of its users are best served by making sure the security properties of connections across the Internet are as well known as possible. At the present stage of our ignorance this means making them as free from security loopholes as possible. randy
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi Donald, At 21:09 27-05-2013, Donald Eastlake wrote: While the RFC should not be materially misleading, I don't think there is a requirement for Informational RFCs to guarantee any particular level or security or privacy. Yes. In my opinion a best effort is preferable or else the Security Considerations section in RFCs is useless. In theory the IETF does not publish RFCs to suit the regulations of one country (see use-case in draft-jabley-dnsext-eui48-eui64-rrtypes-04). In practice, the IETF has published a RFC to suit the requirements (it was a voluntary measure instead of a formal requirement) of one country. draft-jabley-dnsext-eui48-eui64-rrtypes-04 is an odd case. My guess is that the requirements were set because of a problem of monopoly. I have not looked into whether the transfer of data violates the expectations of the user. I understand that the draft is about standardizing [1] a data format and not the transfer of data. Section 8 of the draft says everything correctly except that it doesn't provide adequate security guidance. I believe that Joe tried to do the right thing. I am not comfortable objecting to publication as I don't know the path forward. I personally would not support publication. That can easily be overcome and I won't do anything about it. Regards, -sm 1. I did read Section 2 carefully.
Re: Issues in wider geographic participation
Your experience and ideas on how to start-out are useful. On 27 May 2013 16:13, Yoav Nir y...@checkpoint.com wrote: LCD? Anyway, What I found most useful when I was starting out 9 years ago, was to look over the list of areas and working groups ( http://tools.ietf.org/area/ ) and find out which of them are working on something that is of interest to me. In my case it was mostly the security area, and the IPsec working group, since that is what I was working on in my day job. I subscribed to that list and some others that were also related to what I was working on (TLS, PKIX). So the best thing is to subscribe to the mailing lists, both those that interest you personally and those that are of interest to your employer (if there are such groups). Step 2 is to lurk for a couple of weeks at least, and just read what others are posting. If they're talking about a particular draft, it's easy to find on one of the IETF sites and read it. So you read the drafts, and read what people are saying about the drafts. This teaches you both about what the group is working on, and the (for lack of a better term) political part - who are the participants and what are they like. You might also want to read the Tao document, although different groups have varying dynamics. After a while, you've read the drafts, you've read what some people are saying, and you may have formed an opinion, either about the draft itself, or about one of the comments. That's a good time to speak up by sending a message to the list. Maybe the draft got something wrong. Maybe the comment is only correct in certain contexts, but doesn't describe some situation you're familiar with. Maybe in reading the draft you find it hard to figure out what an implementation should do in a certain case, and you present the case, and ask that it be clarified. Maybe the proposed protocol would require clients, servers, or middleboxes to allocate more memory than implementations that you know can afford. Such comments, and even better, proposed fixes are how you build a reputation in the IETF for knowing your stuff. You can also volunteer to review a whole document, or volunteer to write a missing section. That is how you build a reputation for being useful. Both are necessary for success in the IETF. Step 4 is when you have an idea of your own, or you read someone else's idea and you want to participate. In that case you either write your own draft or join someone else in writing one. It's often not enough to just write it. You also have to get people to read it, post about it to the correct lists, and in general sell it and gather support. It is at about that time that you start to feel the need to attend meetings, but you can get some things done even without it. Hope this helps Yoav On May 27, 2013, at 3:33 PM, Nthabiseng Pule np...@lca.org.ls wrote: as, I am new to the IETF. I would like to contribute any way I can, but the learning curve seems steep indeed. I am from an LCD country. I have the necessary resources but I just don't know where to start. Some guidance would be welcome. I am reading on stuff and hope that one day I will be able to make some meaningful contribution. Nthabiseng Pule On 27 May 2013, at 1:52 PM, Arturo Servin aser...@lacnic.net wrote: John, Good summary. I would add a steep learning-curve to start participating. It takes time to get conformable in participating in mailing list and reviewing drafts for I think two reasons. One is to get know how the IETF works, and another to catch-up in knowing the topic in relation with other WG participants. About the remote hub I think it would be good to give it a try. Regards, as On 27 May 2013, at 02:52, John Levine wrote: I think this is a summary of the issues people have mentioned that discourage participation from LDCs, in rough order of importance. * People aren't aware the IETF exists, or what it does, or that it has an open participation model * People don't read and write English well enough to be comfortable participating * People are unaccustomed to and perhaps uncomfortable expressing overt disagreement * People don't think they have anything to contribute to an organization that is mostly people from rich countries * People don't have adequate Internet access for mail, or to use the remote participation tools I have to say that I don't see one or two meetings in South America addressing any of these. Given that the incremental cost to the participants, compared to meeting in North America, would likely be on the order of a million dollars, it seems to me very likely that there are better ways to spend the money. For example, if language and net access is a problem, it might be interesting to set up a remote participation center in B.A. during one of the North American meetings (it's one time zone off from
When to adopt a WG I-D
Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
Re: Issues in wider geographic participation
Sorry, I meant LCD. Nthabiseng Pule On 27 May 2013, at 5:48 PM, John R Levine jo...@taugh.com wrote: On Mon, 27 May 2013, Yoav Nir wrote: LCD? LDC, Less Developed Country, what used to be called the third world, now that the second has been bought by the first. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 2013-05-28, at 3:38, SM s...@resistor.net wrote: In theory the IETF does not publish RFCs to suit the regulations of one country (see use-case in draft-jabley-dnsext-eui48-eui64-rrtypes-04). In practice, the IETF has published a RFC to suit the requirements (it was a voluntary measure instead of a formal requirement) of one country. Note that there's no suggestion that these RRTypes are required by the CRTC. The example given was for a situation where Interop would have been beneficial (so that cable resellers have an obvious, stable and supported way of encoding this kind of information. draft-jabley-dnsext-eui48-eui64-rrtypes-04 is an odd case. My guess is that the requirements were set because of a problem of monopoly. The opposite actually: cable operators are required to provide access to subscribers on behalf of third parties in order to promote competition. There are multiple such cable providers and multiple such resellers. (TekSavvy is one such reseller of multiple cable companies' access networks.) I have not looked into whether the transfer of data violates the expectations of the user. The CRTC's decisions are public, and one might hope they would show their working. The Canadian courts have been pretty protective of user privacy in general, I would say. I understand that the draft is about standardizing [1] a data format and not the transfer of data. Section 8 of the draft says everything correctly except that it doesn't provide adequate security guidance. Feel free to point out the gaps, and/or to suggest text. I believe that Joe tried to do the right thing. I am not comfortable objecting to publication as I don't know the path forward. I personally would not support publication. That can easily be overcome and I won't do anything about it. Thanks for the thoughtful review. Joe
RE: When to adopt a WG I-D
Hi, Good work. Here are a few thoughts after a first reading. - We seem not to have a definition of what a WG I-D is, although we know how to recognize a WG I-D because of the naming convention. So, if I am not mistaken the phrase Working Group drafts are documents that are subject to IETF Working Group revision control. in section 1.1 introduces such a definition. Is everybody happy with this? - I am lacking from the criteria in 2.2 the stability of the technical solution (as per WG consensus). In my mind this is in current practice the principal specific difference between individual submission I-Ds and WG I-Ds - the fact that the I-D makes a clear (it may be drafty but yet clear) statement about what the technical solution is. - I less like the following: * If not already in scope, is a simple modification to the charter feasible and warranted? Without being extremely strict on the process aspect, I believe that WGs should not work on items that are not chartered, and even less adopt WG I-Ds on non-chartered items. If they feel that something is missing from the charter they can ask the ADs for a charter update, or for adding milestones, we have today at hand light processes which can lead to fast incremental additions to charters, and if the addition is more than incremental than it should go through a proper rechartering process. - * What is the position of the working group chairs, concerning the draft? [[editor note: I am not sure this is relevant. Indeed is might be specifically not relevant. /a]] Not relevant IMO. Regards, Dan -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, May 28, 2013 12:33 PM To: ietf@ietf.org Subject: When to adopt a WG I-D Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
Re: When to adopt a WG I-D
Nicely written, largely stating what might be obvious for many, but still nice to see it in black and white. A few comments/suggestions: 1) Section 3. Authors/Editors I suggest that you suggest that WG (co)chair(s) add an editor that is unrelated to the draft, but that they trust who has good editing skills. As we all well know, that is half the battle for getting a draft successfully across the finish line and to the IESG. How many times has the IESG seen drafts that are not up to snuff in some (editorially-related) manner? This person might also keep the draft's trajectory motivated in the forward progress direction. Finally, in cases where a draft is controversial, this //might// aid in diffusing any electric situations. 2) Section 5.2. Competing Drafts states: Engineering for interesting topics often produces competing, interesting proposals. I suggest replacing interesting proposals with just competing proposals I'd also put a reference here to the point I made above. 3) A little further in this section, I suggesting amending the text a bit from: Sometimes, multiple versions are formally published, absent consensus among the alternatives. to something like: Sometimes, multiple versions are formally published, absent consensus among the alternatives. In this way, marketplace economics and preferences are allowed to weigh-in on the relevancy of one approach versus the other(s). In these cases, the working group should be prepared to revisit the drafts later once a clear preference in the marketplace exists. At this time the working group should be prepared to amend, narrow or delete the competing approaches as necessary, in order to clarify the multiple approaches to as narrow a selection of options as possible once the approaches are ready for Proposed Standard status. 4) There is also no mention of functioning and interoperability of implementations, and hence no reference to the working code part of the mantra. I think it is important to provide some guidance in this regard during all phases of the document's states. For example, two competing approaches, but one with running and demonstrable interoperating code might cause a WG to err in that direction rather than having competing approaches just because a second one was dreamt up at the last minute for political reasons. --Tom Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Tuesday, May 28, 2013 15:42 +0900 Randy Bush ra...@psg.com wrote: ... While the RFC should not be materially misleading, I don't think there is a requirement for Informational RFCs to guarantee any particular level or security or privacy. that the draft now tries to slide by as info does not change that it specified protocol elements and how they are to be used. and the draft makes very clear that this is juristiction specific and a serious privacy problem. Hmm. I'm not happy with several aspects of the content of the draft, including the privacy issue. I'm also not happy with it as an apparent example of if one has a piece of information that needs to be accessible sometimes, put it in the DNS whether the characteristics of the DNS are a good match for the information and retrieval requirements or not. For those reasons, and because of the principles expressed in RFC2804, I believe it was completely unacceptable as a Standards Track document. Perhaps these RRTYPEs should never have been created and registered. If so, the balance between community review and maximizing the number of things that are registered (and the resulting avoidance of conflicts) is wrong for RRTYPEs. That would imply a need to revisit the registration policy, but it wouldn't change the status of these two RRTYPEs. But it seems to me that none of that is at issue at this stage. What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. Put differently, are these RRTYPEs sufficiently reprehensible that we would hope to make them non-interoperable in practice by not telling people how to make them work. I believe that would be a bad plan and would violate principles far more basic than the 2804 ones -- the IETF should not be setting itself up as the arbiter of what can be deployed on the Internet if only because we would certainly fail. If people find these RRTYPEs (or the document) reprehensible, then let me suggest that they generate an I-D in Applicability Statement form that identifies them as Not Recommended and generally obscene and to do so and show sufficient consensus quickly enough to convince the IESG to force a normative reference to it into this document so they can be published together. I also don't see slide by as info in this. Like you, I opposed making this standards track and saw serious issues with 2804 in that context. Tuning aside, only two changes have been made to the document between -03 and -04 and both are intended to make it clear that the _description_ of these RRTYPEs does not constitute a recommendation to use them and that, if one has serious security concerns that outweigh other considerations, one should not use them (or put EUI-* information into the DNS in any other way). That makes the document about as close to being information about how these RRTYPEs work without recommending their use as I can figure out how to get it (others can probably do better, but apparently haven't stepped forward with text). It also contains a pretty strong caution about their use. I think that is appropriate too. It stops short of saying not recommended because the latter would imply standards track (and Joe might not agree). RFC 2804 is about i am very well aware what 2804 contains RFC 2804 doesn't seem to me to be particularly applicable. i disagree. i believe the first two bullets in section one are very applicable to joe's draft. - The IETF, an international standards body, believes itself to be the wrong forum for designing protocol or ... In authorizing the publication of an Informational document that describes how something works for the information of the community, the IETF is not acting as an international standards body even though it is being consistent with its goal of making the Internet better by providing documentation that facilitates interoperability. The idea of providing registrations for non-standardized objects has the same goal. If we were willing to register only those objects that met our standards-track criteria, then we would encourage both code point squatting (seen in many other cases) or kludges that overload existing code points (as we have seen with TXT RRs) and damaging interoperability in both cases. I don't see the issues in simply documenting things as different and we certainly have a long tradition of encouraging the RFC Editor to publish that type of documentation. best, john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. there are two solutions to this randy
Re: IETF Meeting in South America
Hi, Actually it's not industry that I hear complaining, but individuals. Eliot On 5/27/13 10:08 AM, Jari Arkko wrote: Melinda wrote: The industry sector bias in IETF participation is possibly compounding the regional bias. Yes. Jari
Re: IETF Meeting in South America
Riiight. That is why one never has to attend an IETF meeting in person to serve on NOMCOM, one does not need travel support from one's employer to be on the IESG, and why people who never come to IETF meetings are the rule and not the exception with respect to getting documents adopted and published. Oops - I got my sense wrong there…. On May 28, 2013, at 2:29 AM, Dave Crocker d...@dcrocker.net wrote: On 5/27/2013 11:38 PM, Christian O'Flaherty wrote: I would like to follow up on this proposal. Having a meeting in South America scheduled two or three years in advance will let us engage local organisations and individuals on a project. We did several activities in the region trying to encourage IETF participation, but we're going to be much more effective if they're part of a plan with a strong commitment (and effort) from the IETF community. Such a project sounds like an excellent idea and it could be interesting to pursue it with coordination from the IETF community. One point worth noting is that the primary work of the IETF is conducted over email. Consequently, the project does not require an in-person meeting with the IETF community. In fact, relying on an in-person meeting for the effort is counter-productive training for being effective in the IETF. I don't mean that such meetings aren't useful, but that I believe they are secondary to the work that is done over the rest of the time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: IETF Meeting in South America
On May 28, 2013, at 8:46 AM, Eric Burger ebur...@standardstrack.com wrote: Riiight. That is why one never has to attend an IETF meeting in person to serve on NOMCOM, one does not need travel support from one's employer to be on the IESG, and why people who never come to IETF meetings are the rule and not the exception with respect to getting documents adopted and published. The IETF has a big problem, IMHO, in that effective participation really does currently seem to require meeting attendance. There's a reason that nomcom members have to show up—if they didn't, they wouldn't be part of the actual culture of IETF, because so much IETF culture is bound up in the physical meetings. The interaction we get in the physical meetings is really important. I would very much like to see the IETF try to discover new ways of using the technology our forebears (and some remaining senior participants) invented to achieve the same effectiveness without requiring us to all burn tons of fuel getting to remote corners of the globe. But achieve the same effectiveness is an important requirement for any such new solution. And right now we don't have a solution like that, so we do what we do, and you are right that that means that effective participation in the IETF is much easier for people who are able to attend at least a sufficiency of meetings on an ongoing basis. We should see this as a starting point, not as an end state.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
Considering how long and painful the retrofit (RFC 4412) for SIP was, yes, I think it is important to plan for it early. Janet . ietf-boun...@ietf.org wrote on 05/25/2013 03:10:07 AM: From: Jari Arkko jari.ar...@piuha.net To: James Polk jmp...@cisco.com Cc: ietf@ietf.org list ietf@ietf.org Date: 05/25/2013 03:10 AM Subject: WebRTC and emergency communications (Was: Re: IETF Meeting in South America) Sent by: ietf-boun...@ietf.org James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. complete. I know how much pressure there is on the working groups to keep up with things actually happening in the browsers and organisations setting up to use this technology. Do you think the retrofit will be problematic, and do you have a specific suggestion about what should be included today? Jari
[Isoc-br] IETF Meeting in South America
Dear IETF Managers, My name is Rogério Mariano and I`m a member of the Internet Society (Global Member # 339380) and a student of Internet Governance Programme (IGCBP) DiploFoundation and Consultant for the definition and operation of the Service Provider direction related to the technical architecture of Routing Protocols and Core Infrastructure components in the Petrobras Oil company (largest company in Brazil). Over 14 years of management experience working and leading a group of engineers engaged in a variety of projects and operations spanning areas such as MPLS, routing, Internet and services. Active participant in standards bodies and industry forums such as ISOC, IETF, NIC.br and GTER. About IETF in LATAM We feel really miss the action of engineers and professionals in Latin America within the IETF to improve the quality of the Internet in Latin America and spread its use, with special attention to its technical and infrastructure. For these issues is very important to have a performance of the IETF in Latin America, since we already have strong groups like LACNIC, the ISOC.br the NIC.br and meetings as well as the products GTER the LACNOG events and chapters ISOC. I think there are people in Latin America who can encourage and contribute in various aspects such as: infrastructure and standardization / standardization and standards for various segments mainly as a BOF or WG in the IETF. Regards, Rogério Mariano de Souza + 55 21 8314-9647
Re: Re: More participation from under-represented regions (was: IETF Meeting in South America)
I support to try the new meeting sites such as South America or Africa. Jiankang Yao From: Abdussalam Baryun Date: 2013-05-27 07:38 To: SM CC: ietf; dcrocker Subject: Re: More participation from under-represented regions (was: IETF Meeting in South America) I support to add the new region, hoping in future Africa gets its chance. IMO, I thought about it from another point of view. After a long time of having IETF meetings mostly in one region (as history of North America region gaining most meetings), the result of that was that IETF participants are majority from North America, so I think it MAY be a result of meetings held in one region (some will argue it is because experts individual-participants/company-participants come from North America, while giving no value of IETF marketing), However, IETF claims it is for the WORLD as Internet is, not for only one region's Internet. So giving now chance for other regions (or diverse Internet communities) to gain meetings will help in the FUTURE more participants from other regions as it happend to North America. For IETF it already gained many from North america, and they don't increase so it SHOULD market elsewhere for future plans. My answers to your questions below, AB On 5/26/13, SM s...@resistor.net wrote: At 09:42 26-05-2013, Dave Crocker wrote: I like visiting South America. But IETF meetings do not have tourism as a goal. So yes, I'm sure those who go will enjoy the city; but again, that's not stated purpose of choosing venues. Over a year ago the IAOC [was] pleased to announce the Return of the Nerds to Paradise! If we are serious about wanting more participation from under-represented regions, then let's attack that issue seriously and substantively, rather than with an expensive marketing show. Yes. The meaning of the elephant in the room is an important and obvious topic, which everyone present is aware of, but which isn't discussed, as such discussion is considered to be uncomfortable. The elephant in the room is that there hasn't been any discussion about what has been done to get more participation from under-represented regions but nobody has mentioned that. (a) Was the IESG working on how to get more participation from under-represented regions? I think they SHOULD have, and all of us should do the same, because IETF will expand and become stronger by increasing participants from ALL Internet community regions. The answers also based on IETF vesion. (b) Was the IAB working on how to get more participation from under-represented regions? I think they SHOULD have, and all of us should do the same, because IETF will expand and become stronger by increasing participants from ALL Internet community regions. The answers also based on IETF vesion. I am asking the above questions as it is not clear who in the IETF was doing that. I am working on it my self, so I hope others think the same, I have asked many students about the IETF, they don't know about it a thing, so should n't we ask question why the community of Internet users in South America not participating? One answer can be that the reason is that IETF participants majority from North America and they don't want to spend money on long journies that include many competing regions (e.g. few regions or few long distance per year maybe fine). Regards, -sm
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi, I think those comments have been addressed/answered in my previous reply http://www.ietf.org/mail-archive/web/manet/current/msg15274.html I didn't see the support of your comments from other WG participants. best Jiazi 2013/5/27 Abdussalam Baryun abdussalambar...@gmail.com Reply to your request dated 24/05/2013 Draft Reviewed By: Abdussalam Baryun (AB)Dated:27/05/2013 Reviewer Comment A1: Previous comments in WGLC +++ Related to your request below please read my previous review comments [1] and I will continue with additional messages/comments. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15254.html Regards AB On 5/24/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: Participation per Region of Authoring IETF documents vs Marketing
Rather than saying someone should do this on the list, you could, you know, do the work. A -- Andrew Sullivan Please excuse my clumbsy thums. On 2013-05-27, at 9:31, Abdussalam Baryun abdussalambar...@gmail.com wrote: On 5/27/13, Eggert, Lars l...@netapp.com wrote: On May 27, 2013, at 12:10, Abdussalam Baryun abdussalambar...@gmail.com wrote: Each IETF document mentions the authors place address (I may suggest adding region, as a categorised by IETF), but not sure of history statistics of how many IETF-documents produced by authors in South America, Africa, or Asia, or others. http://www.arkko.com/tools/stats/d-countrydistr.html and related pages I read that before, but does not show documents/RFCs per region. It shows drafts per countries. For example, does not show the drafts from South America. Does not show all regions in sequence of the most participated region. AB
Re: IETF Meeting in South America
The IETF has a big problem, IMHO, in that effective participation really does currently seem to require meeting attendance. There's a reason that nomcom members have to show up—if they didn't, they wouldn't be part of the actual culture of IETF, because so much IETF culture is bound up in the physical meetings. The interaction we get in the physical meetings is really important. I think this is going to be difficult to change unless we let robots do the work. The social part is an important component for cooperative work. Probably, this lack of social interaction in our region is one of the main reasons for low participation. Most of latin american IETFers are currently living outside the region and they engaged in the IETF when living in the US or Europe. It's difficult to be involved when no one else around is working in it or think it doesn't fit well in their current work. A physical meeting will help to demystify the IETF, making it accesible from a professional perspective. Christian I would very much like to see the IETF try to discover new ways of using the technology our forebears (and some remaining senior participants) invented to achieve the same effectiveness without requiring us to all burn tons of fuel getting to remote corners of the globe. But achieve the same effectiveness is an important requirement for any such new solution. And right now we don't have a solution like that, so we do what we do, and you are right that that means that effective participation in the IETF is much easier for people who are able to attend at least a sufficiency of meetings on an ongoing basis. We should see this as a starting point, not as an end state.
Re: When to adopt a WG I-D
On 2013-05-28 13:09, Romascanu, Dan (Dan) wrote: Hi, Good work. Here are a few thoughts after a first reading. - We seem not to have a definition of what a WG I-D is, although we know how to recognize a WG I-D because of the naming convention. So, if I am not mistaken the phrase Working Group drafts are documents that are subject to IETF Working Group revision control. in section 1.1 introduces such a definition. Is everybody happy with this? No not really - first it is not a definition - it is something that follow from that the document is a wg document. I guess the following is closer to a definition: A working group document is any document that the working group chairs says is a working group document. The revision control follows from that, but is nevertheless necessary. /Loa - I am lacking from the criteria in 2.2 the stability of the technical solution (as per WG consensus). In my mind this is in current practice the principal specific difference between individual submission I-Ds and WG I-Ds - the fact that the I-D makes a clear (it may be drafty but yet clear) statement about what the technical solution is. - I less like the following: * If not already in scope, is a simple modification to the charter feasible and warranted? Without being extremely strict on the process aspect, I believe that WGs should not work on items that are not chartered, and even less adopt WG I-Ds on non-chartered items. If they feel that something is missing from the charter they can ask the ADs for a charter update, or for adding milestones, we have today at hand light processes which can lead to fast incremental additions to charters, and if the addition is more than incremental than it should go through a proper rechartering process. - * What is the position of the working group chairs, concerning the draft? [[editor note: I am not sure this is relevant. Indeed is might be specifically not relevant. /a]] Not relevant IMO. Regards, Dan -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, May 28, 2013 12:33 PM To: ietf@ietf.org Subject: When to adopt a WG I-D Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: When to adopt a WG I-D
It is difficult to read, because I am expecting a process and find something else, I started to read, but got confused (stoped reading), why you are titling it as creating WG-draft and mentioning the adoption into the document. I understand that the creating first is *individual-draft* not *WG-draft*, the adoption happens after the creation of individual draft. If creating is WG creation, then it is already adopted as *idea* not *draft*, and then draft-00 is the WG-draft. I don't see the process clear at all, I maybe missing something, AB On Tue, May 28, 2013 at 10:32 AM, Adrian Farrel adr...@olddog.co.uk wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
Re: When to adopt a WG I-D
On 28/05/2013 15:36, Abdussalam Baryun wrote: It is difficult to read, because I am expecting a process and find something else, I started to read, but got confused (stoped reading), why you are titling it as creating WG-draft and mentioning the adoption into the document. I understand that the creating first is *individual-draft* not *WG-draft*, Incorrect, the first incarnation of a draft can be a WG draft. The only requirement is that the chairs conclude that the existence such a draft has WG consensus. the adoption happens after the creation of individual draft. If creating is WG creation, then it is already adopted as *idea* not *draft*, and then draft-00 is the WG-draft. I don't see the process clear at all, I maybe missing something, Yes you are. Stewart AB On Tue, May 28, 2013 at 10:32 AM, Adrian Farrel adr...@olddog.co.uk mailto:adr...@olddog.co.uk wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: When to adopt a WG I-D
Adrian, I'm fine with this draft as long as it stays informational and is viewed as a commentary on how what we are doing in the border land between individual and formal working group documents, i.e. this is not an IETF process text. Names of ID file are a bit trickier than what I get from this draft It is true that a document with a file name as: draft-wgname-ietf-... uniquely is a working group document; you need the approval of the wg chair(s) to have a draft with that file name posted. However, a draft with the file name: draft-individual-ietf... may or may not be wg document, and it is actually so when the the working group chairs states on the wg mailing list that it is. Admittedly this is often followed by a request to re-post it with the common format of file names for wg documents, but it is not the posting with the wg name format that makes it a wg document, it is the announcement from wg chairs. It is nowhere required to change the file name just because the document has become a working group document. Stupid not to do it, but not required. For example the appsawg does have two parked *wg documents* that does not follow the naming convention above. Now in section 5.1. you talk about a special case documents supported by a working, but that remains an individual draft but progress according to the wg processes. I think that what is now RFC 3468 was such a case; even though we at that did not talk about in those terms. I think it would be clearer if you in section 5.1. just said that there might be individual documents that is supported by a working group, and that follows the naming conventions for individual documents. /Loa On 2013-05-28 11:32, Adrian Farrel wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: financial fun with an IETF Meeting in South America
On 05/27/2013 07:31 AM, Juliao Braga wrote: According to the news published for a long time in Brazilian newspapers and magazines, Buenos Aires (a wonderful place!) would not be recommended. Recommended for what? And on what basis? Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: financial fun with an IETF Meeting in South America
Jorge, On 05/27/2013 08:16 AM, Jorge Amodio wrote: I feel that is totally OT but for example we have supporters of the current government like this one, claiming to be a writer, that if you are able to read in Spanish or helped by a translator to read his article, you will learn that he is propagating a message that says Internet is the secret weapon of the imperialism. http://sumateacristina.net/m/blogpost?id=6438092%3ABlogPost%3A524963 I'm currently off-line at the moment, and hence cannot read the aforementioned article. I would just say that lots of crap gets posted on the Internet. I'd also say that I've never heard anyone making that sort of statement. For instance, the argentinan government itself has a program to increase Internet connectivity throughout the country -- which should be more of a datapoint that the aforementioned article should be taken as a post by some random idiot (assuming he says what you say he is saying). His view is shared by many, so in the event IETF gets to meet in Buenos Aires, if the meeting becomes public, don't be surprised to see some coordinated political manifestation. I live in Buenos Aires, and have never ever heard about such message about the internet being a weapon of imperialism. For instance, left-wing parties (which are the ones usually talking about imperialism) tend to use the Internet a lot, since it provides a cheap way of communication when compared to other means (printed media, or whatever). So, me, I couldn't even imagine such a manifestation. Besides, I doubt anyone considers us (IETF) as important to be the target of a manifestation. I don't think it's productive to alarm people this way. Particularly without any concrete data. Note: I'm not not even touching the issue of whether having a meeting in Buenos Aires is a great idea or not.. but just trying to keep the discussion objective. Un abrazo, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: financial fun with an IETF Meeting in South America
Hi, Tim, On 05/27/2013 09:19 AM, Tim Chown wrote: The move appears to be related to new, restrictive regulations the Argentine government has imposed on currency exchanges.' According to the Telegraph, 'The new regulations required anyone wanting to change Argentine pesos into another currency to submit an online request for permission to AFIP, the Argentine equivalent of HM Revenue Customs. ... This isn't likely to change soon. Going into the country isn't the problem, more importantly it seems that if you don't spend all your pesos in Argentina, you can't change them back to your own currency: http://www.tripadvisor.co.uk/Travel-g294266-s601/Argentina:Banks.And.Money.html (see last paragraph) I'm currently off-line, and hance cannot read the article right now. But I should say that the last time that I checked, it was possible to change the excess pesos back to your original currency, provided you kept the original receipt that proved that those excess pesos correspond to money you had in your original currency. But I could double-check if interested. That said, man shops accept dollars and euros (not pounds, though :-( ). So I guess that for the most part you could just have some small amount of money in pesos (mostly to pay cabs, I'd say), and move around the city using your credit card (or, if needed, USD or Euros) Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Tuesday, May 28, 2013 20:58 +0900 Randy Bush ra...@psg.com wrote: What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. there are two solutions to this Probably more than two if your comment indicates that you agree that having registered RRTYPEs documented is, on balance, better than not having them documented: (1) We can continue along the path of Informational RFC publication in the IETF Stream (2) Joe could have submitted the document to the ISE and requested Informational RFC publication in the Independent stream. (3) Joe could post the definitional document on a web site somewhere that could provide a stable reference and then ask IANA to incorporate that reference, presumably in URL form, rather than the name of an I-D in the registry. If this is a Canadian initiative, perhaps the Canadian government would like to provide that location and reference but, clearly, there are other alternatives. Did you have something else in mind? I think the advantage of the first over the other two is that it promotes a level of review in the community that, a least IMO, had improved the document and, if we need revisit how RRTYPEs are allocated, to provide a concrete basis for that discussion. Once an RFC is published, the broader community is unlikely to be able to tell the difference between the first and second although, if we think the second would be better, it suggests another option for the longer term: (4) Create an IANA Stream for the RFC Editor through which we can publish documents that describe protocol parameters that are registered through lightweight methods and assure stable references for them, with no approval beyond that required to accomplish the registration. If such a stream retained the requirement to post as an I-D (and conformance to the IETF's IPR rules), there would still be as much or more opportunity for community pre-publication review and feedback to the author and expert reviewers than the independent stream affords. I have no idea whether that would be a good idea or not and it would certainly be too long-term to affect this document, but it is possible. Of course, (5), we could retroactively change the registration procedure and retroactively deprecate these types. That might avoid the need to write the Applicability Statement I-D that I mentioned but, if my reading of trends in the IESG is correct, I have my doubts. What, actually, would you propose other than continuing to complain about the RRTYPEs themselves and what they are intended to support (which, in case it hasn't been clear, I largely agree with you about). best, john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. there are two solutions to this Probably more than two if your comment indicates that you agree that having registered RRTYPEs documented is, on balance, better than not having them documented: (1) We can continue along the path of Informational RFC publication in the IETF Stream (2) Joe could have submitted the document to the ISE and requested Informational RFC publication in the Independent stream. (3) Joe could post the definitional document on a web site somewhere that could provide a stable reference and then ask IANA to incorporate that reference, presumably in URL form, rather than the name of an I-D in the registry. If this is a Canadian initiative, perhaps the Canadian government would like to provide that location and reference but, clearly, there are other alternatives. Did you have something else in mind? remove the rrtypes from the registry
Re: financial fun with an IETF Meeting in South America
Hi Fernando, Please, read my sentence complementary to comment: ...But who should tell us about the true cenary would be our Argentine friends. Regards, Julião Em 28/05/2013 10:36, Fernando Gont escreveu: On 05/27/2013 07:31 AM, Juliao Braga wrote: According to the news published for a long time in Brazilian newspapers and magazines, Buenos Aires (a wonderful place!) would not be recommended. Recommended for what? And on what basis? Cheers,
Re: When to adopt a WG I-D
On 5/28/2013 10:52 AM, Stewart Bryant wrote: ... The only requirement is that the chairs conclude that the existence such a draft has WG consensus. ... Strictly speaking, I believe the only requirement for a document to be published as a WG document is that a WG chair approves it. I do agree/think there are many practical restrictions, notably charter WG support. WRT to the I-D: the text in section 2.4 that says the chairs need to... can mislead some to believe that this is the required process. I think the the chairs typically... would be more accurate. Lou
Re: When to adopt a WG I-D
In reading through the draft, particularly the section on questions for WG adoption of a draft, I did not see the questions I consider most pertinent: Does the WG think this is a reasonable (preferably good) basis for starting to work collectively on the deliverable? (Apologies if it was there and I missed it.) Another question many WGs have found useful is: Are there enough people interested and willing to write and / or review the document? This is not the same as WG support for the document. Yours, Joel PS: The chairs opinion on the technical content of the document ought to be irrelevant as far as I can tell. On the other hand, detecting and raising concerns if the document is badly written is probably part of the chair's job. On 5/28/2013 5:32 AM, Adrian Farrel wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
Re: When to adopt a WG I-D
there is also the not uncommon event where an idea starts as an individual idea, moves into a WG, is rejected by the WG, becomes an individual idea, is picked up by another WG, rejected, (lather, rinse, repeat), and then the -right- WG is formed and it is processed that way. In the current state of affairs, at each name-change, the document counter is reset, particularly for IP challenges. and there is also Mr. Bush's dispensation to use neither WG or name in his drafts… he gets to use YMBK Naming of IDs, while important, is not an accurate reflection of the growth and evolution of an idea in the IETF context. /bill On 28May2013Tuesday, at 7:59, Loa Andersson wrote: Adrian, I'm fine with this draft as long as it stays informational and is viewed as a commentary on how what we are doing in the border land between individual and formal working group documents, i.e. this is not an IETF process text. Names of ID file are a bit trickier than what I get from this draft It is true that a document with a file name as: draft-wgname-ietf-... uniquely is a working group document; you need the approval of the wg chair(s) to have a draft with that file name posted. However, a draft with the file name: draft-individual-ietf... may or may not be wg document, and it is actually so when the the working group chairs states on the wg mailing list that it is. Admittedly this is often followed by a request to re-post it with the common format of file names for wg documents, but it is not the posting with the wg name format that makes it a wg document, it is the announcement from wg chairs. It is nowhere required to change the file name just because the document has become a working group document. Stupid not to do it, but not required. For example the appsawg does have two parked *wg documents* that does not follow the naming convention above. Now in section 5.1. you talk about a special case documents supported by a working, but that remains an individual draft but progress according to the wg processes. I think that what is now RFC 3468 was such a case; even though we at that did not talk about in those terms. I think it would be clearer if you in section 5.1. just said that there might be individual documents that is supported by a working group, and that follows the naming conventions for individual documents. /Loa On 2013-05-28 11:32, Adrian Farrel wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 5/28/13 8:18 AM, Randy Bush wrote: What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. there are two solutions to this Probably more than two if your comment indicates that you agree that having registered RRTYPEs documented is, on balance, better than not having them documented: (1) We can continue along the path of Informational RFC publication in the IETF Stream (2) Joe could have submitted the document to the ISE and requested Informational RFC publication in the Independent stream. (3) Joe could post the definitional document on a web site somewhere that could provide a stable reference and then ask IANA to incorporate that reference, presumably in URL form, rather than the name of an I-D in the registry. If this is a Canadian initiative, perhaps the Canadian government would like to provide that location and reference but, clearly, there are other alternatives. Did you have something else in mind? remove the rrtypes from the registry Unless you're proposing that we change the operation of the registry that seems a bit out of scope.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On Wed, May 29, 2013 at 12:18:40AM +0900, Randy Bush wrote: remove the rrtypes from the registry While it's good to see that the Internet Exemplary Taste-enForcers are alive and well, I would have an extremely strong objection to that approach. The DNS Extensions Working Group published an IANA Considerations document that was explicitly designed to permit registrations, and this is an example of that procedure working. If people had objections to that permissiveness, they didn't express them when the then-to-be-RFC6895 was last called. We have shipping implementations of DNS software that are using those code points. Removing the types from the registry does absolutely nothing for interoperation, doesn't actually help any of the privacy concerns that are being raised, doesn't solve anyone's problem, and sets up the registry as a crypto-normative repository -- a state of affairs that several people objected to when we tried to do this explicitly (I still bear the scars from that lashing). I am tired of the self-appointed Internet Cops attempting to regulate the taste of people wanting to use the DNS. If people don't like the allocation policy for DNS RRTYPEs, then they are free to spin up a new DNSTASTE WG and get the policy changed. I will attend the BoF and blow raspberries. But I look forward to the bright future in which the DNS contains only TXT records, which we retrieve via port 80 or (if lucky) port 443. A -- Andrew Sullivan a...@anvilwalrusden.com
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
On Sat, May 25, 2013 at 12:10 AM, Jari Arkko jari.ar...@piuha.net wrote: James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. complete. I know how much pressure there is on the working groups to keep up with things actually happening in the browsers and organisations setting up to use this technology. Do you think the retrofit will be problematic, and do you have a specific suggestion about what should be included today? Jari I'm replying here, rather than down thread, because I believe it's important to tackle two different statements here: one James' and one Jari's. The first is James' that RTCWEB is ignoring Emergency Services. Perhaps by actively ignoring James means that the working group considered emergency services and made a decision he did not agree with, which is that the baseline capabilities already allows a PSAP or other emergency service to provide a WebRTC application that would work to connect you to its emergency responders, and that this was enough. As context, it's very important to recognize that the WebRTC efforts in the IETF and W3C *are not building a telephone into a browser*. We could have done that in a few weeks. The groups *are* creating building blocks that allow a javascript application within a browser or mobile context to add peer-to-peer audio, video, or data channels to whatever *its* application happens to be. That application can be a game (we often use a poker game as an example here), a puzzle (there's an example where you compete with a peer in unscrambling a tiled video feed), or a pure data exchange (where neither audio or video are passed). In that context, the group considered two questions: can you use the WebRTC building blocks to create an application to talk to emergency responders? should every application be required to have the ability to talk to emergency responders? It gave the answer to the first one as yes, and I am convinced that any emergency responder that wished to create such an application could do so with the existing building blocks. A set of emergency responders could even create and distribute one that was highly generalized and took advantage of LoST's facilities to be useful in many locations. To the second question, the working group answered no. There are applications of WebRTC which are not general-purpose communications, including some applications where there will be no audio or video at all. Requiring that a puzzle should provide you 911 service because it happens to provide have live video is not really sensible. Fundamentally, making every application also be a generalized telephony application with ECRIT support makes no more sense here than it would for desktop applications; you could equally require a text processor connected to the network to support texting emergency responders--after all, it has the UI facilities and the user's attention, right? The second statement is Jari's, which seems to imply that the implementations coming out before standards is a problem in the WebRTC case. The implementers in this case are also very active contributors to both the IETF and W3C efforts, and they are feeding implementation experience into the process. That's a good thing, since it is coming along with a willingness to change implementations to match group consensus. That won't last forever, obviously, but we have that now and should continue to take advantage of it while we do. That's my personal take, in any case, as someone who has been actively involved in both efforts. regards, Ted Hardie
Re: IETF Meeting in South America
On 5/28/13 6:20 AM, Christian O'Flaherty wrote: Probably, this lack of social interaction in our region is one of the main reasons for low participation. Most of latin american IETFers are currently living outside the region and they engaged in the IETF when living in the US or Europe. It's difficult to be involved when no one else around is working in it or think it doesn't fit well in their current work. A physical meeting will help to demystify the IETF, making it accesible from a professional perspective. Any sense of why that didn't happen with Australians after the Adelaide meeting? I'm not opposed to meeting in South America but there have been an awful lot of assertions about this or that happening if we do, without a lot of supporting evidence. History, unfortunately, doesn't support many of these assertions, and I think beating the meeting location question to death is at least some small distraction from trying to get at the core issues. For whatever it's worth, I was participating on IETF mailing lists well before attending a meeting. Granted, I'm a native English speaker and wasn't dealing with that as an issue but probably more to the point was that there was work going on in the IETF that directly impacted work I was doing myself. Melinda
Re: IETF Meeting in South America
On 5/23/13 8:02 PM, David Conrad wrote: On May 23, 2013, at 7:44 PM, Melinda Shore melinda.sh...@gmail.com wrote: So the question is why we aren't seeing more drafts, reviews, and discussions from people in Central and South America, Language? It would seem likely when the participation is heaviliy biased towards equipment vendors and software tooling that the participants would be more representative of where the concentration of the development sideo of that work occurs. Comparative advantage isn't just the domain of agricultural products, extractive industries, and low-cost manufacturing. That seems likely to be part and parcel of the diversity discussion.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi Joe, At 03:12 28-05-2013, Joe Abley wrote: Note that there's no suggestion that these RRTypes are required by the CRTC. The example given was for a situation where Interop would have been beneficial (so that cable resellers have an obvious, stable and supported way of encoding this kind of information. Ok. The opposite actually: cable operators are required to provide access to subscribers on behalf of third parties in order to promote competition. There are multiple such cable providers and multiple such resellers. Yes. (TekSavvy is one such reseller of multiple cable companies' access networks.) Ok. Feel free to point out the gaps, and/or to suggest text. I'll give it a try. I suggest talking to the Area Director to see what's workable. I would drop Section 6 of the draft as I no longer need a use case to get an RRTYPE assignment. There is a typo for RRTPES in Section 7. I would start Section 9 with There are privacy concerns I would replace the third paragraph with: The user should be provided with a disclosure statement that clearly mentions: - How the EUI addresses published in DNS will be used and protected - What privacy policies are applicable The disclosure statement is to enable the user to make an informed decision about whether the disclosure of the information is acceptable considering local laws and customs. I would rename Section 9 as Privacy Considerations. I don't know what to put in the new Security Considerations section. Maybe Publishing EUI addresses in DNS lowers the security of the Internet. Regards, -sm
Re: financial fun with an IETF Meeting in South America
Julio, I'm worried about people making statements on a random basis. I assume that many people (IAOC and many others) have made a lot of effort before getting to the point of formally proposing/suggesting to have an IETF meeting in Buenos Aires. I bet much of that effort had to do with making an informed decision on the subject. However, so far I've read a number of rather uninformed claims about how bad/not_recommended having an IETF meeting in Buenos Aires would be (besides the usual discussion of whether meeting should be held where most of the participants come from, which is a different issue). IMO, throwing out random comments (arbitrary, or based on what one heard, etc.) tends to bias the discussion in an inappropriate way. Thanks, Fernando On 05/28/2013 05:19 PM, Juliao Braga wrote: Hi Fernando, Please, read my sentence complementary to comment: ...But who should tell us about the true cenary would be our Argentine friends. Regards, Julião Em 28/05/2013 10:36, Fernando Gont escreveu: On 05/27/2013 07:31 AM, Juliao Braga wrote: According to the news published for a long time in Brazilian newspapers and magazines, Buenos Aires (a wonderful place!) would not be recommended. Recommended for what? And on what basis? Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 5/28/13 9:41 AM, SM wrote: Hi Joe, At 03:12 28-05-2013, Joe Abley wrote: Note that there's no suggestion that these RRTypes are required by the CRTC. The example given was for a situation where Interop would have been beneficial (so that cable resellers have an obvious, stable and supported way of encoding this kind of information. Ok. The opposite actually: cable operators are required to provide access to subscribers on behalf of third parties in order to promote competition. There are multiple such cable providers and multiple such resellers. Yes. (TekSavvy is one such reseller of multiple cable companies' access networks.) Ok. Feel free to point out the gaps, and/or to suggest text. I'll give it a try. I suggest talking to the Area Director to see what's workable. I would drop Section 6 of the draft as I no longer need a use case to get an RRTYPE assignment. There is a typo for RRTPES in Section 7. I would start Section 9 with There are privacy concerns I would replace the third paragraph with: For some background. The usecase facilitates discussion and justification of the draft. It is not about justifying the RRtype (which was assigned under the rules of that registry). It's in there because the sponsoring AD requested it after feedback during the dnsext dicussion. The user should be provided with a disclosure statement that clearly mentions: - How the EUI addresses published in DNS will be used and protected - What privacy policies are applicable The disclosure statement is to enable the user to make an informed decision about whether the disclosure of the information is acceptable considering local laws and customs. I would rename Section 9 as Privacy Considerations. I don't know what to put in the new Security Considerations section. Maybe Publishing EUI addresses in DNS lowers the security of the Internet. Regards, -sm
Re: financial fun with an IETF Meeting in South America
The bad things that happen in Argentina financially affect only Argentinians. I'm not saying this is a good thing overall, just saying that this isn't a problem for tourists and certainly won't be a problem for IETFers. Probably these financial 'issues' will even affect positively the conference's bottom line, as everything is very cheap when priced in dollars. If you take a stroll through downtown Buenos Aires today, you'll listen to many different languages. The place is packed with foreigners, as the food is great, the city is very nice and everything appears very cheap. cheers! ~Carlos On 5/28/13 10:36 AM, Fernando Gont wrote: On 05/27/2013 07:31 AM, Juliao Braga wrote: According to the news published for a long time in Brazilian newspapers and magazines, Buenos Aires (a wonderful place!) would not be recommended. Recommended for what? And on what basis? Cheers,
Re: When to adopt a WG I-D
On 5/28/2013 10:22 AM, Joel M. Halpern wrote: In reading through the draft, particularly the section on questions for WG adoption of a draft, I did not see the questions I consider most pertinent: I appreciate Dave and Adrian for producing this helpful start, and I'm mostly comfortable with where this conversation has gone since Adrian asked for feedback on this list. I wanted specifically to echo Joel's suggestions for additional questions. Does the WG think this is a reasonable (preferably good) basis for starting to work collectively on the deliverable? I read this as is this stable enough for a working group to work on it, or might we still want to tell some small number of people to go off in a corner and try again to produce something that IS a reasonable basis? I agree. To the extent that a working group really does control the contents of a working group draft, if the working group doesn't agree that the draft is a reasonable basis, making consensus calls about massive rewrites seems more painful than we are hoping for. Another question many WGs have found useful is: Are there enough people interested and willing to write and / or review the document? Exactly. We should work on working group drafts. If a working group doesn't have the resources and willingness to work on the document, I'm not sure how much sense it makes to adopt it as a draft that's being officially ignored by the working group :-) Spencer
Re: Participation per Region of Authoring IETF documents vs Marketing
by looking into the statistics of I-Ds and RFCs, it is strange that we get sometimes high rate in the I-D going in IETF from some regions but the success rate of I-Ds to become RFCs is very low (5- 50). So the only region that is producing RFCs with high rate (about 200 per year) is North America even though there is a high rate of I-Ds created. No sure Why is that result, or waste of efforts, or maybe I misunderstood the figures, How many I-Ds per year of Asia-region are adopted by IETF WGs? How many I-Ds per year of Europe-region are adopted by IETF WGs? AB On Mon, May 27, 2013 at 4:46 PM, Eggert, Lars l...@netapp.com wrote: On May 27, 2013, at 15:31, Abdussalam Baryun abdussalambar...@gmail.com wrote: On 5/27/13, Eggert, Lars l...@netapp.com wrote: On May 27, 2013, at 12:10, Abdussalam Baryun abdussalambar...@gmail.com wrote: Each IETF document mentions the authors place address (I may suggest adding region, as a categorised by IETF), but not sure of history statistics of how many IETF-documents produced by authors in South America, Africa, or Asia, or others. http://www.arkko.com/tools/stats/d-countrydistr.html and related pages I read that before, but does not show documents/RFCs per region. It shows drafts per countries. For example, does not show the drafts from South America. Does not show all regions in sequence of the most participated region. That's why I wrote *and related pages*. Clicking around Jari's pages, you will easily find http://www.arkko.com/tools/rfcstats/d-contdistr.html as well as many more stats. As for most participated region, look at the reports from the IAOC: http://iaoc.ietf.org/reports.html Lars
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
At 11:58 AM 5/28/2013, Ted Hardie wrote: On Sat, May 25, 2013 at 12:10 AM, Jari Arkko mailto:jari.ar...@piuha.netjari.ar...@piuha.net wrote: James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. complete. I know how much pressure there is on the working groups to keep up with things actually happening in the browsers and organisations setting up to use this technology. Do you think the retrofit will be problematic, and do you have a specific suggestion about what should be included today? Jari I'm replying here, rather than down thread, because I believe it's important to tackle two different statements here: one James' and one Jari's. The first is James' that RTCWEB is ignoring Emergency Services. Perhaps by actively ignoring James means that the working group considered emergency services and made a decision he did not agree with, which is that the baseline capabilities already allows a PSAP or other emergency service to provide a WebRTC application that would work to connect you to its emergency responders, and that this was enough. As context, it's very important to recognize that the WebRTC efforts in the IETF and W3C *are not building a telephone into a browser*. We could have done that in a few weeks. The groups *are* creating building blocks that allow a javascript application within a browser or mobile context to add peer-to-peer audio, video, or data channels to whatever *its* application happens to be. That application can be a game (we often use a poker game as an example here), a puzzle (there's an example where you compete with a peer in unscrambling a tiled video feed), or a pure data exchange (where neither audio or video are passed). In that context, the group considered two questions: can you use the WebRTC building blocks to create an application to talk to emergency responders? should every application be required to have the ability to talk to emergency responders? It gave the answer to the first one as yes, and I am convinced that any emergency responder that wished to create such an application could do so with the existing building blocks. A set of emergency responders could even create and distribute one that was highly generalized and took advantage of LoST's facilities to be useful in many locations. To the second question, the working group answered no. There are applications of WebRTC which are not general-purpose communications, including some applications where there will be no audio or video at all. Requiring that a puzzle should provide you 911 service because it happens to provide have live video is not really sensible. Fundamentally, making every application also be a generalized telephony application with ECRIT support makes no more sense here than it would for desktop applications; you could equally require a text processor connected to the network to support texting emergency responders--after all, it has the UI facilities and the user's attention, right? The second statement is Jari's, which seems to imply that the implementations coming out before standards is a problem in the WebRTC case. The implementers in this case are also very active contributors to both the IETF and W3C efforts, and they are feeding implementation experience into the process. That's a good thing, since it is coming along with a willingness to change implementations to match group consensus. That won't last forever, obviously, but we have that now and should continue to take advantage of it while we do. That's my personal take, in any case, as someone who has been actively involved in both efforts. Ted - this view (I believe) doesn't reconcile with the view stated by Henning's yesterday. (truth be told, it's hard
Re: financial fun with an IETF Meeting in South America
Dear Fernando, If I have to decide about a meeting in Buenos Aires based in the information that I read in the Brazilian newspapers and magazines I decide to no. By this reason I need to listen from Argentine people, as you. I believe this is the right way to decide. The choice of Buenos Aires is a definitive fact, and I have no decision concerns this selection. My approach was to reinforce the fact that only you, in Argentina can really guide us, if the decision were to be revoked. Buenos Aires was a beatiful choice! It was not an arbitrary comment. It was real and oriented so that any queries related to media reports, our people of Argentina should be heard. Therefore, you should have no doubt that I'm hoping to have a meeting of the IETF in Buenos Aires. Best regards, Julião Em 28/05/2013 14:13, Fernando Gont escreveu: Julio, I'm worried about people making statements on a random basis. I assume that many people (IAOC and many others) have made a lot of effort before getting to the point of formally proposing/suggesting to have an IETF meeting in Buenos Aires. I bet much of that effort had to do with making an informed decision on the subject. However, so far I've read a number of rather uninformed claims about how bad/not_recommended having an IETF meeting in Buenos Aires would be (besides the usual discussion of whether meeting should be held where most of the participants come from, which is a different issue). IMO, throwing out random comments (arbitrary, or based on what one heard, etc.) tends to bias the discussion in an inappropriate way. Thanks, Fernando
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
I would suggest we not try to sort out on this list which sorts of Internet services are subject to American regulations. On Tue, May 28, 2013 at 2:20 PM, James Polk jmp...@cisco.com wrote: At 11:58 AM 5/28/2013, Ted Hardie wrote: On Sat, May 25, 2013 at 12:10 AM, Jari Arkko mailto: jari.ar...@piuha.net**jari.ar...@piuha.net jari.ar...@piuha.net wrote: James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. complete. I know how much pressure there is on the working groups to keep up with things actually happening in the browsers and organisations setting up to use this technology. Do you think the retrofit will be problematic, and do you have a specific suggestion about what should be included today? Jari I'm replying here, rather than down thread, because I believe it's important to tackle two different statements here: one James' and one Jari's. The first is James' that RTCWEB is ignoring Emergency Services. Perhaps by actively ignoring James means that the working group considered emergency services and made a decision he did not agree with, which is that the baseline capabilities already allows a PSAP or other emergency service to provide a WebRTC application that would work to connect you to its emergency responders, and that this was enough. As context, it's very important to recognize that the WebRTC efforts in the IETF and W3C *are not building a telephone into a browser*. We could have done that in a few weeks. The groups *are* creating building blocks that allow a javascript application within a browser or mobile context to add peer-to-peer audio, video, or data channels to whatever *its* application happens to be. That application can be a game (we often use a poker game as an example here), a puzzle (there's an example where you compete with a peer in unscrambling a tiled video feed), or a pure data exchange (where neither audio or video are passed). In that context, the group considered two questions: can you use the WebRTC building blocks to create an application to talk to emergency responders? should every application be required to have the ability to talk to emergency responders? It gave the answer to the first one as yes, and I am convinced that any emergency responder that wished to create such an application could do so with the existing building blocks. A set of emergency responders could even create and distribute one that was highly generalized and took advantage of LoST's facilities to be useful in many locations. To the second question, the working group answered no. There are applications of WebRTC which are not general-purpose communications, including some applications where there will be no audio or video at all. Requiring that a puzzle should provide you 911 service because it happens to provide have live video is not really sensible. Fundamentally, making every application also be a generalized telephony application with ECRIT support makes no more sense here than it would for desktop applications; you could equally require a text processor connected to the network to support texting emergency responders--after all, it has the UI facilities and the user's attention, right? The second statement is Jari's, which seems to imply that the implementations coming out before standards is a problem in the WebRTC case. The implementers in this case are also very active contributors to both the IETF and W3C efforts, and they are feeding implementation experience into the process. That's a good thing, since it is coming along with a willingness to change implementations to match group consensus. That won't last forever, obviously, but we have that now and should continue to take advantage of it while we do.
Re: [Isoc-br] IETF Meeting in South America
Dear Rogério Mariano, You have a great deal of experience. Since the mission of the IETF is to make the Internet better, could you point out specific problems that you would like to work on in the IETF? When you say infrastructure and standardization, that is very general. If there were an IETF meeting in your city, why would you come to the meeting? Can you give a specific example of a problem that would you like to work on? Thank you. Scott Brim
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
On May 28, 2013, at 11:25 AM, Richard Barnes r...@ipv.sx wrote: I would suggest we not try to sort out on this list which sorts of Internet services are subject to American regulations. Or those of any other jurisdiction. If jurisdiction Z comes to the IETF and says we have declared protocol A to be a service of type B, and we can think of harmless ways of making B more obvious in an extended version of A, that seems like potential work, possibly even for a WG but certainly for individual submission. But it should be done after A is done (assuming that A is extensible) and after Z has looked at A. --Paul Hoffman
Re: IETF Meeting in South America
On Tue, May 28, 2013 at 2:15 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 5/28/13 6:20 AM, Christian O'Flaherty wrote: Probably, this lack of social interaction in our region is one of the main reasons for low participation. Most of latin american IETFers are currently living outside the region and they engaged in the IETF when living in the US or Europe. It's difficult to be involved when no one else around is working in it or think it doesn't fit well in their current work. A physical meeting will help to demystify the IETF, making it accesible from a professional perspective. Any sense of why that didn't happen with Australians after the Adelaide meeting? If we're able to get a proportional growth similar to what happened in Australia it will be a success :-) Latam is a region with 600 million inhabitants compared to 23 million in Australia. But I agree with you and I'm not saying a meeting is going to be enough. In the past it was probably not combined with other activities planned two or three years in advance. We can do something serious here and we know the potential available in the region to empower the IETF even more. Christian I'm not opposed to meeting in South America but there have been an awful lot of assertions about this or that happening if we do, without a lot of supporting evidence. History, unfortunately, doesn't support many of these assertions, and I think beating the meeting location question to death is at least some small distraction from trying to get at the core issues. For whatever it's worth, I was participating on IETF mailing lists well before attending a meeting. Granted, I'm a native English speaker and wasn't dealing with that as an issue but probably more to the point was that there was work going on in the IETF that directly impacted work I was doing myself. Melinda
Re: IETF Meeting in South America
It would seem likely when the participation is heaviliy biased towards equipment vendors and software tooling that the participants would be more representative of where the concentration of the development sideo of that work occurs. This is true, but this is also something where active participants can help. Many of those companies also have RD groups in Latam but unfortunately they're not yet active in the IETF. This is probably for historical reasons but it's feasible to change. If you know in your companies, groups or individuals valuable enough to work in the IETF please reach them and help them (or let me know and I'll do it). Comparative advantage isn't just the domain of agricultural products, extractive industries, and low-cost manufacturing. That seems likely to be part and parcel of the diversity discussion. Latam is not just agriculture and cows :-)
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
On Tue, May 28, 2013 at 11:20 AM, James Polk jmp...@cisco.com wrote: Quoting Henning: At least in the US, many of the WebRTC services would be considered interconnected VoIP, so they are indeed subject to 911 obligations. James BTW- yeah, I know I'm picking a fight - but Jari singled this topic out as an example of how various regions of the world differ on how they handle certain applications, emergency services being one of a very short list he mentioned. I will agree with Richard that we shouldn't focus discussion on this list on the regulatory environment. But I think there's a piece of this that goes to the heart of what WebRTC can be, and that is whether the point is to create a new infrastructure that becomes part of interconnected VoIP or to create a set of building blocks that allows real-time communications without that infrastructure. I personally believe that is the latter, rather than the former, that is the promise of WebRTC. If I can make peer-to-peer, real time communications a part of any javascript application downloaded into a browser, I can create imbue those applications with a far richer environment. They can be social in ways that they are not now; they can be interactive in ways which they are not now; they can be creative in ways that they are not now (at least not without limiting the experience to those with specific plugins). Can you use that interactivity to create a telephone, which you then hook up to SIP islands or the PSTN via gateways? Sure, if that's what you want to do. But I don't think that's the major goal, and I have argued against a focus on that interoperability as a major driver of work in WebRTC. It looks shiny, as a way to get early users and quick deployment. But there's a lot of hooks attached to that lure, and I'd personally advise anyone developing for WebRTC to focus on native WebRTC apps. Those will be the ones that wow users and drive us forward. Again, just my personal view, Ted Hardie
Re: When to adopt a WG I-D
On 28/05/2013 21:32, Adrian Farrel wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? I haven't read the draft yet, and *before* I do so, I'd like to express some doubt whether we should even informally describe this using the word process. It seems to me that it's each WG's prerogative how it does this; it has no impact on the standards process as a whole. The word adopt doesn't even occur in RFC 2418, and it is not used in the context of WG adoption in RFC 2026. In other words, I don't think this action is part of the standards process. It's WG folklore. Brian How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt .
Re: financial fun with an IETF Meeting in South America
Julio, On 05/28/2013 08:20 PM, Juliao Braga wrote: If I have to decide about a meeting in Buenos Aires based in the information that I read in the Brazilian newspapers and magazines I decide to no. Could you please provide pointers to such articles? Additionally, could you please summarize what are your concerns, or what are the concerns expressed in the articles you've read? By this reason I need to listen from Argentine people, as you. I believe this is the right way to decide. The problem is that when comments are thrown out to a mailing-list without checking what's the information that is being spread, that ends up polluting and biasing the discussion unfairly and inappropriately. As a datapoint, Buenos Aires is *full* of brazillians these days -- I guess both because we're geographically near, but also because the exchange rate benefits brazillians (I haven't checked lately, but I'd bet that you can get most stuff for about 50% or 70% of the price of what you pay in Brazil). And I know of quite a few brazillians myself that have recently traveled to Argentina to attend meetings, and others that are planning to do so to attend meetings or conferences (Internet and/or security related) held in Buenos Aires. As noted in some other emails, I'm not even weighing in regarding the pro's and con's of having a meeting in Argentina, but rather pointing out that making public statements regarding based on what has been heard, rumors, or what some idiot posted on a blog pollutes and biases the discussion unfairly and inappropriately. Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: When to adopt a WG I-D
Hi, I have never been a wg chair but I think that this document may be very useful and helpful (at least it clarifies many things to me). I have some comments: - To me Section 2.1 (Formal Steps) looks better after 2.2 (Criteria of Adoption). - Section 2.2 does not set up a criteria. It just ask questions, it would be good to set basic criteria at least. - Section 2.2, The paragraph under REMINDER it is very important but I am not convinced 100% how you raised the attention to it (by using reminder) But I think that it is very important to point out this. - Section 3. Also not convinced about the NOTE, it would be better to me to include it as part of the text (similar to my comment of reminder of section 2.2. - There are some questions in different parts of the document, for example Shall it be adopted and entirely replace the current working group draft? Shall the new ideas be incorporated into the work of the working group through the normal editorial process? ... I am not sure the purpose of those, I imagine that they are helpful questions to ask, if so I suggest to add something like this to clarify Important questions that WG chairs should ask or consider are 'Shall it be adopted and entirely replace the current working group draft?'... Best regards, as On 5/28/13 6:32 AM, Adrian Farrel wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
Re: financial fun with an IETF Meeting in South America
Fernando, Please, read the Brazilian newspapers and magazines. I'm not looking for news from Argentina. I see them and / or read just the same way that I see or read others news, always an passant. This type of issue is not exactly my specialty or interest. But you can see a handful of recents news in the following locations, among others: http://www.veja.com.br http://revistaepoca.globo.com/ http://www.globo.com http://uol.com.br http://www.estadao.com.br or you can use Google, searching for Brazil or other contries news about Argentina. As I said to you, but it seems you do not understand, this is not a relevant question. For me and for many others the relevant question is your opinion. Carlos Martinez was precise and clear in your last post. Let us return to the subject that interests us, please. Although I do not have much time for this kind of debate, if you feel comfortable, send me email in private. Juliao Em 28/05/2013 16:06, Fernando Gont escreveu: Could you please provide pointers to such articles? Additionally, could you please summarize what are your concerns, or what are the concerns expressed in the articles you've read?
RE: IETF Meeting in South America
Any sense of why that didn't happen with Australians after the Adelaide meeting? The centres for networking industry in Australia are Melbourne and Sydney, in that order. It's a bit like IETF 51 being held in Grimsby, not London or Cambridge. Lloyd Wood http://sat-net.com/L.Wood
Re: financial fun with an IETF Meeting in South America
Juliao, I went to all this sites (besides BBC Brazil) and searched for Argentina. There were some news about economy, the lady President, some about the senate, commercial balance but none saying huu, scary Argentina, do not go there. Regards, as On 5/28/13 7:13 PM, Juliao Braga wrote: Fernando, Please, read the Brazilian newspapers and magazines. I'm not looking for news from Argentina. I see them and / or read just the same way that I see or read others news, always an passant. This type of issue is not exactly my specialty or interest. But you can see a handful of recents news in the following locations, among others: http://www.veja.com.br http://revistaepoca.globo.com/ http://www.globo.com http://uol.com.br http://www.estadao.com.br or you can use Google, searching for Brazil or other contries news about Argentina. As I said to you, but it seems you do not understand, this is not a relevant question. For me and for many others the relevant question is your opinion. Carlos Martinez was precise and clear in your last post. Let us return to the subject that interests us, please. Although I do not have much time for this kind of debate, if you feel comfortable, send me email in private. Juliao Em 28/05/2013 16:06, Fernando Gont escreveu: Could you please provide pointers to such articles? Additionally, could you please summarize what are your concerns, or what are the concerns expressed in the articles you've read?
Re: IETF Meeting in South America
On 5/28/13 11:56 AM, Christian O'Flaherty wrote: It would seem likely when the participation is heaviliy biased towards equipment vendors and software tooling that the participants would be more representative of where the concentration of the development sideo of that work occurs. This is true, but this is also something where active participants can help. Many of those companies also have RD groups in Latam but unfortunately they're not yet active in the IETF. This is probably for historical reasons but it's feasible to change. If you know in your companies, groups or individuals valuable enough to work in the IETF please reach them and help them (or let me know and I'll do it). $former_dayjob had a RD office in manaus. We have active kernel/gtk/qt development going on there with real contributors. It is however an isolated kind of strange tax haven in the middle of the amazon and it's kind of hard to get to. Comparative advantage isn't just the domain of agricultural products, extractive industries, and low-cost manufacturing. That seems likely to be part and parcel of the diversity discussion. Latam is not just agriculture and cows :-) I am within about 10 minutes driving distance of maybe 1/3 the world's ethernet switch asic design capacity, so to ignore the fact that concetration and specialization does occur is a little short sighted, it also changes over time when the basis for advantage no longer applies, or erodes).
Re: financial fun with an IETF Meeting in South America
Arturo, Who said ...huu, scary Argentina, do not go there? Where? In this list? Em 28/05/2013 20:09, Arturo Servin escreveu: Juliao, I went to all this sites (besides BBC Brazil) and searched for Argentina. There were some news about economy, the lady President, some about the senate, commercial balance but none saying huu, scary Argentina, do not go there.
Re: financial fun with an IETF Meeting in South America
not be recommended sounds to me it sounded like huu, scary, do not go there. /as On 5/27/13 2:31 AM, Juliao Braga wrote: According to the news published for a long time in Brazilian newspapers and magazines, Buenos Aires (a wonderful place!) would not be recommended. But who should tell us about the true cenary would be our Argentine friends. Juliao On 5/28/13 8:30 PM, Juliao Braga wrote: Arturo, Who said ...huu, scary Argentina, do not go there? Where? In this list? Em 28/05/2013 20:09, Arturo Servin escreveu: Juliao, I went to all this sites (besides BBC Brazil) and searched for Argentina. There were some news about economy, the lady President, some about the senate, commercial balance but none saying huu, scary Argentina, do not go there.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
remove the rrtypes from the registry While it's good to see that the Internet Exemplary Taste-enForcers are alive and well, I would have an extremely strong objection to that approach. jck was trying to enumerate alternatives. he omitted one. i am not a particular advocate of any of them, including the above. but i think the draft in question has very serious privacy issues, and would like to focus on that, not characterization of the messengers. randy
Re: financial fun with an IETF Meeting in South America
Arturo, I'm sorry that you interpret this way. But absolutely, I do not mean to offend. Only expressed a point of view and said that our Argentine friends could clarify. You can not trust the press, totally. Anyway, I apologize if there was offense. Best Regards, Juliao Em 28/05/2013 20:36, Arturo Servin escreveu: not be recommended sounds to me it sounded like huu, scary, do not go there. /as
Re: financial fun with an IETF Meeting in South America
Not taken. It was estrange to me that it were many news about how bad Argentina is in the Brazilian press. I read frequently BBC-Brazil and other newspapers of latin america and I haven't read such things, that is why. /as On 5/28/13 8:45 PM, Juliao Braga wrote: Arturo, I'm sorry that you interpret this way. But absolutely, I do not mean to offend. Only expressed a point of view and said that our Argentine friends could clarify. You can not trust the press, totally. Anyway, I apologize if there was offense. Best Regards, Juliao Em 28/05/2013 20:36, Arturo Servin escreveu: not be recommended sounds to me it sounded like huu, scary, do not go there. /as
Re: More participation from under-represented regions
Hi Edwin,
On 5/26/13, Edwin A. Opare aeop...@gmail.com wrote:
{...}
To elicit participation from the under-represented regions, the
universities are a sure starting point, then a lot more industry-focused
awareness creation by the ISOC local Chapters.
I fully agree with you that universities might be an excellent starting point.
I wonder if you have some ideas to shares in how to do this.
Thanks,
--
Regards,
Edwin
Alejandro Acosta,
On Sun, May 26, 2013 at 8:43 PM, Melinda Shore
melinda.sh...@gmail.comwrote:
On 5/26/13 12:08 PM, SM wrote:
The elephant in the
room is that there hasn't been any discussion about what has been done
to get more participation from under-represented regions but nobody has
mentioned that.
One of the things that's really popped out in the discussion
on the ericas list is that none of the people posting have
been from vendors/manufacturers, which right now is by far
the largest sector participating in the IETF. The posters
have either been academics or from operators. We can't even
get much participation from operators in North America and
Europe. The industry sector bias in IETF participation is
possibly compounding the regional bias.
Melinda
--
=
^A...o$
Re: More participation from under-represented regions
Just one, Alejandro, here in Brazil: Next July, 23-26 in Maceio, Brazil will be held the 13o. CSBC (the main annual meeting of SBC - Brazilian Computer Society. A big meeting!). I sent an e-mail to coordinators, requesting a BoF to talk about the IETF and ISOC Fellowships. If they approve a space, I'll inform the ISOC-BR about it. I'll be there and I can provide the necessary information. But can be others. Also, the Vice-President of the SBC (Lisandro Granville Zambenedetti - granvi...@inf.ufrgs.br) was at IETF 86 in Orlando, and therefore knows the IETF. Additionally the IETF could talk with Lisandro to joint actions in universities and research centers in Brazil. I think the ISOC-BR could do this contact, if necessary. Juliao Em 28/05/2013 22:15, Alejandro Acosta escreveu: I fully agree with you that universities might be an excellent starting point. I wonder if you have some ideas to shares in how to do this.
Re: IETF Meeting in South America
On 5/28/13 3:06 PM, l.w...@surrey.ac.uk wrote: The centres for networking industry in Australia are Melbourne and Sydney, in that order. It's a bit like IETF 51 being held in Grimsby, not London or Cambridge. Okay. So, should we be extrapolating from this to what we can expect from Brazilians if we meet in Buenos Aires? Melinda
Re: IETF Meeting in South America
Perhaps not. Buenos Aires is also a big hub of technology in Latin America. In addition as it was mentioned it relatively close from Sao Paulo, Montevideo and Santiago. Also there are direct flights from other major cities in Peru and Colombia. Going to Buenos Aires, Sao Paulo, Mexico City or Santiago will always split audiences as these are the major tech hubs in the region (also add Bogota, Lima, San Jose and other cities). So, I think it is not comparable with Australia. as On 5/28/13 11:09 PM, Melinda Shore wrote: On 5/28/13 3:06 PM, l.w...@surrey.ac.uk wrote: The centres for networking industry in Australia are Melbourne and Sydney, in that order. It's a bit like IETF 51 being held in Grimsby, not London or Cambridge. Okay. So, should we be extrapolating from this to what we can expect from Brazilians if we meet in Buenos Aires? Melinda
Re: IETF Meeting in South America
I think we can expect a lot of Brazilians people in Buenos Aires. Juliao Em 28/05/2013 23:09, Melinda Shore escreveu: Okay. So, should we be extrapolating from this to what we can expect from Brazilians if we meet in Buenos Aires?
Re: IETF Meeting in South America
On 5/28/13 6:27 PM, Arturo Servin wrote: Going to Buenos Aires, Sao Paulo, Mexico City or Santiago will always split audiences as these are the major tech hubs in the region (also add Bogota, Lima, San Jose and other cities). So, I think it is not comparable with Australia. I actually don't agree with Lloyd that the reason that the Australian meeting didn't lead to increased Australian participation was that it was because it was in Adelaide. I don't expect a South American meeting in any South American city to lead to an increase in Latin American participation, either. Melinda
Re: IETF Meeting in South America
On 5/28/13 11:47 PM, Melinda Shore wrote: On 5/28/13 6:27 PM, Arturo Servin wrote: Going to Buenos Aires, Sao Paulo, Mexico City or Santiago will always split audiences as these are the major tech hubs in the region (also add Bogota, Lima, San Jose and other cities). So, I think it is not comparable with Australia. I actually don't agree with Lloyd that the reason that the Australian meeting didn't lead to increased Australian participation was that it was because it was in Adelaide. I don't expect a South American meeting in any South American city to lead to an increase in Latin American participation, either. Melinda If we just do a meeting probably it won't. But as Christian said it before, that is not the plan. I think that the meeting would be a catalyst to do more thing, but not a solution by it self. .as
RE: IETF Meeting in South America
Melinda, can you confine yourself to disagreeing with something I actually said? Thanks so much! Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Melinda Shore [melinda.sh...@gmail.com] Sent: 29 May 2013 03:47 To: ietf@ietf.org Subject: Re: IETF Meeting in South America On 5/28/13 6:27 PM, Arturo Servin wrote: Going to Buenos Aires, Sao Paulo, Mexico City or Santiago will always split audiences as these are the major tech hubs in the region (also add Bogota, Lima, San Jose and other cities). So, I think it is not comparable with Australia. I actually don't agree with Lloyd that the reason that the Australian meeting didn't lead to increased Australian participation was that it was because it was in Adelaide. I don't expect a South American meeting in any South American city to lead to an increase in Latin American participation, either. Melinda
IETF Meeting in South America
Hello, I agree with the Idea of a IETF meeting in South America. I think it is a way to let the people know about IETF (of course there are other ways, but this is a good one), to give the possibility to students/engineers with very good skills to get into the IETF, thinking that it is going to be published in universities in advance, to give time to students to enroll to a mailing list and read the drafts to be presented. Talking about my personal experience, I am pretty new in the IETF, but since I have been involved, I teach my students (from Argentina) about it, I tell them, that they can participate, that is open, and I realize that they didn't know it. I understand that usually the place is chosen based on the most of participant origin, but I think a meeting in Latin America is a good opportunity to give the possibility to people from that region to know about the IETF. Kind Regards, Ines Robles. -- I would like to follow up on this proposal. Having a meeting in South America scheduled two or three years in advance will let us engage local organisations and individuals on a project. We did several activities in the region trying to encourage IETF participation, but we're going to be much more effective if they're part of a plan with a strong commitment (and effort) from the IETF community. Since this opportunity was announced, there were several contacts and proposals from different groups asking for additional information, suggesting things to do, asking for details, etc. We now have a much more fertile ground to do multiple things. Going further will also enrich the IETF work and community (making it more international becomes a side effect). In this region there are many engineers, software developers, people at Universities, etc. that could provide new ideas and energy to the IETF. Christian
Re: financial fun with an IETF Meeting in South America
Hello, I'd also say that I've never heard anyone making that sort of statement. For instance, the argentinan government itself has a program to increase Internet connectivity throughout the country -- That is the web page of the program that Fernando mentions, http://www.conectarigualdad.gob.ar/ (spanish ) - netbooks with windows and Linux :) for the kids - His view is shared by many, so in the event IETF gets to meet in Buenos Aires, if the meeting becomes public, don't be surprised to see some coordinated political manifestation. I live in Argentina too, and people don't make political manifestation about Internet topics. In opposite. In Mendoza (Arg.) we did a lot of events (conferences, hands-on) open to the people (no technical) about IPv6 and they were very interested on it and the concurrence was high (200 people :-)) Argentina is a beautiful place to know :-), have a lot of things to do, and is always full of tourist during all the seasons. Kind Regards, Ines Robles.
Re: IETF Meeting in South America
I went to Adelaide. it was my first IETF. I am now an IETF regular-irregular, of 10+ years standing. So, proof by example, it increased Australian participation by at least 1. In fact, I think by scale, Australians punch above their weight. Especially if you include americans who live in Australia, Australians who live in the mainland of the USA. I think IETF going to Adelaide had net positive effects on Australian participation. Small. but real. -G On Wed, May 29, 2013 at 1:19 PM, l.w...@surrey.ac.uk wrote: Melinda, can you confine yourself to disagreeing with something I actually said? Thanks so much! Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Melinda Shore [melinda.sh...@gmail.com] Sent: 29 May 2013 03:47 To: ietf@ietf.org Subject: Re: IETF Meeting in South America On 5/28/13 6:27 PM, Arturo Servin wrote: Going to Buenos Aires, Sao Paulo, Mexico City or Santiago will always split audiences as these are the major tech hubs in the region (also add Bogota, Lima, San Jose and other cities). So, I think it is not comparable with Australia. I actually don't agree with Lloyd that the reason that the Australian meeting didn't lead to increased Australian participation was that it was because it was in Adelaide. I don't expect a South American meeting in any South American city to lead to an increase in Latin American participation, either. Melinda
RE: IETF Meeting in South America
Hi, How about in the Philippines? I can show my homeland... I can help facilitate the event, why don't you give it a try! Regards Medel From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of I rob Sent: Wednesday, May 29, 2013 12:17 PM To: ietf@ietf.org Subject: IETF Meeting in South America Hello, I agree with the Idea of a IETF meeting in South America. I think it is a way to let the people know about IETF (of course there are other ways, but this is a good one), to give the possibility to students/engineers with very good skills to get into the IETF, thinking that it is going to be published in universities in advance, to give time to students to enroll to a mailing list and read the drafts to be presented. Talking about my personal experience, I am pretty new in the IETF, but since I have been involved, I teach my students (from Argentina) about it, I tell them, that they can participate, that is open, and I realize that they didn't know it. I understand that usually the place is chosen based on the most of participant origin, but I think a meeting in Latin America is a good opportunity to give the possibility to people from that region to know about the IETF. Kind Regards, Ines Robles. -- I would like to follow up on this proposal. Having a meeting in South America scheduled two or three years in advance will let us engage local organisations and individuals on a project. We did several activities in the region trying to encourage IETF participation, but we're going to be much more effective if they're part of a plan with a strong commitment (and effort) from the IETF community. Since this opportunity was announced, there were several contacts and proposals from different groups asking for additional information, suggesting things to do, asking for details, etc. We now have a much more fertile ground to do multiple things. Going further will also enrich the IETF work and community (making it more international becomes a side effect). In this region there are many engineers, software developers, people at Universities, etc. that could provide new ideas and energy to the IETF. Christian This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately.
Re: IETF Meeting in South America
Just wondering if some folks realize that IETF meetings are not missionary trips, conferences, conventions or industry trade shows ... -Jorge
Last Call: draft-thornburgh-adobe-rtmfp-07.txt (Adobe's Secure Real-Time Media Flow Protocol) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Adobe's Secure Real-Time Media Flow Protocol' draft-thornburgh-adobe-rtmfp-07.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features making it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used. The file can be obtained via http://datatracker.ietf.org/doc/draft-thornburgh-adobe-rtmfp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-thornburgh-adobe-rtmfp/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1942/
Results of IETF-conflict review for draft-pornin-deterministic-dsa-01
The IESG has completed a review of draft-pornin-deterministic-dsa-01 consistent with RFC5742. The IESG has no problem with the publication of 'Deterministic Usage of DSA and ECDSA Digital Signature Algorithms' draft-pornin-deterministic-dsa-01.txt as an Informational RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-pornin-deterministic-dsa/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-pornin-deterministic-dsa/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Last Call: draft-ietf-avtcore-avp-codecs-02.txt (Update to Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Update to Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)' draft-ietf-avtcore-avp-codecs-02.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates the RTP/AVP profile (and by extension, the profiles that build upon it) to reflect changes in audio codec usage since the document was originally published. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-avtcore-6222bis-03.txt (Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' draft-ietf-avtcore-6222bis-03.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-avtcore-idms-09.txt (Inter-destination Media Synchronization using the RTP Control Protocol (RTCP)) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Inter-destination Media Synchronization using the RTP Control Protocol (RTCP)' draft-ietf-avtcore-idms-09.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new RTP Control Protocol (RTCP) Packet Type and RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Reporting Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be send to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is usefull are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-idms/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-idms/ballot/ No IPR declarations have been submitted directly on this I-D.
