RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ron, At 16:55 13-10-2013, Ronald Bonica wrote: Are you suggesting that we don't address the problem because the code is too complex to touch? It's a known problem since at least seven years. Given that the problem is labelled as a security issue there would have to be some changes to the specification at some point. There were design decisions to implement the specification and the code has been deployed. The proposed outbound change is one sentence. The code change to implement that one sentence requires reviewing some implementation decisions (re. encapsulation, etc.). Please note that I am not arguing for or against a change in the RFC 2119 key words. The write-up only mentions that the draft has been implemented on stateless firewalls. I am curious about whether there are any implementations for a host. Regards, -sm
Re: WG Review: IPv6 Maintenance (6man)
At 09:38 11-10-2013, The IESG wrote: The IPv6 Maintenance (6man) working group in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for [snip] Jul 2014 - Advance IPv6 core specifications to Internet standard Which RFCs does the above refer to? Is the milestone about delivering the work item(s) to the IESG? Regards, -sm
Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard
At 11:55 02-10-2013, The IESG wrote: The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Implications of Oversized IPv6 Header Chains' 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 This document intends to update the IPv6 specification. I looked into some code (host) which would be affected by the RFC 2119 requirement in Section 5. The code is complex as it is. I am not sure whether the requirement can be implemented without too much difficulty. I have not looked into the code which processes inbound packets. Regards, -sm
Re: Montevideo statement
Hi Medel, At 19:11 09-10-2013, Medel v6 Ramirez wrote: Leaders were "processed" thoroughly prior to their appointment so I trust them. And that they hold through the "spirit" of being an IETF and shall be responsible under oath for any impact on the organization. There was a Recall petition last year (see http://www.ietf.org/mail-archive/web/ietf/current/msg75672.html ). Note that the IETF "Trustee have a fiduciary duty to protect the IETF's property". What are the implications of: "They identified the need for ongoing effort to address Internet Governance challenges, and agreed to catalyze community-wide efforts towards the evolution of global multistakeholder Internet cooperation." Should a global body have oversight over the IETF? Some people are arguing for that as part of the future of Internet Cooperation. Regards, -sm
Re: leader statements (was: Montevideo statement)
At 12:27 09-10-2013, Andrew Sullivan wrote: Now, there is indeed a possible issue, and that is that these chairs were attending a "chief officer"-type meeting: there were CEOs and so on, and (presumably by analogy) the chairs got invited to represent the organizations of which they are chairs. John is quite right that people unfamiliar with the way the IETF or IAB work might interpret the statement along the lines of, "The CEO of the IETF said that the IETF subscribes to some view." Normally, the leader of an organization can direct that organization to some end; the Chair is the leader; therefore, the Chair can direct the organization. Of course, that's not how we operate (this is, I think, at the bottom of this very discussion). But others might get that impression. What I am not sure about is whether people are willing to accept the chairs acting in that sort of "leader of organization" role. If we do accept it, then I think as a consequence some communications will happen without consultation. For a CEO is not going to agree to issue a joint communique with someone who has to go negotiate the contents of that communique (and negotiate those contents in public). If we do not accept it, then we must face the fact that there will be meetings where the IETF or IAB just isn't in the room, because we'll have instructed the chairs not to act in that capacity. There might be some history to the "we reject: kings, presidents and voting". Should the IETF change the way it operates? There are advantages to the Chair directing the organization. It is easier to set policy. It is easier for the Chair to negotiate with other organizations. There are disadvantages, for example, the policy might not reflect the wishes of the community. The IETF might have to reconsider whether people participate as individuals or as corporate folks. There is the question of openness. If the IETF were to set policy behind closed doors, can it say that it is open? "We" don't take working group decisions behind closed doors. The IESG tries to take its decisions in a transparent manner. There may have been a time when it was not like that. As I mentioned previously the IAB [1] is supposed to be based on collegial responsibility. There hasn't been any discussion to change that during the tenure of the last two IAB Chairs. What's different now? The IAB has published statements and RFCs about its positions. The Chairs can exercise their discretion. The members of the IESG and the IAB have not mentioned that they do not have the ability to negotiate under current rules [2]. The IETF Chair and the IAB Chair have not mentioned that they are not able to negotiate due to the current rules. The question of trust comes up every now and then. Responsibility [3] seems to be an inconvenient word on this mailing list. What's the opinion of the persons who are part of "leadership" about all this? Regards, -sm 1. "People outside think IAB has power :-)" 2. I chose a word quickly. 3. the state or fact of being responsible, answerable, or accountable.
Re: Montevideo statement
Hi Russ, At 09:24 09-10-2013, Russ Housley wrote: This is a statement about what happened at a meeting. Discussion would not change what happened at the meeting. Making the statement very public allows a good discussion of what should happen next. I look forward to that discussion. One of the organizations mentioned in the statement commented about it as follows: "Internet/Web Organizations Issue Montevideo Statement on the Future of Internet Cooperation" "The leaders of organizations responsible for coordination of the Internet technical infrastructure globally met in Montevideo, Uruguay, to consider current issues affecting the future of the Internet. They issued today a Montevideo Statement on the Future of Internet Cooperation, signed by African Network Information Center (AFRINIC), American Registry for Internet Numbers (ARIN), Asia-Pacific Network Information Centre (APNIC), Internet Architecture Board (IAB), Internet Corporation for Assigned Names and Numbers (ICANN), Internet Engineering Task Force (IETF), Internet Society (ISOC), Latin America and Caribbean Internet Addresses Registry (LACNIC), Réseaux IP Européens Network Coordination Centre (RIPE NCC), W3C." One of the signatories of the statement mentioned (if I understood correctly) that the statement was from the organizations. Is the statement an IAB statement or a statement from the IAB Chair? Please note that I have read the message from Andrew (see http://www.ietf.org/mail-archive/web/ietf/current/msg82926.html ). I agree that discussion would not change what happened. I don't think that it is a good idea to have a "fait accompli" [1] for the IETF Community to discuss about. It has been said that "we reject: kings, presidents and voting". The statement creates the perception that the leaders of the Internet Architecture Board and the Internet Engineering Task Force are like kings or presidents. The Internet Architecture Board is supposed to be based on collegial responsibility. I read that as meaning not to have statements which commits the Internet Architecture Board to a course of action without some form of approval from the members of that Board. Obviously, some form of approval would not have to be sought if the course of action has been discussed previously. "The [IAB] board discussed the issue of a joint OpenStand statement or an IAB specific statement. Many members were against a closed review period for such a statement and would prefer to have an open discussion period in the IETF if such a statement was required." There is a comment on the www.iab.org web site about "allegations of interference by some governments in the standards development process" and a link to an "OpenStand" statement. It seems that there was a closed review period for the joint OpenStand statement. I don't think that it is possible to build trust if openness and transparency are in name only. I am not enthusiastic about having a discussion which does not materially affect the outcome. Regards, -sm 1. something that has been done and cannot be changed.
Re: Montevideo statement
Hi Russ, At 15:51 07-10-2013, Stephane Bortzmeyer wrote: This wording is surprising. It looks like it is the revelations that undermined confidence, and not the NSA actions. I would prefer something like, to avoid shooting the messenger: They expressed strong concern over the undermining of the trust and confidence of Internet users globally, due to pervasive monitoring and surveillance by powerful actor(s). The wording could have been different instead of one expressing a strong concern about the "revelations". There is a statement from LACNIC about allegations of espionage (http://www.lacnic.net/en/web/anuncios/2013-lacnic-acerca-espionaje). The statement signed by the IAB Chair (http://www.iab.org/documents/correspondence-reports-documents/2013-2/montevideo-statement-on-the-future-of-internet-cooperation/) is about future of Internet Cooperation. This is the second time that the IAB has issued a statement without requesting comments from the IETF Community. In my humble opinion it would be good if there was a comment period. Regards, -sm
Re: Last Call: (Recommendations on filtering of IPv4 packets containing IPv4 options.) to Best Current Practice
At 12:05 16-09-2013, The IESG wrote: The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Recommendations on filtering of IPv4 packets containing IPv4 options.' as Best Current Practice 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-09-30. Exceptionally, comments may be I took a quick look at the draft. In Section 4.3.5: "Routers, security gateways, and firewalls SHOULD implement an option- specific configuration knob ..." The heading of that section is "Advice". It's better to have an explanation as advice instead of using a RFC 2119 "should". 'The default setting for this knob SHOULD be "drop", and the default setting MUST be documented.' I guess that the "SHOULD be drop" is obvious. Using a RFC 2119 "must" to state that the default setting must be document is excessive. The above comment also applies to Section 4.5.5 In Section 4.8.5: "This option SHOULD be allowed only in controlled environments, where the option can be used safely. [RFC6398] identifies some such environments. In unsafe environments, packets containing this option SHOULD be dropped." There could be one RFC 2119 "should" instead of two in the above. "A given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment. Therefore, routers, security gateways, and firewalls SHOULD, by default, ignore the Router Alert option. Additionally, Routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction in the presence of packets containing the Router Alert option. This configuration setting SHOULD allow to honor and process the option, ignore the option, or drop packets containing this option. The default configuration is to ignore the Router Alert option." The last sentence mentions the default configuration. It looks clear to me. The first (quoted text) RFC 2119 "should" says that same thing. Regards, -sm
Re: Community Feedback: IETF Trust Agreement Issues
Hi Chris, At 23:48 02-08-2013, Chris Griffiths wrote: Issue 1 We have recently been asked permission to republish the TAO with a creative commons license, but according to counsel, the current trust agreement does not give the trustees the rights to do this. - Without specific language being added to the trust agreement, we cannot grant these types of requests. - The current open request for a creative commons license from 6/18/2013 cannot be completed. In term of "outgoing" rights the Independent Submission Stream is different from the IETF Stream. The draft version of the Tao might offer a path forward. Would it be possible to have it submitted through the Independent Submission Stream and use that version and changes to address the above request? I haven't looked into the process stuff. It might be possible [1] to sort that out once the legal hurdles are settled. Regards, -sm 1. I read the thread :-(
Re: feedback & blog entry
Hi Jari, At 11:22 24-09-2013, IETF Chair wrote: You are referring to attendance and authoring RFCs? I agree, of course. I apologize for using a metric that is, at best, partial. My only defense is that it was what I had easily available :-( I do realise that real engagement from different types of organisations and people and areas of the world goes to far more fundamental issues than showing numbers of people. True involvement and effect is what counts. As we know, that does not necessarily correlate with any particular statistic... The metric which you provided on your own time has been useful. With these statistics there wouldn't have anything to look at to get a view of IETF work. I agree that true involvement and effort is what counts. Showing the number of people might be the least bad way to understand what's happening and whether the efforts are successful. Ok. Which comment are you referring to? I'm sorry, too much e-mail to know what you are referring to. I'd be interested in better metrics. From http://www.ietf.org/mail-archive/web/ietf/current/msg79780.html "It's pretty tempting for new participants to submit drafts that they like, and maybe reaching out to their office mates as co-authors, but to be effective in the IETF, participants have to learn how to collaborate with folks from other IETF sponsors" How does one collaborate in the IETF? How does one contribute in the IETF? What's the level of involvement at the country level? Is the involvement from a country increasing if we look at the number of people involved? Please note that the questions are not meant as questions for you to reply to. I am not sure whether there is a way to generate statistics to get a view of the above.It may be worth pursuing if other people believe that it would be a better metric. Regards, -sm
Re: [urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt)
At 08:10 19-09-2013, John C Klensin wrote: The WG will be three years old in late November. I hope and wish we could set a target of having the documents in the hands of the IESG well before that, ideally before Vancouver. From http://www.ietf.org/mail-archive/web/urn/current/msg01626.html "If the WG does not make visible progress before IETF 82 (which I would measure by, at least, updated versions of the chartered I-Ds), as the responsible AD I will need to consider taking more drastic measures to generate a successful outcome, or consider closing the WG." And http://www.ietf.org/mail-archive/web/urn/current/msg01679.html "I assume that the URNBIS WG will meet at IETF 83 in Paris (if the WG does not plan to meet then my concerns would become even more grave). Please note that WG sessions need to be scheduled less than 2 weeks from now:" There were an issue about authorship. From http://www.ietf.org/mail-archive/web/urn/current/msg01843.html "We have tried to standardize the URN syntax in Finland before, but failed (in about 2005 or so) when the external evaluators said that the draft was not compliant with URI syntax as defined in RFC3986. This time we do not want to take any risks. On the other hand, there is an urgent national need to revise RFC2141, since the government is planning to establish a URN service for the entire public sector. Currently the national library of Finland and its partners are assigning about 200.000 URNs annually to persistent digital resources; this figure is likely to rise." And http://www.ietf.org/mail-archive/web/urn/current/msg02062.html "Today begins a two-week working group last call of draft-ietf-urnbis-rfc2141bis-urn-06.txt. This last call will end Tuesday, 27 August 2013." And http://www.ietf.org/mail-archive/web/urn/current/msg02120.html "It is now over three weeks since the closing date and I, at least, have no idea where we are. Do the WG Chair(s) think we have consensus?" Can the Finnish government rely on the IETF for technical standards? Regards, -sm
Re: feedback & blog entry
Hi Jari, At 03:10 20-09-2013, IETF Chair wrote: One of things that I feel is important for the chair to do is to talk to various IETF contributors - not just on this list! :-) - and try to understand what issues they have, either technical or otherwise. Here's a small overview report of my recent effort to talk I read the article. As a comment about the last paragraph, the metric being used is not the best in my humble opinion. Spencer Dawkins made an insightful comment which I would look into if I was looking for a better metric. Regards, -sm
IPR disclosure for draft-kaplan-insipid-session-id (was: Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt)
Hello, At 01:52 20-09-2013, Gonzalo Camarillo wrote: to summarize the status of this IETF LC, we are still expecting (at least) an additional IPR disclosure on this draft (as announced on the INSIPID list). When that happens, I will IETF LC it again. There was a discussion about IPR on this mailing list but nobody mentioned RFC 6701 or RFC 6702. It is a mystery why the IETF cannot remember the (Informational) RFCs it published one year ago. There was a Last Call for draft-kaplan-insipid-session-id-03 ( http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11753.html ). The announcement did not mention any IPR disclosure. Does the above qualify as a late disclosure? In the mean time, we need to address the comments related to the IANA registration the draft requests. I have discussed with the expert reviewer (Adam) and adding something along these lines would help: "This registration is intended to be temporary. The authors expect that a standards-track definition of Session-ID will be published at a future date. Assuming such a document is published, it will replace this registration with a reference to itself, at which point this document will no longer be referenced by IANA." draft-ietf-insipid-session-id-02 is a WG document intended as a Proposed Standard. The INSIPID charter mentions a milestone for February 2013. It would be good if the IESG takes into consideration the overhead of getting this temporary assignment published as an IETF RFC. The reason given for publication was that 3GPP has tight deadlines. It is understandable that there can be delays in reaching a milestone. What is the INSIPID WG estimate for that future date? Regards, -sm
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Hi Brian, At 21:54 19-09-2013, Brian E Carpenter wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Thanks for writing the draft. For the sake of disclosure [1], I know some of the XSF members. draft-carpenter-prismatic-reflections-00 mentions that: "Clearly, we have a lot of specification work ongoing in different areas that helps to mitigate various security vulnerabilities. This ranges from recent work on XMPP end-to-end security " I recently read an article about XMPP ( https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging ). From the article: "removes the option to disable the archiving of all chat communications" Regards, -sm 1. I welcome any questions about conflict of interest.
Re: Transparency in Specifications and PRISM-class attacks
At 06:12 20-09-2013, Harald Alvestrand wrote: By those who implement them, and those who try to understand how it works to the degree that they feel assured that there are no non-understood security risks (intentional or otherwise). Yes. From the stack I'm currently working on, I find the ICE spec to be convoluted, but the SDP spec is worse, becaue it's spread across so many documents, and there are pieces where people seem to have agreed to ship documents rather than agree on what they meant. I have not found security implications of these issues. I'll quote a message [1] from an ex-IAB member: "in IPv4 days: - implement and test - then write a draft or, - BSD IPv4 code is there - everyone cheated and looked at it today: - write a draft with pipe dream - spam IESG - then implement - big issue happen - go back to 1" It is an implementor's nightmare to understand a specification when it is spread across multiple documents. The "Updates" and document status (label) does not make matters easier. Some parts will not be committed into the tree as it is not simply a matter of writing code; there is also the question of who is going to maintain that code. At 07:34 20-09-2013, John C Klensin wrote: I don't know of any general solution to those problems, but I think the community and the IESG have got to be a lot more willing to push back on a spec because it is incomprehensible or contains too many options than has been the case in recent years. If I recall correctly there was a discussion about a solution in 1992. RFC 2026 also considered the problem of too many options and offered a path to resolve that. At 08:37 19-09-2013, Phillip Hallam-Baker wrote: Whatever our personal political views on the matter are, the views of our audience are likely to be different. Most of our audience are not US citizens, they are not even from the Anglosphere. Yes. of the one CA. That is OK, I don't complaint about that, I have always understood that anyone who is taking on a position of extreme responsibility is subject to an equally extreme degree of proof. Yes. The process I have seen instead is that people argue about whether a requirement should be included in the requirements document and the final requirements document is a list of requirements the noisiest people in the group thought were important rather than what the document should be which is a tool to determine whether the design is capable of addressing the use cases. The boundary between use cases and edge cases is not always clear. The requirements document is a long list of stuff to satisfy the noisiest and the people considered as important. Harald Alvestrand mentioned "actually finishing our specs". It's difficult to get there when a working group suffers from exhaustion. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ipv6/current/msg07313.html
Re: Last Call: (Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks) to Informational RFC
At 09:40 10-09-2013, The IESG wrote: The IESG has received a request from the INtermediary-safe SIP session ID WG (insipid) to consider the following document: - 'Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks' 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-09-24. Exceptionally, comments may be Section 4.5 of the draft discusses about logging. It mentions that "creating a common header field value through all SIP entities will greatly reduce any challenge for the purpose of" ... "communication tracking". I look a quick look at Reference [6]. It mentions that the IMEI shall be used for generating an identifier. Is the IMEI covered by REQ4? Regards, -sm
Re: Last Call: (Threat Model for BGP Path Security) to Informational RFC
At 15:26 09-09-2013, The IESG wrote: The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Threat Model for BGP Path Security' 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-09-23. Exceptionally, comments may be I read this draft to find out whether we have met the enemy, and he is us [1]. The draft mentions PATHSEC in the Introduction section without explaining the term. I suggest using the following (edited) which is already in the Abstract: "The term PATHSEC is used to refer to any BGP path security technology that makes use of the RPKI." According to Section 2 anyone or any thing can be an adversary. I would not use "threat" to determine "adversary" as motivation can change. I am not sure whether the average reader will understand the nuance. Please note that I am not suggesting any change. In Section 3: 'Hackers may be motivated by a desire for "bragging rights" or for profit or to express support for a cause.' The above may be applicable for any person. "The staff could be motivated to do this based on political pressure from the nation in which the registry operates (see below) or due to criminal influence (see above)." Wouldn't the profit angle also be applicable for registries? The above focuses on staff instead of the registry. Political pressure would apply for the organization (see definition of entity in Section 2). "Nations - A nation may be a threat. A nation may control one or more network operators that operate in the nation, and thus can cause them to act as rogue network operators." The are also network operators that operate outside the nation. That can be used to get the operator to act as a dishonest network operator outside the nation. "A nation may have a technical active wiretapping capability (e.g., within its territory) that enables it to effect MITM attacks on inter-network traffic. (This capability may be facilitated by control or influence over a telecommunications provider operating within the nation.)" There is an emphasis that this (the nation) threat only applies within the territory. There is a sentence after the quoted text that the nation has the ability to take control in other countries. Would a reference to NSL be appropriate in that paragraph? In Section 4.2: "False (Route) Origination: A router might originate a route for a prefix, when the AS that the router represents is not authorized to originate routes for that prefix. This is an attack, but it is addressed by the use of the RPKI [RFC6480]." Wouldn't the way to address the attack open the way for other attacks (see Section 3)? In Section 4.5: "Some adversaries might effect an attack on a CA by violating personnel or physical security controls as well. The distinction between CA as adversary vs. CA as an attack victim is important. Only in the latter case should one expect the CA to remedy problems caused by a attack once the attack has been detected. (If a CA does not take such action, the effects are the same as if the CA is an adversary.)" I gather that the CA would have a CPS and that CPS would take into consideration the possible attacks and describe the measures to prevent them. The above looks at it from an after-the-fact perspective; i.e. once the damage is done, action is taken. This draft is well-thought. There's a cryptography angle to one of the references. I wondered about the why for that reference. Regards, -sm 1. The explanation was that "each individual is wholly involved in the democratic process, work at it or no. The results of the process fall on the head of the public and he who is recalcitrant or procrastinates in raising his voice can blame no one but himself".
was: not really pgp signing in van
Hi Yoav, At 03:28 11-09-2013, Yoav Nir wrote: I don't think you'd even need the threats. [snip] Notice the important parts of that pitch. A sense of danger; Making the target feel either patriotic or a humanitarian; Sharing a "secret" with the target, making him part of the "inner circle". Making the target feel important, like "only your cooperation can help us stop the next attack". If this pitch is executed correctly, by the end, the target is asking for an NSL as CYA. I've seen this kind of thing done once years ago, but it was done very poorly and didn't work. Yes. My reading of Phillip Hallam-Baker's comment is that there isn't anything to worry about in relation to Comodo except that he does not have any knowledge about the operational side. John Levine asked how likely they would risk their reputation. Theodore Ts'o mentioned that there really is no incentive for them to do a good job. Over the last few years nobody noticed that there might be a problem. That's not reassuring. I doubt that people would not comply with a NSL. Regards, -sm
Re: Practical issues deploying DNSSEC into the home.
Hi Jim, At 08:55 10-09-2013, Jim Gettys wrote: We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is "use ntp". Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. That problem has been bothering me for a while. There can be a leap of faith at startup to get the correct time. DNSSEC can be done after that. Regards, -sm
Re: What real users think [was: Re: pgp signing in van]
Hi Brian, At 13:48 09-09-2013, Brian E Carpenter wrote: (Excuse my ignorance, but do existing MUAs allow one to edit a body part that arrived with a PGP signature?) Yes. Somebody would write a MUA to do it if it wasn't possible. Regards, -sm
Re: Equably when it comes to privacy
Hi Joel, At 11:59 08-09-2013, joel jaeggli wrote: Should your tools, the contents of your mind, and the various effects and context of your personal communication become instruments of state-power? Because the tools we've built are certainly capable of that. Yes. That's not a good motivation to give up on privacy though. Regards, -sm
Re: Equably when it comes to privacy
At 07:07 08-09-2013, Jorge Amodio wrote: You mean like Pakistan, Iran, Libya, Syria, Saudi Arabia There were people from Pakistan who participated in the IETF. I recall an email exchange where a person from that country received an unpleasant comment from someone who is part of the IETF "leadership". In my opinion a discussion about Country X or Country Y would take the thread downhill. It can also have a chilling effect. At 05:14 08-09-2013, Phillip Hallam-Baker wrote: Another worrying aspect of [censored] is that it is named after[censored]. They seem to be looking to make [censored] out of us. They certainly seem to be endorsing [censored]. What should we think if the [censored] had a similar program codenamed [censored]? It would not look good. Regards, -sm
Equably when it comes to privacy
Hi David, At 16:10 06-09-2013, David Morris wrote: Seriously though, NSA makes a nice villan, but much of our hardware is manufactured in counties with fewer restraints than the NSA when it comes the right to privacy, etc. Wouldn't suprise me that my major brand router has sniffers from more than one country's security agency. The right to privacy is mentioned in the above. From http://www.europarl.europa.eu/sides/getDoc.do?type=MOTION&reference=B7-2013-0342&language=EN "whereas the US legal system does not ensure the protection of non-US citizens, such as EU citizens; whereas, for instance, the protection provided by the Fourth Amendment applies only to US citizens and not to EU citizens or other non-US citizens;" There aren't any villains in all this. There is a question of whether the company taking the data will value each of its customers equably when it comes to privacy. It doesn't seem so. Regards, -sm
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
Hi Tim, At 15:02 06-09-2013, Tim Bray wrote: How about a BCP saying conforming implementations of a wide-variety of security-area RFCs MUST be open-source? A BCP is not needed to do that. It is already doable "but we [1] know that you [2] are not going to do it". Speaking of open source, http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c *ducks* Where? I don't see any ducks. :-) Regards, -sm 1. The word "we" is used in a general context. 1. The word "you" is used in a general context.
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
Hi Dean, At 11:31 06-09-2013, Dean Willis wrote: What if they didn't say they were NSA guys, but just discretely worked a weakness into a protocol? What if they were a trusted senior member of the community? Trust does not work well without accountability. There is less to worry about if you do not implicitly trust senior members of the community. Regards, -sm
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
Hi Vinayak, At 01:13 06-09-2013, Vinayak Hegde wrote: It is tragic if the community does understand strong encryption is essential in many cases (with the caveat that it is not a panacea for all security breaches) As for raising issues at the last-call. Why not ? The last-call is no different than any other mailing list discussion or going to the mic in a physical meeting. (Other than the urgency of having the last chance to comment ?) The Last Call is different from going to the microphone in a physical meeting. Fancy speeches at the microphone are impressive. It takes more work to identify issues and explain why it is or can be a problem. Martin Sustrik asked: At 06:04 06-09-2013, Martin Sustrik wrote: So, what if an NSA guys comes in and proposes backdoor to be added to a protocol? Is it even a valid interest? Does IETF as an organisation have anything to say about that or does it remain strictly neutral? Would anyone notice it on a Last Call? Would anyone say something about it? I doubt that. Ted Lemon said it nicely: "we should pay attention". Regards, -sm
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
At 20:32 05-09-2013, Vinayak Hegde wrote: While it is nice to do a dedication of this meeting to the SA surveillance, I do not see us solving any issue here. It is merely a "feel-good" measure without real impact. :-) Second, technology can never fix what is essentially a political problem. for eg. We mandate strong security protocols and end-to-end encryption in HTTP(S) by default. Lets In a Last Call comment a few months ago it was mentioned that a specification takes the stance that security is an optional feature. I once watched a Security Area Director spend thirty minutes trying to explain to a working group that security feature should be implemented. If I recall correctly the working group was unconvinced. Would the community raise it as an issue during a Last Call if a proposed protocol did not have strong security features? It's up to the reader to determine the answer to that. assume all browsers implement this and do this perfectly without software flaws. All the NSA has to do is to compromise the other endpoint (controlled by ACME major corp). ACME gives over the encryption keys and access to all the unencrypted data to the NSA. So now Yes. what are we going to do. The IETF can make an political statement by taking a stand but that may mean nothing in reality when the laws are weak. Another example is when you have Taking a stand that means nothing is a feel-good measure. encrypted your drive and do not want to hand over the keys as it has some personal (and possibly incriminating evidence). In several countries you can be held in jail indefinitely (with obvious renewals of sentences) until you hand the keys over[1]. So in summary, technology cannot solve political and legal issues. At best it can make it harder. But in this case maybe not even that. The IETF outlook does not apply in several countries. The IETF does not seem to pay much attention to that details (re. hand the keys). It's not clear what the emergency is. Phillip Hallam-Baker and Brian Carpenter already mentioned that it's not like this is a surprise. According to a news article key architects of the Internet plan to fight back by drawing a plan to defend against state-sponsored surveillance. Anyway, if someone really wanted to call for an emergency response the person would have sent it to an IETF mailing list. At 20:08 05-09-2013, Ted Lemon wrote: I think we all knew NSA was collecting the data. Why didn't we do something about it sooner? Wasn't it an emergency when the PATRIOT act was passed? We certainly thought it was an emergency back in the days of Skipjack, but then they convinced us we'd won. Turns out they just went around us. I would describe it as a scuffle instead of a battle. My guess is that the IETF did not do anything sooner as nobody knows what to do, or it may be that the IETF has become conservative and it does not pay attention to the minority report. At 23:04 05-09-2013, Jari Arkko wrote: I think we should seize this opportunity to take a hard look at what we can do better. :-) And please do not think about all this just in terms of the recent revelations. The That's an interesting perspective. security in the Internet is still a challenge, and if there are improvements they will be generally useful for many reasons and for many years to come. Perhaps this year's discussions are our ticket to motivate the world to move from "by default insecure" communications to "by default secure". Publicity and motivation are important, too. Yes. Regards, -sm
Re: Last Call: (Retirement of the "Internet Official Protocol Standards" Summary Document) to Best Current Practice
At 14:45 05-09-2013, Scott O Bradner wrote: looks good to me except that maybe using the IETF Announce list rather than IESG minutes as the publication of record What draft-resnick-retire-std1-01 says is that the "publication of record" has been the IESG minutes. I read what Scott Bradner wrote as meaning that the IETF will use the IETF Announce list as the publication of record. Suggested text: Finally, RFC 2026 [RFC2026] section 6.1.3 also calls for the publication of an "official summary of standards actions completed and pending" in the Internet Society's newsletter. This has also not been done in recent years. Therefore, that paragraph is also effectively removed from section 6.1.3. The "publication of record" for standards action is the IETF Announce list. The idea here is to announce the standards action that has been taken. By the way, "publication of record" is different from formal record. Regards, -sm
RE: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
At 02:43 04-09-2013, mohamed.boucad...@orange.com wrote: [Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time. There aren't any minutes for that WG session. Is there a formal request for guidance from the working group and is it possible to verify that there wasn't any comment at that time? I took a quick look at the draft. I note that, for the telechat, Spencer Dawkins and Pete Resnick are paid by the document. :-) It would be interesting to have an approximate page count of the number of pages to review. In the Introduction Section: "One of the major hurdles encountered by mobile operators is the availability of non-broken IPv6 implementation in mobile devices." I read the above sentence several times. My understanding is that having non-broken IPv6 implementations is a hurdle. The way to fix that would be for mobile operators to have broken IPv6 implementations. :-) In Section 1.2: "It uses the normative keywords only for precision." My reading of the word "precision" is that it is the ability of a measurement to be consistently reproduced. I don't see how special language fits that. My guess is that the intent of that sentence got lost in translation ( http://www.youtube.com/watch?v=pCB7cxv-Ey8 ). In Section 2: "REQ#3: The cellular host MUST comply with the behavior defined in [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-Context type." Is the above in accordance with RFC Editor guidelines? "REQ#6: The device MUST support the Neighbor Discovery Protocol ([RFC4861] and [RFC5942])." In which RFCs are the Neighbor Discovery Protocol defined? I am asking this question as the above does not match the information provided by the RFC Editor. "REQ#12: The cellular host SHOULD support a method to locally construct IPv4-embedded IPv6 addresses [RFC6052]. A method to learn PREFIX64 SHOULD be supported by the cellular host." How would the capitalized "should" be read in the above? The guidance in RFC 2119 does not look applicable here. In Section 5: "REQ#34: Applications using URIs MUST follow [RFC3986]. For example, SIP applications MUST follow the correction defined in [RFC5954]." The above says that applications must follow RFC 3986 and then provides an example with a capitalized "must" for RFC 5954. The Security Considerations Section references draft-ietf-v6ops-rfc3316bis-04. That draft contains exhaustive security considerations. This draft doesn't say much about security considerations. Regards, -sm
Re: Last Call: (Retirement of the "Internet Official Protocol Standards" Summary Document) to Best Current Practice
Hi Pete, At 16:02 03-09-2013, Pete Resnick wrote: OK, does this do anything for anyone? Finally, RFC 2026 [RFC2026] section 6.1.3 also calls for the publication of an "official summary of standards actions completed and pending" in the Internet Society's newsletter. This has also not been done in recent years, and the "publication of record" for standards actions has for some time been the minutes of the IESG. [IESG-MINUTES] Therefore, that paragraph is also effectively removed from section 6.1.3. I suggest using "IETF Announce mailing list" as the "publication of record". The mailing list probably has a wider readership and anyone can subscribe to it. The usage of the mailing list is also consistent with other parts of RFC 2026. Regards, -sm
Re: Mail lost yesterday
Hi Jari, At 01:05 30-08-2013, Jari Arkko wrote: I certainly agree that in incidents like this, a timely notification is in order. (Of course to the extent that the outage itself allows us to do that. Sometimes the outage or the queue that has built up during the outage delays sending a notification.) I'll refrain from commenting about the details of the last incident as there are extenuating circumstances. My message was not about the contact address to report operational issues. For what it is worth I did notice an issue with the mail archives but I didn't think that it was worth pursuing as my message was off-topic. I read ietf-announce; there wasn't any notification there. I assumed that there was either something wrong on my end or it could be some glitch which was not worth the bother. IASA stated that: "The IASA defines the service requirements (statement of work, service level agreement)" That information is not publicly available. The message you wrote does not say anything about monitoring. The practical question is whether IETF services are being monitored. This is where the IETF "leadership" answers yes and I look unreasonable for asking more questions. On a lighter note I have been watching too many IETF movies. :-) The nit is why is the IETF still using PDT. Regards, -sm
Re: Mail lost yesterday
Hello, Thanks to Bob Hinden for the quick response. What follows is a general comment. My message was not a report about an operational problem. It was about the lack of a timely notification, and maybe an explanation if anyone deems that appropriate, about these problems to the IETF community. There is question of whether the services are being monitored. There is also the question of the reliability of the services provided to the community. Usage has likely increased since 2007. I hope that the contract has been updated to take all of that into account. Regards, -sm
Mail lost yesterday
Hello, Could whoever from the IETF "leadership" who is responsible for the matter please comment about the mail loss incident? I previously commented about the visibility of IETF services. That aspect of the IETF lacks transparency [1] and leaves it to the user to guess what is wrong at his/her end. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg68755.html
Re: Last Call: (Early IANA Allocation of Standards Track Code Points) to Best Current Practice
Hi Barry, At 09:43 29-08-2013, Barry Leiba wrote: I tripped over the same text, and I suggest rephrasing it this way: NEW The code points must be from a space designated as "Specification Required" (in cases where an RFC will be used as the stable reference), "RFC Required", "IETF Review", or "Standards Action". That looks better. Regards, -sm
Re: Last Call: (Early IANA Allocation of Standards Track Code Points) to Best Current Practice
At 14:52 27-08-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Early IANA Allocation of Standards Track Code Points' as Best Current Practice 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-09-24. Exceptionally, comments may be In Section 2: 'a. The code points must be from a space designated as "Specification Required" (where an RFC will be used as the stable reference), "RFC Required", "IETF Review", or "Standards Action".' I suggest not having the comment (where) and leaving it to RFC 5226 to define "Specification Required". Regards, -sm
Re: Last Call: (A Reputation Query Protocol) to Proposed Standard
Hi Murray, At 01:14 21-08-2013, Murray S. Kucherawy wrote: Ah. I realize that CRLF is standard line termination for SMTP; is it automatically the expected line termination for all line-oriented protocols? I don't know about others. I would have to write a long answer to that question. :-) I haven't had time to test what the draft specifies. Thanks for addressing the comments. Regards, -sm
Re: Last Call: (A Media Type for Reputation Interchange) to Proposed Standard
Hi Murray, At 00:05 21-08-2013, Murray S. Kucherawy wrote: As alluded to above, there can be quite a bit of information needed for an application to be defined beyond the defaults assumed when a name is registered. There didn't seem to be any need to require such definition to be in an IETF document, but it also seems as though more information than what's needed with just FCFS or DE or the other lesser rules is appropriate either. I'll suggest Expert Review here as it is a lesser barrier. I'll defer to you on this. Regards, -sm
Re: Last Call: (A Reputation Query Protocol) to Proposed Standard
At 23:53 20-08-2013, Murray S. Kucherawy wrote: I don't believe so. The only cases we can think of are those where the supported application does or does not exist, and the service being queried does or does not have data about the subject. Elsewhere we describe that there's a specific mechanism to say in a valid reply that no data are available, so that handles the second question. You only get to the second question if the answer to the first is "yes", which leaves the first answer of "no" that needs handling specified. Ok. An operator that calculates reputation values on demand would conceivably give a new value for every query. If a client wants that up-to-the-moment accuracy, then Expires is counterproductive. On the other hand, an operator that calculates reputation values daily could indicate this by setting an Expires field of either a day (86400) or the total time between "now" and the next calculation. The latter case is likely more prevalent, but it doesn't seem like saying "MUST" and requiring a value of 0 for the former case is strictly the right solution. I see what you mean. The server-specified expiration (see RFC 2616) uses other headers as well. Why is that? The media type is "text/plain". A client could support HTTP for the template retrieval but only HTTPS for the service itself, for all the usual privacy and security reasons. Ok. Any URI scheme is supported. Only HTTP/HTTPS are currently implemented at the moment. Ok. That's not "the" angle, it's one possible template. Does it not qualify as a Proposed Standard? If not, why not? Will it fail to interoperate? The quick answer is that I am not sure. I'll defer to you. Regards, -sm
Re: Call for Review of draft-rfced-rfcxx00-retired, "List of Internet Official Protocol Standards: Replaced by an Online Database"
Hi Pete, At 12:01 20-08-2013, Pete Resnick wrote: The IESG and the IAB had an email exchange about these two points. Moving a document from Standard to Historic is really an IETF thing to do. And it would be quite simple for the IETF to say, "We are no longer asking for the 'Official Protocol Standards' RFC to be maintained" by updating (well, effectively removing) the one paragraph in 2026 that asks for it, and requesting the move from Standard to Historic. So I prepared a *very* short document to do that: http://datatracker.ietf.org/doc/draft-resnick-retire-std1/ I read the draft. I agree with what is written above. I'm asking Jari to Last Call it along with a status change for STD 1 (RFC 5000) to Historic. If the RFC Editor wants to explain more of the history and whatever else they're going to do in a separate document, that's up to the IAB. But declaring Standards to be Historic is something the RFC Editor or IAB shouldn't be doing. The above document solves the problem by making it clear that the IETF isn't interested in the document being updated anymore. I support moving the draft to Last Call as it solves the problem. Regards, -sm
Re: Academic and open source rate (was: Charging remote participants)
Hi John, At 06:11 19-08-2013, John C Klensin wrote: I think this is bogus and takes us down an undesirable path. Ok. First, I note that, in some organizations (including some large ones), someone might be working on an open source project one month and a proprietary one the next, or maybe both concurrently. Would it be appropriate for such a person (or the company's CFO) to claim the lower rate, thereby expecting those who pay full rate to subsidize them? Or would their involvement in any proprietary-source activity contaminate them morally and require them to pay the full rate? Second, remember that "open The above reminds me of the Double Irish with a Dutch sandwich. If I was an employee of a company I would pay the regular fee. If I am sponsored by an open source project and my Internet-Draft will have that as my affiliation I would claim the lower rate. source" is actually a controversial term with some history of source being made open and available, presumably for study, but with very restrictive licensing rules associated with its adaptation or use. Yes. Does it count if the open source software is basically irrelevant to the work of the IETF? Written in, e.g., HTML5? Do reference implementations of IETF protocols count more (if I'm going to be expected to subsidize someone else's attendance at the IETF, I think they should). This would require setting a demarcation line. That isn't always a clear line. A subsidy is a grant or other financial assistance given by one party for the support or development of another. If the lower rate is above meeting costs it is not a subsidy. Shouldn't we be tying this to the discussion about IPR preference hierarchies s.t. FOSS software with no license requirements get more points (and bigger discounts) than BSD or GPL software, which get more points than FRAND, and so on? No. :-) Regards, -sm
Re: Academic and open source rate
Hola Arturo, At 07:34 19-08-2013, Arturo Servin wrote: Academic might work. "Open source" not so much as other mentioned. Does "Big Corporation" doing Open Source apply? I was tempted to propose "non-profit", but also there are organizations with large budgets. And profit driven ones with not much money. "Open source" is difficult. As people pointed out "open source" does not necessarily mean free. "open source" does not necessarily mean "non-profit". I used the term loosely. If hypothetically speaking, there was formal action, a clearer term might be needed. Irrespective of my views, "big corporation" is what helps the IETF operate. If "big corporation" doing open source applies it will become a problem for the IETF. The main issue is why should the IETF subsidize a particular group. It can also be argued that it is not fair to subsidize a particular group. Regards, -sm
Re: Academic and open source rate (was: Charging remote participants)
Hi Hadriel, At 05:33 18-08-2013, Hadriel Kaplan wrote: Define "open source developers". Technically quite a lot of developers at my employer develop "open source", as do many at many of the corporations which send people to the IETF. Heck, even I personally submit code to Wireshark now and then. Distinguishing between "Self-paying" vs. "Expensing" is pretty easy. "Open source" vs. "Closed source" is a big can of worms. I'd love to get more developers in general to participate - whether they're open or closed source doesn't matter. But I don't know how to do that, beyond what we do now. The email lists are free and open. The physical meetings are remotely accessible for free and open. On reading the second paragraph of the above message I see that you and I might have a common objective. You mentioned that you don't know how to do that beyond what is done now. I suggested a rate for people with an open source affiliation. I did not define what open source means. I think that you will be acting in good faith and that you will be able to convince your employer that it will not make you look good if you are listed in a category which is intended to lessen the burden for open source developers who currently cannot attend meetings or who attend meetings on a very limited budget. We can discuss about whether a few hundred United States dollars makes a significant difference or we can sit by a pool and discuss about more interesting things. Your colleagues will probably wonder why you brought more value to your company compared to them. You could tell them that it is because you like strawberry ice cream as it is something that wills the void between rational discussion and all-out thermonuclear war. :-) At 08:50 18-08-2013, Hadriel Kaplan wrote: I've been told, though obviously I don't know, that the costs are proportional. I assume it's not literally a "if we get one additional person, it costs an additional $500". But I assume SM wasn't proposing to get just one or a few more "open source developer" attendees. If we're talking about just a few people it's not worth arguing about... or doing anything about. It would only be useful if we got a lot of such attendees. What I proposed might have an impact on just one or a few more persons. The rest is left to the imagination of the reader. :-) Regards, -sm
Academic and open source rate (was: Charging remote participants)
Hi Hadriel, At 12:31 16-08-2013, Hadriel Kaplan wrote: I may be misunderstanding you, but I'm proposing we charge "large corporations with large travel budgets" slightly *more* than others.[1] I'm not suggesting an overhaul of the system. I'm not proposing they get more attention, or more weight, or any such thing. That sounds like the ability to pay. It might be worth considering changing the student rate to an academic and open source rate and doubling the rate. I am not getting into a definition of "academic" or "open source" [1]. It is left to the organization to determine whether it is a good idea to be honest or try the weasel words [2] approach. Regards, -sm 1. If the IETF is serious about running code (see RFC 6982) it would try to encourage open source developers to participate more effectively in the IETF. 2. weasel words give the impression of taking a firm position while avoiding commitment to any specific claim.
Re: Call for Review of draft-rfced-rfcxx00-retired, "List of Internet Official Protocol Standards: Replaced by an Online Database"
At 11:48 14-08-2013, IAB Chair wrote: This is a call for review of "List of Internet Official Protocol Standards: Replaced by an Online Database" prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-rfced-rfcxx00-retired/ From Section 2.1 of RFC 2026: 'The status of Internet protocol and service specifications is summarized periodically in an RFC entitled "Internet Official Protocol Standards".' My guess is that draft-rfced-rfcxx00-retired cannot update RFC 2026. Does the IAB have any objection if I do something about that? From Section 3: "This document formally retires STD 1. Identifier STD 1 will not be re-used unless there is a future need to publish periodic snapshots of the Standards Track documents (i.e., unless the documentation is resumed)." The document argues that STD 1 is historic as there is an online list now. The above reserves an option to restart periodic snapshots if there is a future need. I suggest removing that option as I presume that the IAB has thought carefully about the long term evolution of the Series before taking the decision to retire STD 1. Regards, -sm
Re: Last Call: (A Model for Reputation Reporting) to Informational RFC
At 07:45 15-08-2013, The IESG wrote: The IESG has received a request from the Reputation Services WG (repute) to consider the following document: - 'A Model for Reputation Reporting' 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-08-29. Exceptionally, comments may be The Privacy Considerations Section focuses on data in transit and collection of data only. Section 8.1 mentions protecting the data from "unauthorized access and viewing". That would only be unauthorized viewing while the data is in transit. I don't know whether people overlook this; the queries leak out information. Information which the user might consider as private is sent out without the person's knowledge. I suggest pushing that discussion to the specification which defines the identity (e.g. draft-ietf-repute-email-identifiers-08). As a general comment I would say that the issue is less about privacy and more about reputation. There is a saying: Tell me what you read and I will tell you who you are. Regards, -sm
Re: Last Call: (A Media Type for Reputation Interchange) to Proposed Standard
At 07:44 15-08-2013, The IESG wrote: The IESG has received a request from the Reputation Services WG (repute) to consider the following document: - 'A Media Type for Reputation Interchange' 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 ietf@ietf.org mailing lists by 2013-08-29. Exceptionally, comments may be From Section 3.1: "expires: A timestamp indicating a time beyond which the score reported is likely not to be valid. Expressed as the number of seconds since January 1, 1970 00:00 UTC. See Section 5 for discussion." And Section 5: 'A reputon can contain an "expires" field indicating a timestamp after which the client SHOULD NOT use the rating it contains, and SHOULD' The "expires" field uses "HTTP-date". It is easier to code for one timestamp format instead of two (see Unix timestamp in Section 3.1). In Section 3.1: "An application service provider might operate with an enhanced form of common services, which might in turn prompt development and reporting of specialized reputation information." I don't see anything actionable in the above. Why was "specification required" chosen for the Reputation Applications Registry? Regards, -sm
Re: Last Call: (A Reputation Response Set for Email Identifiers) to Proposed Standard
At 07:43 15-08-2013, The IESG wrote: The IESG has received a request from the Reputation Services WG (repute) to consider the following document: - 'A Reputation Response Set for Email Identifiers' 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 ietf@ietf.org mailing lists by 2013-08-29. Exceptionally, comments may be draft-ietf-repute-model is a down-ref. I suggest referencing the updated SPF specification as that specification is said to fix some issues in RFC 4408. Why is DKIM and SPF normatively referenced while SMTP is an informative reference? Section 5 states that the draft "is primarily an IANA action and doesn't describe any protocols or protocol elements". Why is the intended status "Proposed Standard"? Regards, -sm
Re: Last Call: (A Reputation Query Protocol) to Proposed Standard
At 07:41 15-08-2013, The IESG wrote:
The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Reputation Query Protocol'
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
ietf@ietf.org mailing lists by 2013-08-29. Exceptionally, comments may be
The draft-iet-repute-model reference is a down-ref.
"A server receiving a query about an application it does not
recognize or explicitly support support (e.g., by virtue of
private agreements or experimental extensions) MUST return a
404 error code."
There is a typo: "support support".
Are there other cases where a 404 is appropriate? I am asking the
question as there is a string of proposals built upon RFC 2616 which
attempt to use HTTP status codes to communicate errors for the
layered protocol.
In Section 3.2:
"and SHOULD include an Expires field (see Section 14.21 of [HTTP])
indicating a duration for which the template is to be considered
valid by clients and not re-queried."
Why is this a RFC 2119 SHOULD? There is a "SHOULD NOT" following
that paragraph with a "don't query for a day if there isn't an
Expires field". Wouldn't it be easier to have "MUST include the
Expires field"?
"The template file might contain more than one template. Such a file
MUST have each template separated by a newline (ASCII 0x0D)
character."
As this is line oriented it may be better to have CRLF.
In Section 3.3:
"A server SHOULD include support for providing service over HTTP"
Is there a case where the service with work if the server does not
support HTTP?
In Section 5:
"The reputation service itself will use HTTP or other transport
methods to issue queries and receive replies. Those protocols have
registered URI schemes and, as such, presumably have documented
security considerations."
This is odd. What other protocols are there to retrieve the URI template?
If I understood the draft, the Proposed Standard angle is:
http://{service}/{application}/{subject}/{assertion}
with a "application/reputon+json" response. Why should that be a
Proposed Standard?
Regards,
-sm
What RFC 2026 says (was: Last Call:
At 09:25 10-08-2013, Ted Lemon wrote: Fair point. RFC2026 does not in fact make the distinction I made. Here is what RFC 2026 says about proposed standards: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. RFC 2026 also says that "Implementors should treat Proposed Standards as immature specifications". Specifications are rarely retracted. The community would not agree to retract an Experimental document. Trying to do that with a Proposed Standard is madness. :-) Here is what it says about Informational documents: An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). There is a bug in the above. I prefer to avoid quoting RFC 2026 nowadays as nobody really knows what RFC 2026; or to say it differently, the consensus is that there isn't any consensus about RFC 2026. At 11:46 10-08-2013, Eliot Lear wrote: There is an architectural question hiding here: when we use CBOR in Note that I did selective quoting. There is a belief that someone would have thought about the architectural question. After seeing such questions being ignored or seeing the blank stares in response to an architectural question I prefer not to even ask about that. It is difficult to find the right answer to architectural questions. One can only wonder how many people read RFC 1958 before writing a draft. Padlipsky's Law states that: To The Technologically Naive, Change Equals Progress; To Vendors, Change Equals Profit. I would read The Relevant Literature instead of RFC 2026. Regards, -sm
Re: Last Call: (Security Services for the Registration Data Access Protocol) to Proposed Standard
d the latter at least is normally a standards track document. I personally think that there is a lack of understanding of what an applicability statement is. I commented on the draft from a technical specification angle. I don't know what "thinking about security" we are expected to do beyond making use of the security services that have already been made available to applications built atop HTTP. Do you have any specific suggestions? It is a lot of work to explain or suggest text. It's not worth putting in the effort if the working group believes that the draft is okay. Regards, -sm -MSK
Re: procedural question with remote participation
At 13:10 04-08-2013, Hadriel Kaplan wrote: OK, I'll bite. Why do you and Michael believe you need to have the slides 1 week in advance? One generation's bad behavior becomes the next generation's best practice. It would be appreciated if those slides could be made available in advance. You have the agenda and drafts 2 weeks in advance. The slides aren't normative. Even I do not have the agenda two weeks in advance. Nowadays, there are "if time permits" slots in addition to A.O.B. What is the meaning of "normative" in the above? If you need to have them on the website 7 days in advance, you really need to get a faster Internet connection. ;) Ok. :-) At 14:27 04-08-2013, Hadriel Kaplan wrote: What *would* be good to have 7 days or more in advance are the Technical and O&A Plenary slides. They shouldn't be changing, afaict. And that way we can figure out if we can have those nights free for other things, or if it's worth going to the Plenaries instead. But I assume those slides already are made available well in advance. (right?) The Technical and other Plenary slides are not made available well in advance. Someone asked the following question: "Does she have a clue that she just asked for feedback from an audience that can't see the link she put on the screen?" There was a discussion about beer from the tap after that. Please open a new thread if you would like to discuss about that. :-) At 15:21 04-08-2013, Stephen Farrell wrote: And only something potentially disastrous ought imply even considering a zero-tolerance anything in a volunteer organisation. It is after all a volunteer organisation. I hope that people were not surprised that I did not ask for the Spice Girls session to be cancelled. At 15:41 04-08-2013, Hadriel Kaplan wrote: Do you find this is an actual problem in WG meetings? Are the jabber scribes not able to tell you who is at the mic if you ask them? People have forgotten to state their names Some of the Jabber scribes are not able to tell me who are at the microphone when I ask them. If it was my decision to make (and it is not), the Jabber scribe would be allowed to comment at the microphone even after the microphone line is capped. A person can always argue that it is an arbitrary decision. :-) As an off-topic comment, it's not because the Meetecho people are nice that one should expect them to act as Jabber scribes. At 18:36 04-08-2013, Hadriel Kaplan wrote: But for the general case, the truth is that Fuyou Maio is right - you really do need to be able to parse English quickly to truly participate effectively in an IETF physical meeting. And you need to be reasonably swift in either reading it, or following the speaker's words. It's not nice to say, but it's the truth. Real-time direct human communication is why we have the physical meetings to begin with, instead of only mailing lists and virtual meetings. (and for cross-wg-pollination, and for cookies) Yes. Some sessions are easy to follow. For example, I read some slides posted a few days before and I had an idea of what would be discussed. I looked for the slides for a BoF as it was not clear to me what one of these items on the agenda was about. The slides were not available. I didn't bother asking about them. The correct question would have been about the item on the agenda instead of the slides. Regards, -sm
Re: 6tsch BoF
Hi Ted, At 05:47 03-08-2013, Ted Lemon wrote: Do you think I said something that contradicts what Brian said? I believe that I agree with him. But he's talking about how you ultimately determine consensus, whereas I was talking about what hums and shows of hands mean, and in what way they are useful. I don't think that Brian was talking about how you ultimately determine consensus. Here is the last paragraph of Brian's message: "In the case of a WG-forming BOF, it seems to me that a nucleus of people willing and competent to do the work, and a good set of arguments why the work needs to be done and how it will make the Internet better, are more important than any kind of numbers game." That one sentence covers all the points which are relevant. It's an Area Director decision. It does not require consensus or any kind of number game. Regards, -sm
Re: [Trustees] The Trust Agreement
Hi Chris, At 23:56 02-08-2013, Chris Griffiths wrote: I just replied to Brian's email, and also requested that Jorge Contreras (CC'd) weigh in with his legal review on this matter. Please let me know if you need any further details. I'll wait for Jorge Contreras's comments. While I cannot speculate if we will need to register new domains or trademarks, there are some that have already been registered that the trust must continue to maintain indefinitely that we would prefer to see lapse. The current state of having to hold onto them indefinitely seems impractical and requires the trust to go through efforts to maintain these every few years when they are most likely not needed. I guess that the problem is "must continue to maintain indefinitely". My (uninformed) understanding is that the IETF Trust has to take reasonable steps to maintain the value of a thing. It would be very difficult to claim that the IETF Trust has taken unreasonable steps in not maintaining a thing which does not have any value. Regards, -sm
Re: The Trust Agreement
Hi Chris, At 13:59 01-08-2013, Brian E Carpenter wrote: Re the Trust's plenary slides (I was not in Berlin): I have an allergy to modifying the Trust Agreement unless there's an overwhelming reason to do so. It was a very hard-won piece of text. > Issue #1 > We have recently been asked permission to > republish the TAO with a creative commons > license, but unfortunately the current trust > agreement does not give the trustees the > rights to do this It doesn't? You have the right to license "existing and future intellectual property" according to clause 2.1 of the Trust Agreement. Is there some particular property of the CC license that causes a problem? I was told during the JSON chartering that relicensing of the specification was not a problem. I would appreciate some feedback on the questions from Brian Carpenter. > Issue #3 > Once a domain name or trademark is > registered by the trust, it cannot be > abandoned even if it is no longer needed > We must maintain these in perpetuity IANAL, but it isn't clear to me that clause 9.4 forces you to do this. It requires you to "take reasonable steps" and to file applications "as the Trustees deem necessary in order to maintain and protect the Trust Assets." If you decide (and minute) that it isn't reasonable or necessary to maintain veryolddomainname.org, where's the crime? The IAOC decided to register a domain name. It wasn't well-thought in my humble opinion. Anyway, I don't see why there will ever be a need for a new domain. As for trademarks, well, I don't see why the IETF needs more of them. Regards, -sm
Re: 6tsch BoF
Hi Ted, At 08:00 01-08-2013, Ted Lemon wrote: We actually had a talk about this amongst several IESG and former IESG members. I am not going to Bernard Aboba once mentioned: To paraphrase Tilda Swinton's Oscar Acceptance Speech: "To the IESG, you know, the seriousness and the dedication to your art... you rock, man!" report the results, because I might remember them wrong, but my thoughts on this are as follows: - The hum is not a means of determining consensus; it is a means of determining the sense of the room. If the hum is clearly many in favor, nobody against,then you have consensus, but that's unusual. If the hum shows many in favor and some against, you need to go to the next step, because you do not yet know whether you have consensus. - So since the hum was quite inconclusive, the next question is, "can somebody who objects please say why." One way to approach that is to ask for a show of hands. Here, the chairs could have asked for a show of hands againstthe show of hands for was unnecessary. But this is forgivable, I think, unless you think people were intimidated by the show of hands for. I think that would be hard to argue, given that they had already heard the result of the hum. - So the show of hands against elicited no hands. I was there, that's what I remember seeing too. So at this point, what do you do? Nobody is willing to stand up and say "I think we shouldn't go forward with this because of X." Many people have said "we think we should go forward with this, support doing this, and want to participate." To me, that's consensus. The above comment about consensus is an opinion. :-) In my opinion part of the answer has been provided by Brian Carpenter. The other part of the answer is the minutes. The rest of the answer is in something mentioned in the Note Well. Regards, -sm
Protecting the disclosure of the identity (was: Loud humming is subject to cultural bias)
Hi Andy, At 09:26 01-08-2013, Andy Bierman wrote: I meant that it is difficult to remain anonymous when the email to the WG has your email address in it. Agreed. Perhaps you can point me to the RFC 2026 text (or other RFC) that says something about protecting the disclosure of the identity of the person expressing agreement or disagreement with some question asked in a WG meeting. I read RFC 2026 quickly. I did not find any text about protecting the disclosure of the identity of a person. I read another RFC which was about a WG meeting. It states that there are requirements for disclosure of conflicts of interest. I did not find any text about protecting the disclosure of the identity of the person. Regards, -sm
Re: 6tsch BoF
Hi Ralph, At 01:50 01-08-2013, Ralph Droms wrote: Toward the end of the BoF, the chairs asked the question "1. Is this a topic that the IETF should address?" First, the chairs asked for a hum. From my vantage point (middle of the room), the hum was pretty close to equal, for/against. I reviewed the audio (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, starting about 1:22), and heard a slightly louder hum "for". The BoF chairs decided they needed more information than they could extract from the hum, so they asked for a show of hands. From the audio record, there were "a lot" for (which matches my recollection) and "a handful" against (my memory is that no hands showed against). There was a request to ask for a show of hands for "how many don't know". The question was asked, and the record shows "a dozen". Switching from hums to votes is not a good idea. The above could be because: (a) The question asked was incorrect. (b) The choices provided were incorrect. So, there was apparently a complete change in the answer to the question based on humming versus voting. There may also have been some effect from asking, after the fact, for a show of hands for "don't know". I'm really curious about the results, which indicate that, at least in this case, the response to the question is heavily dependent on the on the mode used to obtain the answers to the question (which we all know is possible). In particular, the effect of humming versus show of hands was pretty obvious. draft-resnick-on-consensus gives several reasons why humming is preferred over a show of hands. From this example, it seems to me to be worth considering whether a more honest and accurate result is obtained through humming rather than a show of hands. Your message does not provide enough context. The simple explanation is that the vote was used to change the answer. Consensus is a process, i.e. there are steps which are carefully followed until everyone is okay with the choices which they are provided with. In case of doubt, hum. The other question raised in my mind is why the initial result from the hum, which did not have a consensus either way, was not sufficient. "Roughly the same response" for/against the question would seem to me to be as valid a result as explicit consensus one way or the other, and the act of taking a show of hands to survey the appeared to treat the hum as irrelevant, rather than highly significant. The first result was sufficient. A second try, whether it is a hum or a vote, creates an appearance that the decision-maker did not like the result and is trying to change it. A decision can be undermined by people conforming to what other people in the group think. Regards, -sm
Re: PS to IS question from plenary
Hi Dave, At 14:11 30-07-2013, Dave Crocker wrote: And, of course, if it "can" be reshashed, in the IETF it will be. Agreed. However the specification for the new two-stage model provides criteria for the second stage, and it does not include re-evaluating the technology or its details. Instead it focuses on adoption and use. RFC 5011 is one of the rare RFCs which does not have any erratum. The move wasn't problematic. It is not clear whether RFC 6891 is an odd case or symptomatic of the difficulties in updating a specification. The easier way not to have a re-evaluation is not to reopen the RFC (e.g. RFC 5011). Anything else means having two consensus calls on the text. draft-bradner-restore-proposed-00 proposes an alternative where the specification is not expected to be complete and comprehensive. Here's a minimum standards profile published in 2009: SMTP IETF STD 10 (RFC 821, 1869, 1870) DNS IETF STD 13 (RFC 1034, 1035) HTTP v1.1 (RFC 2616), URL (RFC 1738), URI (RFC 2396) IPv4 (RFC 791, 792, 919, 922, 1112) BGP4 (RFC 1771) The ex-IAB Chair explains that RFC 1035 is an Internet Standard. He then explains that an Experimental Standard (RFC 1183) updates that Internet Standard. The Internet Standard is updated by a Best Current Practices (RFC 6895). There is also a Proposed Standard ( RFC 1982) which updates the Internet Standard. He recommends RFC 2026 for further information. He receives an enquiry afterwards about immature specifications. He decides to ask the question at the plenary. The community thanks him for his valiant efforts. The alternative is to settle for Informational Standards as that requires less effort. Regards, -sm
Re: PS to IS question from plenary
At 11:27 30-07-2013, John C Klensin wrote: Disclaimers and possible small classification errors aside and being careful to avoid making causal assumptions, I believe that the implication of the above is that there is no evidence that the 3 -> 2 transition has increased the number of documents being moved or promoted out of Proposed Standard. If one were to assume a causal relationship and an absence of external confounding variates or processes, one might even conclude the the 3 -> 2 transition has made things quite a lot worse. Conversely, it seems to me that one could argue that the change has made things better only by demonstrating the existence of a process that would have led to considerably fewer than four documents being moved out of Proposed Standard in the last 22 months in the absence of the change. "Changing the Internet Standards Process from three maturity levels to two is intended to create an environment where lessons from implementation and deployment experience are used to improve specifications". The change could be rated as a non-change if there were only four specification moved to Internet Standard since then. The hurdle in moving a specification (not a RFC) from PS to IS is that the draft goes through IESG Evaluation again. As for public review, it can be a hurdle too as the pervious discussions can be rehashed. A PS specification which sticks to what goes over the wire turns these hurdles into a lesser effort. draft-bradner-restore-proposed-00 proposes a nice fix and it might even help lessen time to publication. Regards, -sm P.S. Olaf asked the question to the correct body.
Re: setting a goal for an inclusive IETF
Hi Jari, Pete, At 06:53 30-07-2013, Jari Arkko wrote: We have discussed diversity at the IETF at length. Yesterday, Pete Resnick and I wrote an article about what we think the goal for the IETF should be, as well as listing some of the early activities that we have taken at the IETF. Our goal is making the IETF more inclusive for everyone who needs to be working on Internet standards. We are at the beginning, however, and a lot of work remains ahead. Here's the article: I agree that the word "diversity" is a catch phrase. There was an exchange between Leaf Yeh and Ted Hardie on this mailing list. It is encouraging to see people from different sides of the world having an exchange of opinions. It's been one IETF meeting since several women spoke at the microphone during the plenary. There aren't that many people from different countries speaking at the microphone during a plenary. I have one question. The subject line says "setting a goal". How would you assess the results? Please note that I am not asking about how to measure the results. Regards, -sm
Re: Remote participants, newcomers, and tutorials
At 22:25 28-07-2013, Dave Crocker wrote: I've been finding discussion and actions about newcomers far more interesting this year, than most previous ones. So I think it's worth pressing on several fronts, to see how we can both accommodate such folk better, as well as be clear about when and where and how such accommodation is /and is not/ appropriate. The keyword in the above is "actions". Some actions do not require the agreement of the entire IETF. In other words, an action does not require consensus if it is not mandatory. Your reply to me, above, lists different types of new folk -- and of course the list is reasonable and might be useful -- but I didn't see the actual clarification of what you felt was wrong in the target text or how you agreed with me an others. So, now you've got me curious for that detail... A public discussion can be started with: (a) I will be listening to your comment. (b) You must have read X, Y, and Z before you comment. (c) Be sure that you are not wasting my time when you comment. I'll argue that (b) and (c) are trying to stop problems before they happen. (b) looks like the type of thing which ought to be explained during the orientation. (b) is not a problem caused by remote participants as it is possible to provide an explanation through the Jabber room. (c) is intimidating. I would choose (a). My suggestion is for a 'status' page that gives a brief summary about the current state of the working group, ideally listing the current, near-term vector of the work -- what's the current focus of effort -- and major open issues. I'll suggest that it be updated after every meeting. Arguably, this sort of status statement is good to have even without newcomers, since it forces working groups to face the question of what progress they are and are not making. The simpler form might be to update the milestones so that anyone can read about the work the working group is planning to do and when it is planning to do it. It also provides information about the work that the working group has completed. On the topic of remote participation I'll mention that the current approach is to open a trouble ticket when there is a problem. A status web page could provide some visibility about whether the services are running correctly, whether there is a known problem, etc. Notifications could be sent to xmpp:hall...@jabber.ietf.org so that people do not hit the reload button repeatedly. Regards, -sm
Re: Remote participants, newcomers, and tutorials
As an off-topic note, thanks to Alexa, Alexey, Jari, Lorenzo and the Meetecho team. At 16:52 27-07-2013, Aaron Yi DING wrote: What do you mean by conference? too much information inferred in your term that may confuse others on the list. Will appreciate, if you can share bit more on it, behind the single term "conference" that you particularly don't like. I took a quick look at some session agendas. The common format is: - Name of draft - Presenter That looks like a conference to me. There will be the usual Powerpoint presentations. People can object to that on this mailing list but the fact is that these presentations will happen. PS: things evolve, over the long term. it does not matter we like it or not. that is how it is. Yes. At 00:33 28-07-2013, Marc Petit-Huguenin wrote: What about people who have difficulties understanding the speaker without some sort of context? It helps to provide some context before discussing the issue. I would not expect cross-area input if I do not provide context. Sometimes it is difficult to understand the speaker. The written form, for example slides, can help. What about being able to understand the problem that will be discussed before the session, so to cut on the "thinking out loud" on the microphone? That is where the agenda can help. The name of the draft does not tell me about the issues that will be discussed. Regards, -sm
Re: Remote participants, newcomers, and tutorials
At 14:01 27-07-2013, Jari Arkko wrote: Let me clarify why I thought it was wrong. I don't think I'm disagreeing with you, I'll reorder the end of the original message. Jari (the guy who is preparing for the possibility - no matter how remote - that the cool kids might actually teach us a trick or two) :-) If there is a possibility, however remote, that someone, irrespective or age or any other attributes, can teach me something I believe that it is worthwhile to be open to that. Yes, it may have been tried before. And yes, there is a history of failure. However. Newcomers are not all alike. The student coming here to observe the IETF. The researcher who understands the field we are embarking on. The colleague that has been implementing The Protocol for the last two years in the office, but is now coming to the IETF for the first time. The guy who has something to say about the operational experience of our results. The team who brought their idea to the IETF to be standardised. And so on. I do not equate new to the IETF with beginner. The student may be someone writing code. The person may know that for all its fancy words what's in the draft won't work as he or she tried that. The operator knows that whatever the RFC says it is not possible to follow that due to operational constraints. A guideline is not a good one if it will have a chilling effect (motivate people not to speak up). Regards, -sm
Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info)
At 23:17 26-07-2013, Jari Arkko wrote: The second quote is valid in most cases, though we've had some sessions at times that were designed more as education than discussion. For instance, the IAB WCIT BOF last time. The following will be discussed in the DMARC BoF: "a mechanism for protecting the portion of the RFC5322.From field" My guess is that it might be educational. :-) I read the second quote as meaning that a WG session is not a how-to or a tutorial. It might be help people understand if it is explained during the orientation session. But the first one is just plain wrong. Is this from RFC 3184? Many of the first time IETFers are Yes. Regards, -sm
Re: Oh look! [Re: Remote participants, newcomers, and tutorials]
At 15:10 26-07-2013, John C Klensin wrote: However, the IETF has been having a lot of discussions about newcomers, diversity, and attracting new folks to participate and get work done. I think those populations will be better served if it is possible for people a lot less experienced than the two of us can participate actively and constructively without attending every meeting. I also think that, especially for many people from developing countries, universities, small companies, and far-away places, we will be far more successful in recruiting if we can encourage remote participation as a starting point with the expectation of getting people physically to meetings only after the value to them and their organizations of doing so has been demonstrated. I'd personally even favor making remote participation at a could of meeting be a prerequisite for most applications for ISOC's IETF Fellows program. Discussions that do not translation into actions are, well, discussions. What is the easiest to enable the person from the university participate in the IETF meeting; what is the easiest way to enable the person from the small company to participate in the IETF meeting? It is: (a) an audio stream (b) a jabber service (c) a jabber scribe (a) and (b) are already available. (c) is doable. Will there be any results from that? No. Why should the IETF do that then? Because it is simple, it is cheap, and if it works, who knows, there may be results. But the above picture isn't going to happen unless we are serious and treat that seriousness as an integral part of our strategies about newcomers and diversity. Seriousness to me says that we get more careful about how experienced one has to be to find critical information, that we make sure remote participation works, and that we make any session that would be relevant to remote participants accessible to them (and with materials available as much as possible in advance and from easy-to-find places). Seriousness implies that, if there are extra costs, we figure out how to cover them (or how to cut somewhere else). Making information available is a first-step in getting things to work. Please note that I do not see that as publishing some random web page. I see that as making the information readily available to the target audience. I'll quote part of a message from Benoit Claise: 'Let me explain what the targeted audience is for those posters. It's not intended for the people who know about a specific BoF and plan on participating. It's intended for people who have not prepared for a specific BoF, but just come to listen to it, and in the end, go to mic. to provide some useful feedback: "pay attention to this!", "similar work was done ...", "don't forget that ...", "don't forget OPS" ;-)' It is a down-to-earth explanation about how to get people interested in a specific BoF. Two years ago (minus one day) Brian Carpenter objected to the fact that the regular audio streaming is not available for the plenaries. The link for the technical plenary audio stream is not available in the (tools) agenda. Or, if we are not serious, it would probably be to the benefit of the community for us to face that and stop wasting energy and resources on outreach efforts that are expensive in one or the other (or both). It is a waste of energy and money to pursue outreach efforts if the IETF is not serious about how to lower the barriers for newcomers and its strategy about diversity. Regards, -sm
Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info)
Hello, At 08:32 26-07-2013, John C Klensin wrote: For this particular meeting all of the following seem relevant to at least some remote participants: [snip] with subscribing to the 87all list. It should no involve a treasure hunt at which only very experienced IETF participants can be expected to succeed. It would be helpful to new people if everything in the IETF was not a treasure hunt or required an email broadcast for a person to find information. The consensus of the IETF is that: "newcomers who attend Working Group meetings are encouraged to observe and absorb whatever material they can, but should not interfere with the ongoing process of the group" It was also mentioned that: "Working group meetings are not intended for the education of individuals" The first quote might discourage newcomers from participating. I suggest discussing about the two quotes during the orientation as they could be misunderstood. Specific suggestions: (i) Let's get these open Sunday sessions audiocast and/or available over Meetecho or WebEx. If that is impossible for IETF 87, it should be a priority for IETF 88 and later. Yes. POSH has not published a session agenda. However, the BoF is listed on the meeting agenda. Is the BoF cancelled or will this be one of those willful violations of IETF Best Current Practices? Regards, -sm
Do you want to know what it is?
Hi Jose, As I would like to know what it is I watched http://www.youtube.com/watch?v=QAnW9HTkbsI It was a pleasant surprise to see a new approach instead of the usual boring presentations. People who are old might feel left out though. :-) Here a quote from Jack Haverty: "If you always win, it means you're not taking enough risks." The IETF might say that it does not scale [1]. Who am I to prove that the IETF is wrong? :-) Regards, -sm 1. People who are old will actually understand the quote.
Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
Hi Christer, At 13:54 24-07-2013, Christer Holmberg wrote: Why couldn't remote participants register to the meeting like all other participants? Remote participation would of course still be free, but it would allow remote participants to subscribe to the attendee list in the same way as other participants. A quick scan of that list shows the following topics: - coffee, sims - mailing list for IETF women and the following comment: "I'm not sure why I should be required to give my contact information to get a document prepared by the Brussels airport for Brussels passengers." In addition, it would provide better knowledge to IETF about the number of remote participants, where they are physically located (which might be useful input when planning future meeting locations) etc. I doubt that the IETF chooses its meeting location based on where the remote participants are located. I'll go off-topic first. Mr Reschke once asked "I was just trying to understand *why* the archive can't be at <http://www.ietf.org/tao/archive>". Mr Housley replied that "I was told that we cannot have http://www.ietf.org/tao directed to the document and also be the directory containing the archive directory". Mr Hansen provided some technical details about how that can be done. The point here is it might be better to have a good answer as some IETF participant might deconstruct the answer and find the flaw in it. Mr Klensin's message was about how to find out about the 87all mailing list. Participants within the inner circle know how to find it. The rest of the participants will not be able to find that information as it is not easily accessible through the www.ietf.org web site. There is probably a lack of information about what information is provided through the ietf-announce@ mailing list. Regards, -sm
Re: Last Call: (Security Services for the Registration Data Access Protocol) to Proposed Standard
At 16:06 15-07-2013, The IESG wrote: The IESG has received a request from the Web Extensible Internet Registration Data Service WG (weirds) to consider the following document: - 'Security Services for the Registration Data Access Protocol' 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 ietf@ietf.org mailing lists by 2013-07-29. Exceptionally, comments may be According to Section 1, the Registration Data Access Protocol is a Lookup Format, JSON Responses and HTTP usage. This looks like a weird protocol to me. If the said protocol is HTTP + JSON (responses) it would be clearer to the reader to explain that in one specification. Section 1 mentions that: "One goal of RDAP is to provide security services that do not exist in the WHOIS" I don't see how adding a fourth document helps to achieve that goal. In Section 3.1: 'To that end, RDAP clients and servers MUST implement the authentication framework specified in "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617].' This draft refers to the above authentication framework as the RDAP authentication framework. The draft then explains how the "basic" and "digest" schemes work. This is "how-to" stuff. The draft sets the following requirement: 'If the "basic" scheme is used, HTTP Over TLS [RFC2818] MUST be used to protect the client's credentials from disclosure while in transit (see Section 3.4).' If I understood correctly HTTPS is needed for security only if the "basic" scheme" is used. "RDAP SHOULD be capable of supporting future authentication methods defined for use with HTTP." That sounds like a "SHOULD CONSIDER". Given how ill-defined the protocol is I doubt that the above is actionable. In Section 3.1.1: "RDAP MAY include a federated authentication mechanism that permits a client to access multiple RDAP servers in the same federation with one credential." Using an upper-case "may" does not bring much in terms of security. The draft takes the stance that security is an optional feature. Section 3.1.1 looks like an executive summary for federated authentication. In Section 3.3: "An RDAP service has to be available to be useful. There are no RDAP- unique requirements to provide availability, but as a general security consideration a service operator needs to be aware of the issues associated with denial of service." The text says that the service must be available to be useful and that there isn't any requirement for the service to be available. In Section 3.4: "Web services such as RDAP commonly use HTTP Over TLS [RFC2818] to provide that protection by encrypting all traffic sent on the connection between client and server." The above describes the protocol as a web service. "When this scheme is used, HTTP Over TLS MUST be used to protect the client's credentials from disclosure while in transit.' The above repeats a "MUST" mentioned in a previous section. In Section 5: "RDAP might need to be extended to provide this service in the future." This does not look like a security consideration. "Code injection refers to adding code into a computer system or program to alter the course of execution." I can only wonder about who is the target audience after reading the above. The security considerations section seems like an attempt to write something about security as there isn't nothing to say about the protocol. Overall, the draft does not look like a technical specification. It looks like the working group took FYI 36 as a template for designing a security service instead of thinking about security and designing a security service. Regards, -sm
Re: Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard
n this section as they will be in common use by servers." I don't understand the "SHOULD understand". From the Security Considerations section: "This document does not pose strong security requirements to the RDAP protocol." I read the about as meaning that the unspecified RDAP protocol does not need strong security requirements. "Additional security considerations to the RDAP protocol will be covered in future RFCs documenting specific security mechanisms and schemes." I assumed that security considerations was about considering security concerns and discussing about them. The above leaves that to future RFCs. In Section 9.1: "Clients can use IRIs [RFC3987] for internal use as they see fit, but MUST transform them to URIs [RFC3986] for interaction with RDAP servers." That means that servers do not support internationalization. From Section 9.2: "On the other hand, when servers return data and have knowledge that the data is in a language or script, the data SHOULD be annotated with language identifiers whenever they are available, thus allowing clients to process and display the data accordingly. The mechanism for including a language identifier in a response will be defined in subsequent documents describing specific response formats." The approach adopted in this future Proposed Standard is that everything will be defined in some future document. This future Proposed Standard is under-specified to the such an extent that it would be extremely difficult to implement without insider information. By the way, the RFC 4627 and RFC 5234 references should be normative. Regards, -sm
Re: Call for Comment on draft-iab-anycast-arch-implications-09 on "Architectural Considerations of IP Anycast"
At 11:13 03-07-2013, IAB Chair wrote: This is an announcement of an IETF-wide Call for Comment on "Architectural Considerations of IP Anycast" (draft-iab-anycast-arch-implications-09). The first version of this draft was submitted in February 2010. The IETF-wide Call is a little more than three years after that. The title of the draft is "Architectural Considerations of IP Anycast". The Abstract mentions "architectural implications of IP anycast". After reading the draft it seems to me that it is more about considerations of using IP Anycast. In Section 1: "As of early 2009, at least 10 of the 13 root name servers were using IP anycast [RSSAC29]" ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62449 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;rssac.org. IN A rssac.org is having DNS issues. The above cites a report published in 2007 about root name servers using IP anycast in 2009. That seems incorrect. In Section 2.1: "One of the first documented uses of anycast was in 1994 for a "Video Registry" experiment [IMR9401]." I suggest using ftp://ftp.rfc-editor.org/in-notes/museum/imr/imr9401.txt as the stable reference for IMR9401. "At the same time, site-local-scoped well-known addresses began being used for recursive resolvers [I-D.ietf-ipv6-dns-discovery], but this use was never standardized (see below in Section 3.4 for more discussion)." That I-D from 2002 is cited as work in progress. :-) '"Requirements for a Mechanism Identifying a Name Server Instance" [RFC4892] cites the use of anycast with DNS as a motivation to identify individual name server instances, and the Name Server ID (NSID) option was defined for this purpose [RFC5001].' From an architectural point of view I would look at it in terms of locator and identifier separation. In Section 3.4: 'Section 3.3 of [RFC4339] proposes a "Well-known Anycast Address" for recursive DNS service configuration in clients to ease configuration and allow those systems to ship with these well-known addresses configured "from the beginning, as, say, factory default". During publication the IESG requested that the following "IESG Note" be contained in the document:' Section 3 is about principles. RFC 4339 was published in 2006. I didn't look into what seems to be the preferred approach since then. The IESG Note quoted in the draft does not convey much information from an anycast perspective. I guess that Section 3.3.2 of RFC 4339 is more appropriate as it discusses about the disadvantages of using the well-known anycast address. It seems to me that the idea here was more about well-known address instead of anycast. As a comment about history it seems that this goes back to the idea of logical addressing mentioned in 1981. To keep matters easy I would go with the idea of locator of ubiquitous service which offers flexibility to the host. Would it be appropriate to say that one of the assumptions for anycasting an application is that it has a fail-over mode in addition to using a stateless transport? Otherwise the route has to be withdrawn to avoid service outage (see Section 4.5). The draft was an interesting read. I didn't catch the potential for a cascaded failure at first (see Section 4.4). On a second read I realized that I was confusing a specific case with a general approach. The "many pitfalls and subtleties" mentioned in Section 1 sums up IP anycast. Regards, -sm
Re: Appeal Response to [removed] regarding draft-ietf-manet-nhdp-sec-threats
At 03:39 03-07-2013, William McCall wrote: I used to read the appeals for my own education. Some pretty hilarious stuff in there. I feel this contributor's frustration though (even though the IESG is right). The decision of the respected members of the IESG was predictable. There may be a minor issue. I cannot comment about that. The appellant mentioned that he worked hard and he has been excluded. In my opinion any other contributor might be frustrated in similar circumstances. The IETF is a place of many misunderstandings. Maybe one day something good will come out of all that. At 09:54 03-07-2013, Toerless Eckert wrote: To me the problem seems to be going back to the means the IETF has for providing recognition to participants contributing by review/feedback. As long as recognition for that contribution is primarily left to the disgression of the listed draft authors, it will negatively impact the amount of especially critical feedback/review the IETF will see. Unless a contributor has a specific business reason to reject or help to improve a drafts, its most likely not worth their time to fight / improve documents without better means of recognition than how its defined today. Especially if their job role lives off showing recognition for their contribution to their employer/sponsor. Yes. There are more incentives not to perform a critical review of a draft instead of doing the reverse. If contributors operate solely for business reasons it can lead to IETF structural issues. At 11:10 03-07-2013, John C Klensin wrote: I am honored to be a member of that club. Remembering that :-) appeals, as others have pointed out, a mechanism for requesting a second look at some issue, they are an important, perhaps vital, part of our process. We probably don't have enough of them. Effectively telling people to not appeal because they will be identified as "kooks" hurts the process model by suppressing what might be legitimate concerns. Yes. come to the formal attention of the full IESG. If an issue is appealed but discussions with WG Chairs, individuals ADs, or the IETF Chair result in a review of the issues and a satisfactory resolution, then that is an that is completely successful in every respect (including minimization of IETF time) but does not Agreed. Sometimes a gesture of goodwill is all that it takes. Regards, -sm
Re: [IAB] RSOC Appointments
Hola Russ, At 06:46 25-06-2013, Russ Housley wrote: The original call for nominations did this in two ways. First, it pointed to RFC 6635, which defines the role of the RSOC. Second, it included a list of the top four items that the RSOC is focusing on right now. What Mr Servin is trying to understand is how can people who are not part of the "good ol' boys network" (see http://www.ietf.org/mail-archive/web/diversity/current/msg00018.html ) know the desirable experience and general requirements to have a fair chance when they apply for the job. If the suggestion is that people read RFC 6635 I don't think that it is not good enough. I understand that the IAB may be reluctant [1] to talk to the Internet Community about all this. Regards, -sm 1. http://www.youtube.com/watch?v=lhmjnYKlVnM
Re: IASA contracts (was: IAOC Website Updated)
Hi Ray, At 12:22 24-06-2013, Ray Pelletier wrote: Progress is being made. The ICANN SLA for 2013 has been published. That's a zero-cost contract. I don't have any problem with the IANA folks I interact with. They are nice and they do what they say they will do. That's more important to me than a SLA. The Verilan Master Services Agreement 2013 has been published. Both the Secretariat and the RFC Production Center contracts are under review and I expect them published in the next two weeks Thanks. I prefer specific dates instead of ambiguous time frames. We have more to do and appreciate the continuing community interest in and feedback on what we do. I presume that this message is from IASA. What I find unusual is that a member of the IAOC is being asked to agree to a contract without being given the opportunity to read the contract ( http://www.ietf.org/mail-archive/web/ietf/current/msg80269.html ). I note that the member was selected by NomCom and that the person is doing the IAOC work as a volunteer. According to RFC 4333 "Candidates for these IAOC positions should have knowledge of the IETF, knowledge of contracts and financial procedures". I don't know which procedures IASA is following that make it acceptable to blindly agree to contracts. There was a RFP for "Remote Participation Services Specifications Development". There were the IDIQ contracts which were mentioned over two years ago. There was the "Requirements for Data Tracker Extensions for Working Group Chairs and Author" contract. I did not elaborate about all the contracts in my previous message as I assumed that it was about all the contracts. I do not have any vested interest in those contracts. I am okay about answering any questions the IETF Community may have about my vested interests. PS Hope to see you in Berlin It's unlikely that I will be able to make it to Germany. Regards, -sm
IASA contracts (was: IAOC Website Updated)
The IAOC states that "The IASA site is designed to provide the IETF community with transparency into the fiscal and administrative activities of the IAOC". According to the IAOC minutes: "The IAOC approves a two-year extension of the Legal Services Contract with Contreras Legal Strategy LLC and requests the Internet Society to enter into such agreements as to effect this extension. The motion passed. Randy [Bush] abstained because he had not seen the contract." The Contracts webpage ( http://iaoc.ietf.org/contracts.html ) does not contain most of the contracts which were signed by the IAD. The IAD previously mentioned that the contracts will be published after the last meeting. Regards, -sm
Back to the future (was: IETF Diversity)
At 05:27 23-06-2013, Noel Chiappa wrote: You're right about it having fallen through a time warp - but you got the sign wrong. It's from the future, not the past. I went back to the future to play the repeated game and I read an (edited) extract of a message from Andy Cohen: "I've been struck by the intensity, the humour, pettiness, and grandeur. I haven't yet concluded whether this is a group of smaller alliances protecting vested interests...or a bunch of pretty remarkable folk working in remarkable ways -- maybe both." There was something I did not know [1] about the Internet Engineering Tooth Fairy, i.e. why it was set up in such a way. Please do not ask me why. It seems that the current discussion is about morganatic marriages, i.e. that's all that the person got. Solutionists recommend easy solutions which ignore complex human problems. Oddly enough a solution was chosen many years ago. As time went by people forgot what was chosen. It is yet to be established whether that was out of convenience or something else. That solution was likely chosen to avoid incestuous relationships where vested interests could flourish. Meritocracy can degenerate into cronyism. Diversity can also degenerate into cronyism. Perceptions are what people believe and what people believe is reality. The answer being sought might be in the above. Regards, -sm 1. I am not sure whether I actually knew about it. There are many things which I do not know.
Policy makers (was: Conclusions on South American IETF Meeting)
At 11:00 20-06-2013, The IAOC wrote: series of events and programs in South America. This would include: - Increasing the IETF Fellows and policy makers from the region I don't see any policy makers reviewing Internet-Drafts. I don't see any policy makers writing IETF RFCs. Policy makers do not usually participate in IETF discussions. During the diversity discussions it has been pointed out that it would be useful if there were more network operators and people who can write code participating in the IETF. What the IAB seems to be have recommended instead is to increase the number of policy makers attending IETF meetings. I am reminded of a sentence from Patrik Fältström: "And to some degree there might be parties that see the lack of progress as a good thing...". I hope that the IAB is not one of these parties as it might be seen as using the IETF for its political convenience. Regards, -sm
Re: Is the IETF is an international organization? (was: IETF Diversity)
At 08:02 20-06-2013, Mark Nottingham wrote: Keep in mind that you're talking to an organisation that believes that Vancouver qualifies as "Asia." That should be added to the Tao. :-) At 08:24 20-06-2013, John C Klensin wrote: Political convenience and expedience trumps geographical reality every time :-) The question I would ask is how many continents are there. Regards, -sm
Is the IETF is an international organization? (was: IETF Diversity)
Hi Aaron, At 11:40 19-06-2013, Aaron Yi DING wrote: Relating to the statement above(I assume Phillip is addressing the US Academia), not quite sure are we still discussing the same topic? sorry, I am bit confused .. since IETF is an international organization. I changed the subject line as I am as confused as to whether the IETF is an international organization. There was a mention of "First the Civil Rights act, then Selma... ;)". I assume that the act is an Act for the United States of America. Harvard was also mentioned. I did a quick search and I found out that "Harvard University is an American private Ivy League research university". Regards, -sm
Re: IETF, ICANN and Whois (Was Re: Last Call: (The Internet Numbers Registry System) to Informational RFC)
Hi Patrik, At 23:25 18-06-2013, Patrik Fältström wrote: I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some "more" technical standards where developed in IETF, and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to "invent" or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? I'll highlight part of a comment from Steve Crocker: (I sometimes have to explain to my colleagues at ICANN who have not had the benefit of the IETF experience that "let's send it over to the IETF" doesn't work. The IETF isn't a standing army ready to do ours or anyone else's work. Rather, I say, it's a place where the relevant people can get together to get their work done. It is easy to see why there isn't significant progress about DNS-related issues in the IETF. If nobody volunteers to do the work the work does not get done. Whether the problems are acute enough to require surgery is not for me to decide. The ITU does work as the IETF does not show interest in doing that work when it had the opportunity to do so. I would not worry too much about ICANN inventing as, to quote John Klensin: I don't know whether that is because they don't have time to write shorter reports or because they don't think the subject matter can be covered in more concise reports, but the pattern is clear, When those committees cannot agree or discover the issues are, in fact, contentious, they typically recommend the creation of more committees. Sometimes people either do not see the problems or pretend not to see them (I am not inferring that you do that). In the latter case I would be asked to explain why I think the problem is a problem when I mention it. I am somewhat suspicious when people who have much more experience than me do that. :-) I don't know whether you have been following the URNbis discussions. That WG had leisurely discussions about the drafts since over three years. It has not been able to publish a single RFC. DNSEXT has been in shutdown mode since over a year. The call for adoption of a draft in DNSOP failed as there wasn't significant interest within the working group to do that work. I'll ask a question to the other persons subscribed to this mailing list. Are there other active participants in ICANN interested in doing work in the IETF? Regards, -sm
RE: Last Call: (Adobe's Secure Real-Time Media Flow Protocol) to Informational RFC
Hi Michael, I am adding my response to John and Martin at the end of this message. At 14:51 11-06-2013, Michael Thornburgh wrote: the intended status is Informational because the specification describes a protocol that was developed outside the IETF, the protocol is in widespread use in the Internet today, and may be of interest to the Internet community. the Shepherd write-up does not draw any connection (nor is there any connection) between the intended Informational status and the existence of IPR. aspects of the protocol that are protected by IPR are disclosed in the specification and are (and have been) available for the review of the community. the relevant IPR was disclosed (IPR 1942) immediately after draft -00 was submitted. Thanks for the explanation. I don't have any problem with the IPR disclosure. my understanding of the "A-D Sponsored" process for an Informational track document is that the IETF Last Call should serve as a final check with the IETF community that there are no important concerns that have been missed or misunderstood. as this protocol and specification are not products of an IETF WG, technical changes to the protocol itself are not expected; however, the specification should be clear and complete enough that an independent and interoperable implementation could be created from it. i have received thorough and detailed feedback from several members of the community that i believe has helped me improve the quality and clarity of the specification. I'll comment about this in my response to Martin. in the course of face-to-face discussion at IETF-86 in the TSVWG meeting, i was prompted to disclose additional detail and supplementary information about the protocol, which i believe improves the clarity of the specification. Yes, I noticed that. the memo (and the protocol it describes) is not the product of a WG. the protocol was presented in person at IETF-77 (in the TSV Area meeting) and IETF-86 (in the TSVWG meeting), and feedback was solicited on the TSVWG and MMUSIC mailing lists. at this time i am not aware of any unaddressed concerns regarding this specification, with the exception of your following comment that i am about to address. I don't think that any technical concerns which might have been raised were not addressed. agreed. i included this statement at the suggestion of the Responsible (and Sponsoring) Area Director, to help establish the breadth of deployment of the protocol, and therefore the relevance of the specification in the RFC Series as an independent submission. the Shepherd, A-D and i are discussing your concern regarding this statement off-list. possible solutions are: move this comment to the Shepherd write-up for the IESG's consideration, change the wording to be more neutral, leave as-is or strike it completely. My preference is to have something neutral but that can be ignored as it is nit. At 02:44 12-06-2013, John C Klensin wrote: I think the advantages to the community of having widely-deployed protocols like this published for information are considerable. It seems to me that those advantages are increasingly getting lost in our quest for consensus (or even unanimity). Perhaps we should be handling them all as Independent Submissions where the community wouldn't even think it had a "vote", but, as Michael points out, community review often improves document quality. Yes. At 04:37 12-06-2013, Martin Stiemerling wrote: The last call is not intended to gather IETF consensus about this draft but give the community an opportunity to see the draft and comment on it before it progress to the IESG. This draft is an AD sponsored draft. I'll keep it short; the intended status is Informational, it's not worth spending too much time arguing about it. :-) Regards, -sm
Re: Content-free Last Call comments
Hi Dave, At 01:43 12-06-2013, Dave Cridland wrote: I strongly feel that positive statements have value, as they allow the community to gauge the level of review and consensus, and I suspect that human nature means that we get more reviews if people get to brag about it. I suggest that if more than one bit of data is required, it's simply asked for. Given that the text of IETF Last Call announcements is not governed by any process RFC that I'm aware of (feel free to correct), I suggest simply putting a set of optional questions there. I note this practise has served the XSF very well. I do not think this needs an endless bikeshed discussion on what questions; the IESG can pick what it wants to know. If, on the other hand, only objections are sought, then the text (which simply asks for "comments") also needs changing. And the GenArt, AppsDir, and SecDir reviews should only be send when they have objections to publication, of course. If you feel that the only way to make either change is to form a working group and publish an RFC to change something undocumented in the series, then I think we're stranded in a bureaucratic quagmire with no chance of escape, but I'll be happy to send "comments", as requested, nonetheless. An interesting point in the above is level of review and consensus. Here's what I know: there is going to be apathy, there might be attempts by a group to support a draft or even attempts to silence critics, there might be someone new to all this who might be commenting. If it was my decision to make (and it is not) I would take those factors and some other points into consideration in making a determination about a document. As I have read your reviews I have an approximate idea of the type of review you would do. I read the draft and I notice some obvious issues; I downgrade your statement of support to a tweeter comment. I read the draft and I notice an obvious issue; I consider your statement of support as good enough. I have read the reviews from the IAB Chair. I read the draft and I notice that it is not well-written; I downgrade the statement of support of the IAB Chair to a tweeter comment. I read the draft and I notice that it is good to go. However, I don't find any comments about it except for a statement of support from the IAB Chair. I don't say that there is consensus. Note that this is really a personal decision; someone else might say that there is consensus. It's not a problem unless the IESG is affected by the Abilene paradox. The XSF is likely a group of people who can write code. The IETF is a bunch of people who might discuss about content-free comments but won't comment about the draft. :-) Drawing up a set of optional questions will generate a bottom-up discussion and that would be against the values which the IETF cherishes. :-) There isn't anything preventing an Area Director or someone else from asking optional questions during a Last Call. Optional questions from an IETF participant might be ignored if such activity would turn a Last Call into the Tribunal del Santo Oficio de la Inquisición. If you are doing an AppsDir review, for example, and you state: The draft is ready for publication as a Proposed Standard. I presume that you can personally explain the meaning of that sentence. If you are an individual responding to a Last Call you can say anything you wish. If your message is littered with spelling mistakes or it does not contain any substantive comment, it won't bear much weight. If your English writing skills is not that good but your code is good the message will bear more weight. If your message is to show your management that you are participating in the IETF the message will not bear much weight. It's simple enough. I would send a message if I believe that it can affect the decision. It's up to me to know what will influence the content and fate of the draft. Regards, -sm
Re: Last Call: (Enrollment over Secure Transport) to Proposed Standard
At 07:45 10-06-2013, The IESG wrote: The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Enrollment over Secure Transport' 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 ietf@ietf.org mailing lists by 2013-06-24. Exceptionally, comments may be There weren't any comments during the WGLC of draft-ietf-pkix-est-06. The AD review of draft-ietf-pkix-est-06 was posted to the mailing list and the only comments after that was "this version address my concerns". I read the document. It is about the use of an obsolete Proposed Standard or later versions of that specification. The comments from three individuals who happen to be Area Directors creates a conundrum; should I give more weight to them or to a content-free comment? I do not support the publication of this document as a Proposed Standard as it is doubtful that it has the consensus of the working group. Regards, -sm
Re: Content-free Last Call comments
Hi Pete, At 13:37 10-06-2013, Pete Resnick wrote: A month ago, we had another very senior member of the community post just such a message (in that case directly to the IESG) in response to a different Last Call. I took that senior member of the community to task for it. But apparently Russ either disagrees with my complaint or didn't notice that discussion on the IESG list, so I think it's worth airing here in public: I don't expect IAB or IESG members to be infallible, i.e. they are individuals after all. A statement such as the above is almost entirely useless to me as an IESG member trying to determine consensus. It is content-free. Yes. We don't vote in the IETF, so a statement of support without a reason is meaningless. We should not be encouraging folks to send such things, and having the IAB chair do so is encouraging bad behavior. Had I not known Russ and his particular expertise, I would have no reason to take it into consideration *at all*. We should not have to determine the reputation of the poster to determine the weight of the message. Even given my background knowledge of who Russ is, I cannot tell from that message which one of the following Russ is saying: The comment was from an individual. The issue is that if you do a blind review of the messages you don't know who sent the message and the only weight you could give is to the content of the message. I think we should stop with these one-line statements of support. They don't add anything to the consensus call. I'm disappointed that Russ contributed to this pattern. I agree that one-line statements are not of much use. It's more tedious to write a statement to support a proposal than an objection to it. Non-silent Last Calls usually draw objections. It's going to be difficult to balance that if one-line statements of support (or objections) are not considered in a determination of consensus. Regards, -sm
ietf@ietf.org is a failure (was: Weekly posting summary for ietf@ietf.org)
At 15:58 07-06-2013, John C Klensin wrote: And it is getting to that conclusion from the above that often troubles me about the posting summary list rankings. Assuming a significant issues shows up on the list, whether in conjunction with a Last Call or something else. Posting a comment and then following up the comments of others with a couple of more postings constitutes three messages in a week, which is pretty reasonable. On the other hand, if there are four such issues in a single week (it happens) then that same individual gets "credited" with a dozen messages, which would make the top of the list in many weeks. I'll reuse some text from IETF 55: - Decisions are taken by backroom deals, intimidation and mob psychology - People unsubscribe in disgust in droves Many years ago the following criticism was made against another body: "The process is stacked in favour of multinationals with expense accounts who can afford to talk on the phone for two hours a week and jet to world capitals for meetings." The IESG once said that it prefers that comments on Last Calls be sent to the ietf@ietf.org list. The IESG also said that authors, working group Chairs and the responsible Area Director are presumed to see all such messages. Is posting the summary list ranking a form of intimidation? I don't know. If ietf@ietf.org is a failure as significant issues are not showing up on the list (see quoted text above) or if the IESG prefers that comments on Last Calls be sent to some other list it can say that. If people unsubscribing in droves is a problem, the IESG could recommend having two hour phone calls a week and meetings in world capitals for Last Calls. If the IESG believes that it is more practical to take decisions through backroom deals it can use a non-public list for handling Last Calls. If a significant number of people cannot act or conduct themselves in a proper way, especially toward others, it is a social problem. If people cannot filter the ietf@ietf.org mailing list, it is a technical problem. The IETF has published a specification which describes a language for filtering email messages at time of final delivery. After reading the latest messages to the list I might conclude that: (i) people do not know about the mail filtering language (ii) people are having technical difficulties using email (iii) it might rain tomorrow As an off-topic comment, there are are alternative ways in making a decision; the best judgement of the most experienced or IETF Consensus. Regards, -sm
Re: Last Call: (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
At 04:07 07-05-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' as Best Current Practice 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-04. Exceptionally, comments may be Sorry for the late comments. I'll defer to the authors on what to do about them. In Section 2.1.3: "o must be for standards purposes (either for an IETF Standard or other standard related to IETF work)," The above is not that clear. I suggest using "IETF Review". BTW, the documentation requirement could also be fulfilled with "Specification Required". Section 2.3.2.1 mentions changes to RFC 2153. I suggest having an "Updates:" for that RFC. In Section 3.1: "o the assignment must be for standards use (either for an IETF Standard or other standard related to IETF work)," IETF Review (see previous comment about that) could be used. In Section 4: "If different policies from those above are required for such a parameter, a BCP or Standards Track RFC must be adopted updating this BCP and specifying the new policy and parameter." "Standards Action" could be used for this. In Section 5.1 I suggest using "IESG Approval". BTW, IESG Ratification of an Expert Review approval recommendation looks unusual to me. Regards, -sm
RE: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"
At 20:01 05-06-2013, l.w...@surrey.ac.uk wrote: RFC2031 documented the takeover. Snuck through on informational... It's part of the poorly documented historical facts which happened after some IETF financial woes. I read draft-iab-rfc4441rev-04 again. Section 1 mentions that: "This version of the document responds to comments received during IAB Last Call." I would have expected the IAB to catch issues which are related to the IETF. Section 3.1.4 lists "Balance between mailing lists and meetings" as a cultural difference. The last sentence in the paragraph: "Attendance at meetings is critical to influencing decisions and to maintaining membership voting rights." sums up a major difference. It could be said that a standard setting organization is dominated by interest groups (see RFC 6852) which can afford the air travel if major decisions are made during a plenary or interim meetings. In Section 3.3.1.4: "However, since IEEE 802 work-in-progress is copyrighted, incorporating material into IETF documents or posting" The above does not describe correctly why it is not possible to incorporate the material. It could mention that due to copyright restrictions, incorporating materials into IETF documents or postings is not allowed. In Section 3.3.1.5: "IEEE 802 standards, once approved, are published and made available for sale." This could be a cultural difference. RFC 6852 glosses over that (see "Standards specifications are made accessible to all for implementation and deployment.") BTW, the draft could be made shorter by incorporating the relevant topics by reference instead of describing them in the draft. RFC 6756 has a better layout in my opinion. RFC 4441 describes the policies and procedures that have developed in order to coordinate between the IETF and IEEE 802. draft-iab-rfc4441rev-04 mentions that it describes the standardization collaboration between the IETF and IEEE 802. The result looks like a "Taoesque" mix of IETF and IEEE 802 material. Why is it important to explain the IAB responsibilities? Why is it important to explain IESG and IAB member appointments? What does cross-referencing documents have to do with the relationship? I suggest looking at the draft while taking the above (non-exhaustive) list of questions into consideration. The details of the collaboration, e.g. how to get a password, can be documented through a Wiki. The IEEE does a decent job of documenting its standards document lifecycle; it's less convoluted than the IETF. The relevant URL is not mentioned in the draft. The draft lists analogies between the IETF and IEEE 802 whereas the reality is that the two organizations operate differently. The details of that is written as politically appropriate version of reality. Regards, -sm
Re: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"
At 11:50 05-06-2013, IAB Chair wrote: This is a call for review of "The IEEE 802 / IETF Relationship" prior to potential approval as an IAB stream RFC. In Section 1: "This document contains a set of principles and guidelines that serves as the basis for establishing collaboration between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE 802) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC)" Is the IETF a task force of the Internet Society? In Section 3.1.2: "4. Appointment of RFC Series and Internet Assigned Number Authority (IANA) roles" What is the meaning of IANA roles in the above? In Section 3.1.4 "Voting: Both organizations use voting as a decision-making tool, but IEEE 802 uses voting within working groups, while IETF working groups do not use voting. Working group chairs may ask for a "show of hands" or "take a hum" to judge backing for a proposal, but this is not considered to be "voting" - The IESG does ballot documents when considering them for publication. This balloting is a final approval for publication." The first part of the text says that the IETF uses voting whereas the "hum" is not considered as "voting". "Decision-making" might be a better label. Regards, -sm
Re: Last Call: (Adobe's Secure Real-Time Media Flow Protocol) to Informational RFC
At 09:12 28-05-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Adobe's Secure Real-Time Media Flow Protocol' 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-25. Exceptionally, comments may be The write-up mentions that: "As a private protocol, no technical changes were performed on the protocol itself, but the authors disclosed more details in response to the WG discussions." I don't see why this specification requires IETF consensus as it is not possible to suggest any major changes. The explanation given for the intended status is that the aspects of the protocol protected by IPR were not reviewed externally. The summary is that there is a memo which is not a WG memo, which is supposed to have gained WG consensus, where some group is supposed to consider the IPR disclosure, and which is being Last-Called as an Individual Submission. I would like to be considered as not part of the consensus. Nits: "At the time of writing, the Adobe Flash Player runtime is installed on more than one billion end-user desktop computers." Shouldn't the memo be about the protocol? Regards, -sm
Re: What do we mean when we standardize something?
to deploy the code and forget about it for a few years. As an unrelated comment, what could "we" mean? It could mean: 1. doing what is right to make you look good 2. doing what is right for your company 3. doing what is right for a country 4. doing what is right for the IETF Regards, -sm
Re: Last Call: (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
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." The text I suggested was based on my reading of the above. Regards, -sm
Re: Last Call: (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi Ted,
At 09:53 29-05-2013, Ted Lemon wrote:
too restrained in this regard, IMHO. I would add some text to the
introduction, like this:
The DNS Resource Records described in this document have significant
privacy implications (see section 8). They were developed with the
intention to use them in [scenario a] or [scenario b] and are likely
not to be appropriate in other scenarios. In particular, they are
unlikely to be appropriate for use in DNS zones hosted on
globally-reachable servers that will answer any query without any
access control mechanism.
Here's what I would be told: Scenario a and Scenario b do not have
privacy implications as they have been reviewed by a respected
organization in Canada. I would also be told that there is an Office
of the Privacy Commissioner of Canada which is diligent [1]. I will
also be told that all this has been reviewed diligently by highly
respected people in the Internet Engineering Task Force.
I still do not plan to raise any objection on the draft.
Regards,
-sm
1. Out of context quote: "One issue being contended with by several
data protection authorities was whether or not Media Access Control
("MAC") addresses (manufacturer-assigned codes that allow devices to
speak to one another), either alone or in combination with other
information, constitute personal information. The OPC did not have
to address this question since it found, as a matter of fact, clear
examples of personal information collected among the payload data,
including complete e-mails, user names and passwords, and even
medical conditions of specified individuals. However, as in the case
of IP addresses, the question of whether or not MAC addresses
constitute personal information is highly contextual and must be
considered in conjunction with what other information is also
available to different users in different circumstances.
Re: Last Call: (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: Last Call: (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
Hola Arturo, At 05:17 27-05-2013, Arturo Servin wrote: Also, it would be important that the "local" people/helpers could do an introduction to what it is the ietf, how to send comments in the remote participation, to the list, what's a WG etc. It may sound a bit bureaucratic, but if we want to have these remote people to start sending emails, comments, reviewing draft we need to break the "ice" somehow. It does not have to be extensive, a short intro could be enough. I like what you said about breaking the ice. As mentioned above, having local people would help. There is a Newcomers tutorial which explains what is a working group, what is the IETF, etc. Joel Jaeggli mentioned that a regional NOG is not fertile ground for new IETF participants. Is LACNOG fertile ground for new IETF participants? The "sending email, comments, reviewing draft" is the really difficult part. My uneducated guess is that it would takes months of work. It's not as negative as it sounds if you consider that overcoming the barrier of entry might usually take over a year. Could you ask the people who attended the talk ( http://www.youtube.com/watch?v=L_zacX9DcZA ) to provide some feedback about it to edu-discuss mailing list? Regards, -sm
Re: More participation from under-represented regions
Hi Joel, At 22:45 26-05-2013, joel jaeggli wrote: notable sucesses I don't think of it a fertile training ground for new IETF participants. I agree that it is not fertile ground for new IETF participants. People come to the IETF with work because they have a problem which the work product of their contribution through the IETF activity addresses. That's fairly expensive, time consuming, and has uncertain results. Yes. Regards, -sm
Re: More participation from under-represented regions (was: IETF Meeting in South America)
Hi Abdussalam, At 16:38 26-05-2013, Abdussalam Baryun wrote: 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. The question was about what was done in the past. It is not about what the IESG or IAB is doing or could do in future. At 16:51 26-05-2013, Abdussalam Baryun wrote: There are some from Africa trying to find the way in, but they may not mention it, however, training is not important much to make people participate but the type of training and its period inside organisation not outside. For example, I notice that there was one African participant (not me), trying to participate in writing one draft for the community, so was he/she encouraged by the WGs, Does that participant reside in Africa? Will that participant implement the draft by writing code? Regards, -sm
Re: More participation from under-represented regions
Hi Edwin, At 13:59 26-05-2013, Edwin A. Opare wrote: The awareness creation should start at the grassroots level : "The Universities"!. Train the soon-to-graduate Computer Scientist/Engineer on the values and essence of the IETF and it'll forever be with them even after graduation. 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. AfNOG has trained hundreds of people in Africa. Those people do not participate on the mailing list. There are some people from Africa who have attended IETF meetings. They don't participate in the IETF. Why is it that there are some participants from South America whereas there aren't any participants from Africa? Regards, -sm
More participation from under-represented regions (was: IETF Meeting in South America)
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? (b) Was the IAB working on how to get more participation from under-represented regions? I am asking the above questions as it is not clear who in the IETF was doing that. Regards, -sm
Re: IETF Meeting in South America
Hi Juliao, At 18:34 23-05-2013, Juliao Braga wrote: I stare at the map of where the IETF meetings occurred (http://ws.org.br/index.php/IETF_Meetings) and wondering if the fact of bringing some of the meetings to below the Equator could lead to increase people participation. That's a nice map. It highlights the division between the northern and southern hemispheres. The answer is always negative. Will not increase participation of more people. Fellowships will help? Certainly not. Resources are finite. Agreed. How then can we increase participation in meetings of the IETF? My answer to the question may seem strange: increasing the number of annual meetings. The answer did sound strange at first. I think that your answer might be appropriate for a different question. At 19:37 23-05-2013, Juliao Braga wrote: I think we will have new challenges to be defined. New opportunities for change that can stimulate, for example, the coming of researchers immersed in universities and / or research centers, not yet participating in the IETF. Maybe they can not submit drafts, but can contribute to foster the knowledge of those who produce drafts or working as reviewers. Regarding the participation in discussions of the mailing lists, I think that they might be involved with reasonable intensity, ideas, and knowledge. Agreed. Perhaps the IETF should and can change (not where it has always been a success) to capture new people. It would take a huge effort to do the above. A person trying to do it will make a lot of enemies. Do you know people in universities or research centers in South America who might be interested in contributing their knowledge? If so, could you ask them to comment on ericas? Regards, -sm
