Re: PS Characterization Clarified
On 18 sep. 2013, at 01:54, John C Klensin john-i...@jck.com wrote: Pete, I generally agree with your changes and consider them important -- the IESG should be seen in our procedural documents as evaluating and reflecting the consensus of the IETF, not acting independently of it. Agreed…. Of the various places in the document in which IESG now appears, only one of them should, IMO, even be controversial. It is tied up with what I think is going on in your exchange with Scott: --On Tuesday, September 17, 2013 18:10 -0500 Pete Resnick presn...@qti.qualcomm.com wrote: Section 2: ... the IESG strengthened its review ... The IETF as a whole, through directorate reviews, area reviews, doctor reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., its reviews. I believe that change would be factually incorrect Which part of the above do you think is factually incorrect? The issue here --about which I mostly agree with Scott but still believe your fix is worth making-- is that the impetus for the increased and more intense review, including imposing a number of requirements that go well beyond those of 2026, did not originate in the community but entirely within the IESG. It didn't necessarily originate with explicit decisions. In many cases, it started with an AD taking the position that, unless certain changes were made or things explained to his (or occasionally her) satisfaction, the document would rot in the approval process. Later IESG moves to enable overrides and clarify conditions for discuss positions can be seen as attempts to remedy those abuses but, by then, it was too late for Proposed Standard. And, fwiw, those changes originated within the IESG and were not really subject to a community consensus process either. However, because the document will be read externally, I prefer that it be IETF in all of the places you identify. If we have to hold our noses and claim that the community authorized the IESG actions by failing to appeal or to recall the entire IESG, that would be true if unfortunate. I would not like to see anything in this document that appears to authorize IESG actions or process changes in the future that are not clearly authorized by community consensus regardless of how we interpret what happened in the past. But one of the things that we should try to maintain in making that change is the notion that the IESG does have a almost key-role in doing technical review. You made the point that that is an important distinction between 'us' and formal SDOs. Therefore I propose that that last occurrence reads: cross-area technical review performed by the IETF, exemplified by technical review by the full IESG at last stage of specification development. I think that this language doesn't set precedence and doesn't prescribe how the review is done, only that the IESG does do review. In full context: In fact, the IETF review is more extensive than that done in other SDOs owing to the cross-area technical review performed by the IETF,exemplified by technical review by the full IESG at last stage of specification development. That position is further strengthened by the common presence of interoperable running code and implementation before publication as a Proposed Standard. Does that work? --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ORCID - unique identifiers for contributors
I agree with both, but maybe the problem is that people from academia are not participating enough to report to ADs their concerns (e.g. what is bad in ietf, or lack of diversity), on the other hand, people from industry are more organised and don't need/want the academians ideas/participations :-) AB On Wed, Sep 18, 2013 at 6:46 AM, Riccardo Bernardini framefri...@gmail.comwrote: On Wed, Sep 18, 2013 at 3:14 AM, George Michaelson g...@algebras.org wrote: Currently, IETF standards activity carries little or no weight for an academic career profile. It doesn't appear to have a weighting compared to peer review publication. I think this is a shame, because the contribution is as substantive, if not more so. And, since time is limited and choices have to be made, I believe good students/postdocs don't come into our space because the payback isn't there compared to submission into the peer-review process. (happy to be corrected. this is a belief, not a proven theory) I can confirm your theory, at least regarding me. I come from academia. I came with some enthusiasm, happy to try to get involved in IETF activities; I subscribed to few WG mailing list, but after some time I discovered that (unfortunately) the payback for unit of work was much less than just publishing scientific paper. So, I unhappily unsubscribed from most of the ML and I stay here, lurking in the background, waiting for some interesting subject... Too bad.
Re: ORCID - unique identifiers for contributors
On Wed, Sep 18, 2013 at 11:09 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: I agree with both, but maybe the problem is that people from academia are not participating enough to report to ADs their concerns (e.g. what is bad in ietf, or lack of diversity), on the other hand, people from industry are more organised and don't need/want the academians ideas/participations :-) Not really, at least in my case. The problem is the different nature of the work done in IETF and in academia. In IETF the work is mostly of engineering nature: you have a problem (e.g., update HTTP with new features) and you try to solve it using, as much as possible, well-known approaches/algorithms/... It is not common that an IETF problem requires some strongly original approach. In academia, instead, we are evaluated on the basis of the scientific papers we produce and, usually, solutions in IETF protocols are not original enough to deserve publication on scientific journals. *Please note*: let me emphasize that I am not criticizing neither of the two worlds (IETF or academia); it is just that we have two similar, but different (important) jobs with minimal overlap... With limited resources (not only funds, also students are nowadays a scarce resource) we must concentrate our efforts where the return for unit of work is larger. Riccardo AB On Wed, Sep 18, 2013 at 6:46 AM, Riccardo Bernardini framefri...@gmail.com wrote: On Wed, Sep 18, 2013 at 3:14 AM, George Michaelson g...@algebras.org wrote: Currently, IETF standards activity carries little or no weight for an academic career profile. It doesn't appear to have a weighting compared to peer review publication. I think this is a shame, because the contribution is as substantive, if not more so. And, since time is limited and choices have to be made, I believe good students/postdocs don't come into our space because the payback isn't there compared to submission into the peer-review process. (happy to be corrected. this is a belief, not a proven theory) I can confirm your theory, at least regarding me. I come from academia. I came with some enthusiasm, happy to try to get involved in IETF activities; I subscribed to few WG mailing list, but after some time I discovered that (unfortunately) the payback for unit of work was much less than just publishing scientific paper. So, I unhappily unsubscribed from most of the ML and I stay here, lurking in the background, waiting for some interesting subject... Too bad.
Re: PS Characterization Clarified
John covered why I said that Pete's assertion is factually incorrect that said, I agree that being accurate here (that the IESG is the final decider and the body that changed the review from what was described in RFC 2026) may be counter productive when the document is reviewed outside of the IETF so changing most of the IESG reverences to read IETF is the right thing to do the one that should not be changed is the one that Olaf calls out at the end of the included message Scott On Sep 18, 2013, at 4:59 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: On 18 sep. 2013, at 01:54, John C Klensin john-i...@jck.com wrote: Pete, I generally agree with your changes and consider them important -- the IESG should be seen in our procedural documents as evaluating and reflecting the consensus of the IETF, not acting independently of it. Agreed…. Of the various places in the document in which IESG now appears, only one of them should, IMO, even be controversial. It is tied up with what I think is going on in your exchange with Scott: --On Tuesday, September 17, 2013 18:10 -0500 Pete Resnick presn...@qti.qualcomm.com wrote: Section 2: ... the IESG strengthened its review ... The IETF as a whole, through directorate reviews, area reviews, doctor reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., its reviews. I believe that change would be factually incorrect Which part of the above do you think is factually incorrect? The issue here --about which I mostly agree with Scott but still believe your fix is worth making-- is that the impetus for the increased and more intense review, including imposing a number of requirements that go well beyond those of 2026, did not originate in the community but entirely within the IESG. It didn't necessarily originate with explicit decisions. In many cases, it started with an AD taking the position that, unless certain changes were made or things explained to his (or occasionally her) satisfaction, the document would rot in the approval process. Later IESG moves to enable overrides and clarify conditions for discuss positions can be seen as attempts to remedy those abuses but, by then, it was too late for Proposed Standard. And, fwiw, those changes originated within the IESG and were not really subject to a community consensus process either. However, because the document will be read externally, I prefer that it be IETF in all of the places you identify. If we have to hold our noses and claim that the community authorized the IESG actions by failing to appeal or to recall the entire IESG, that would be true if unfortunate. I would not like to see anything in this document that appears to authorize IESG actions or process changes in the future that are not clearly authorized by community consensus regardless of how we interpret what happened in the past. But one of the things that we should try to maintain in making that change is the notion that the IESG does have a almost key-role in doing technical review. You made the point that that is an important distinction between 'us' and formal SDOs. Therefore I propose that that last occurrence reads: cross-area technical review performed by the IETF, exemplified by technical review by the full IESG at last stage of specification development. I think that this language doesn't set precedence and doesn't prescribe how the review is done, only that the IESG does do review. In full context: In fact, the IETF review is more extensive than that done in other SDOs owing to the cross-area technical review performed by the IETF,exemplified by technical review by the full IESG at last stage of specification development. That position is further strengthened by the common presence of interoperable running code and implementation before publication as a Proposed Standard. Does that work? --Olaf
Re: ORCID - unique identifiers for contributors
On Sep 18, 2013, at 5:09 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: on the other hand, people from industry are more organised and don't need/want the academians ideas/participations :-) The IETF is not an industry organization. We want (and get!) participation from a wide range of people, including industry people and academics. Several area directors are academics. Honestly, we don't care if you are an academic, an industry person, a hobbyist or a manatee (actually that would be kind of cool). What we care about is that if you participate, you do so meaningfully: you add value to the organization either by doing the work that needs to be done, or by helping other participants to get that work done.
Re: ORCID - unique identifiers for contributors
Hiya, On 09/18/2013 10:22 AM, Riccardo Bernardini wrote: With limited resources (not only funds, also students are nowadays a scarce resource) we must concentrate our efforts where the return for unit of work is larger. While I sympathise, that must above is a choice. Since an academic career is not supposed to be only about publishing and climbing the greasy pole of success, academics can choose to devote time and energy to trying to make the Internet better. Its entirely true that they won't be rewarded much for that in academia. S.
Re: PS Characterization Clarified
--On Wednesday, September 18, 2013 10:59 +0200 Olaf Kolkman o...@nlnetlabs.nl wrote: However, because the document will be read externally, I prefer that it be IETF in all of the places you identify. If we have to hold our noses and claim that the community authorized the IESG actions by failing to appeal or to recall the entire IESG, that would be true if unfortunate. I would not like to see anything in this document that appears to authorize IESG actions or process changes in the future that are not clearly authorized by community consensus regardless of how we interpret what happened in the past. ... But one of the things that we should try to maintain in making that change is the notion that the IESG does have a almost key-role in doing technical review. You made the point that that is an important distinction between 'us' and formal SDOs. It doesn't affect the document but can we adjust or vocabulary and thinking to use, e.g., more traditional rather than formal. There is, IMO, too little that we do that is informal any more, but that isn't the point. Therefore I propose that that last occurrence reads: ... I think that this language doesn't set precedence and doesn't prescribe how the review is done, only that the IESG does do review. ... In full context: In fact, the IETF review is more extensive than that done in other SDOs owing to the cross-area technical review performed by the IETF,exemplified by technical review by the full IESG at last stage of specification development. That position is further strengthened by the common presence of interoperable running code and implementation before publication as a Proposed Standard. Does that work? The new sentence does work and is, IMO, excellent. I may be partially responsible for the first sentence but, given other comments, suggest that you at least insert some so that it ends up being ...more extensive than that done in some other SDOs owing That makes it a tad less combative and avoids a potentially-contentious argument about counterexamples. The last sentence is probably ok although, if we were to do an actual count, I'd guess that the fraction of Proposed Standards for which implemented and interoperability-tested conforming running code exists at the time of approval is somewhat less than common. john
Re: ORCID - unique identifiers for contributors
On 17 September 2013 20:14, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I really think that you all are completely over-engineering this. +1 Really? Each RFC lists the addresses of the authors. There are, in the RfC I used as an example, far more acknowledged contributors, than authors. No addresses for those contributors are given. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: ORCID - unique identifiers for contributors
On 17 September 2013 20:44, Hector Santos hsan...@isdg.net wrote: The idea is great. By why use ORCID? Why not Facebook? linked-in? etc. So many issues when its 3rd party. Facebook, LinkedIn (and other such services) are commercial, and proprietary. Their data is not available under a CC0 licence and their software is not open source. ORCID's - as I've already pointed out - are. While ORCID does offer an API (another conflict issue when API changes), Again, the software and data is open. I think the IETF should offer its own registry database of contributors. Why reinvent the wheel? Even if done, that would not preclude the use of ORCID. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: ORCID - unique identifiers for contributors
On 17 September 2013 20:58, Hector Santos hsan...@isdg.net wrote: But all the newsletter spam potential and privacy issues IETF has no legal hold or control of any kind, in case, well, of the many things that can happen. Please elaborate on these issues and things, in order that specific concerns can be addressed. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: ORCID - unique identifiers for contributors
On 17 September 2013 21:10, Tony Hansen t...@att.com wrote: What would the ORCID reference look like? My understanding is that it would look like this: http://orcid.org/-0003-0437- That is correct. Very few people use the uri element in the author block. (I count zero in the currently extant internet-drafts XML files.) Its intended use really is for the author to put in whatever URI they care to that helps identify them. Its usage is directly parallel to a person's postal, fax and email addresse. So plugging an ORCID into the URI element seems to fit that usage perfectly. What address block? Please refer to the listing of my name in RFC 6350; noting that I am not listed as an author. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: ORCID - unique identifiers for contributors
On 17 September 2013 21:13, Hector Santos hsan...@isdg.net wrote: On 17 September 2013 14:37, Hector Santos hsan...@isdg.net wrote: Seems to me to be a conflict of interest issue. Please explain where this conflict supposedly lies. Too many to list. Then please list a few. Why not gmail.com, google+, facebook.com, linked-in, and so forth? I believe that is at least the third time you have asked a variant of that question; I have just answered at the first. I support the basic concept but why not use a IETF registry instead? To avoid duplicating work already done, for one. But farming this registry out to a 3rd party is problematic, at many levels. Again, please list some, so that we may discuss specifics, rather than vague assertions. Solves several of the conflict of interest concerns, including about 3rd party entities disappearing, losing support, etc. I have already addressed the entities disappearing, losing support myth in an an earlier email. You have no guarantee ORCID will be tomorrow We have guarantees that the software and data will be available openly. nor gmail.com, google+, facebook.com, linked-in, nor tomorrows fad will stick around for ever. I'm not sure why that's relevant. Even then, the means of contract can also chance. Will ORCID keep up? What do you mean by means of contract? Keep up with what? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: ORCID - unique identifiers for contributors
On 18 September 2013 02:44, Andrew G. Malis agma...@gmail.com wrote: Checking out the ORCID site, I noticed that when manually adding a work, one of the possible external IDs is Request for Comments. So they certainly seem to be aware of the RFC series. The site already has the ability to search various external databases to automate the process of adding works, but doesn't have the ability to search the RFC database for works. It would be a great addition to the site if it could. That's certainly doable, but may require the IETF to enter into a partnership agreement with ORCID, The details are outside my area of expertise, but I'd be happy to broker a contact if that would help anyone. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: PS Characterization Clarified
On 9/18/13 7:19 AM, John C Klensin wrote: In full context: In fact, the IETF review is more extensive than that done in other SDOs owing to the cross-area technical review performed by the IETF,exemplified by technical review by the full IESG at last stage of specification development. That position is further strengthened by the common presence of interoperable running code and implementation before publication as a Proposed Standard. Does that work? The new sentence does work and is, IMO, excellent. I may be partially responsible for the first sentence but, given other comments, suggest that you at least insert some so that it ends up being ...more extensive than that done in some other SDOs owing That makes it a tad less combative and avoids a potentially-contentious argument about counterexamples. All sounds good to me. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: ORCID - unique identifiers for contributors
On 9/18/2013 8:45 AM, Andy Mabbett wrote: On 17 September 2013 21:10, Tony Hansen t...@att.com wrote: Very few people use the uri element in the author block. (I count zero in the currently extant internet-drafts XML files.) Its intended use really is for the author to put in whatever URI they care to that helps identify them. Its usage is directly parallel to a person's postal, fax and email addresse. So plugging an ORCID into the URI element seems to fit that usage perfectly. What address block? Please refer to the listing of my name in RFC 6350; noting that I am not listed as an author. Hmmm, I just re-read your original message to ietf@ietf.org. What I had originally taken as a complaint about getting a way to have a unique id (in this case, an ORCID) for the authors was instead a complaint about getting a unique id for the people listed in the acknowledgements. I can't say I have a solution for that one. Tony Hansen
Re: PS Characterization Clarified
Olaf, John, Pete, I know I have more mail to process and that you've already converged. I just wanted to say something about this: draft Proposed rewrite While commonly less mature specifications will be published as Informational or Experimental RFCs, the IETF may, in exceptional cases, publish a specification that still contains areas for improvement or certain uncertainties about whether the best engineering choices are made. In those cases that fact will be clearly communicated in the document prefereably on the front page of the RFC e.g. in the introduction or a separate statement. I like it much better than earlier versions in the discussion. The review that we perform for documents is not really just the IESG review. There is a plenty of WG and IETF Last Call and directorate and specialist and AD review going on… Secondly, for a long time the preferred IESG approach to saying something about the document's applicability and status has been to put the words in the document itself, abstract, introduction, separate section…. as opposed to an IESG statement. And we'd really like WGs and authors to be the source of those words, rather than the IESG. Of course there may be special situations that demand an IESG statement, but that is another matter. and Pete wrote later: I would like to change IESG to IETF in five places: And given my explanation above, I fully agree with his suggestion. And I see that you seem to have converged on that change, too. Good. Jari
Re: ORCID - unique identifiers for contributors
On 18 September 2013 14:04, Tony Hansen t...@att.com wrote: I just re-read your original message to ietf@ietf.org. What I had originally taken as a complaint about getting a way to have a unique id (in this case, an ORCID) for the authors was instead a complaint about getting a unique id for the people listed in the acknowledgements. I can't say I have a solution for that one. It wasn't a complaint, but a suggested solution, for both authors and other named contributors. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: ORCID - unique identifiers for contributors
--On Wednesday, September 18, 2013 14:30 +0100 Andy Mabbett a...@pigsonthewing.org.uk wrote: On 18 September 2013 14:04, Tony Hansen t...@att.com wrote: I just re-read your original message to ietf@ietf.org. What I had originally taken as a complaint about getting a way to have a unique id (in this case, an ORCID) for the authors was instead a complaint about getting a unique id for the people listed in the acknowledgements. I can't say I have a solution for that one. It wasn't a complaint, but a suggested solution, for both authors and other named contributors. Andy, we just don't have a tradition of identifying people whose contributed to RFCs with either contact or identification information. It is explicitly possible when Contributors sections are created and people are listed there, but contact or identification information is not required in that section, rarely provided, and, IIR, not supported by the existing tools. That doesn't necessarily mean that doing so is a bad idea (although I contend that getting it down to listings in Acknowledgments would be) but that making enough changes to both incorporate the information and make it available as metadata would be a rather significant amount of work and would probably reopen policy issues about who is entitled to be listed. For those who want to use ORCIDs, the suggestion made by Tony and others to just use the author URI field is the path of least resistance and is usable immediately. A URN embedding has several things to recommend it over that (mostly technical issues that would be clutter on this list). You would need to have a discussion with the RFC Editor as to whether, e.g., ORCIDs inserted as parenthetical notes after names in Contributor sections or even acknowledgments would be tolerated or, given a collection of rules about URIs in RFCs, removed, but you could at least do that in I-Ds without getting community approval. If you want and can justify more formal recognition for ORCIDs as special and/or required, you haven't, IMO, made that case yet. Perhaps more important from your point of view, if you were, impossibly, to get that consensus tomorrow, it would probably be years [1] before you'd see complete implementation. best, john [1] Slightly-informed guess but I no longer have visibility into ongoing scheduling and priority decisions.
Re: ORCID - unique identifiers for contributors
There are, in the RfC I used as an example, far more acknowledged contributors, than authors. No addresses for those contributors are given. As far as I can tell, nobody else considers that to be a problem. I have written a bunch of books and looked at a lot of bibliographic records, and I have never, ever seen any of them try to catalog the acknowledgements. Indeed, in many books the acknowledgemnents are deliberately very informal, e.g., thanks to Grandma Nell for all the cookies and to George for his unwavering support. George turns out to be his dog. R's, John PS: On the other hand: http://www.condenaststore.com/-sp/On-the-Internet-nobody-knows-you-re-a-dog-New-Yorker-Cartoon-Prints_i8562841_.htm
Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
On 09/16/2013 08:03 PM, Gonzalo Camarillo wrote: Hi Glen, as I mentioned in another email, that question is just a reminder. No, it's not. It is a roadblock. If it was just a reminder. I would be free to ignore it, in the same way that I ignore a reminder from my calendar about a meeting in which I'm is already sitting. In the past, it has happened that even long-time IETF participants with a lot of experience had forgotten about a particular disclosure until they received the reminder. I believe that. I'm sure that there is at least one person in the world who has been granted so many patents that they have just lost track. OTOH, if they put their name on a draft and submitted it, they stated that the draft was full conformance with the provisions of BCP 78 and BCP 79. This is a strong statement, but if you affirm it without knowing that it's true, you are lying. Responding with a yes, per the draft's boilerplate should take only a few seconds of your time. So I guess that makes it OK to call us liars, since only takes a few seconds of our time to deny it. Just one question, though: if you refused to believe it the first 11 times the statement was made, why would you believe it the 12th? ...
Re: ORCID - unique identifiers for contributors
On 9/18/2013 8:59 AM, John C Klensin wrote: Andy, we just don't have a tradition of identifying people whose contributed to RFCs with either contact or identification information. It is explicitly possible when Contributors sections are created and people are listed there, but contact or identification information is not required in that section, rarely provided, and, IIR, not supported by the existing tools. That doesn't necessarily mean that doing so is a bad idea (although I contend that getting it down to listings in Acknowledgments would be) but that making enough changes to both incorporate the information and make it available as metadata would be a rather significant amount of work and would probably reopen policy issues about who is entitled to be listed. If I learned nothing else while mis-spending the mid-2000s talking about IETF process change, it's that if you want anything to change, take the first step toward changing it. If you can come up with a URN definition for ORCID and stuff it into your own author block as a URI without asking for permission or tooling changes, and you think doing so would be helpful, do it. If three people include ORCIDs in their contact information during the next two years, we're probably done. If 300 people do it, we can talk about whether that turned out to be useful, and whether taking some other step would be useful, too. There have been (counting me) four sitting ADs posting on this 90-email thread, plus another six or so former ADs, including a former IETF chair, plus at least six or so WG chairs, plus other participants of good mind and good hearts. I'm thinking that if it was possible to reason what the right answer should be, we would have all agreed. Perhaps we've all agreed (dear Jari, did we all agree?), but if not, the next step could be to try something, and see if it's good enough, or if we need to try something else. Spencer
Re: ORCID - unique identifiers for contributors
On 9/18/13 8:59 AM, Spencer Dawkins wrote: There have been (counting me) four sitting ADs posting on this 90-email thread, plus another six or so former ADs, including a former IETF chair, plus at least six or so WG chairs, plus other participants of good mind and good hearts. I'm thinking that if it was possible to reason what the right answer should be, we would have all agreed. I found the discussion incredibly annoying because for the most part the people raising issues didn't understand what the ORCID identifier represents, they don't understand who its audience is, they don't understand how bibliographic metadata are used, etc., and yet they plowed on, undeterred by their own lack of familiarity with the problem space. I think it is possible to reason what the right answer should be, but not in this environment. Melinda
Re: IETF 88 - Hotel Reservations: REMINDER
Hi Marcia, On 9/18/13 11:54 AM, IETF Agenda wrote: You can still use the main reservation links provided on the meeting web page at http://www.ietf.org/meeting/88/hotel.html for both the Hyatt and Fairmont, but please let me know once you have made your reservation. I have already made my reservation. Regards, Brian
Re: Macro Expansion (was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
Dear SM, See comments inline. On Sep 16, 2013, at 9:00 AM, S Moonesamy sm+i...@elandsys.com wrote: Hi Doug, At 21:55 11-09-2013, Douglas Otis wrote: Add to: 11.5.3. Macro Expansion ,--- It is not within SPF's purview whether IPv6 or DNSSEC is being used. IPv6 (RFC2460) increased the minimum MTU size to 1280 octets. DNSSEC is deployed with EDNS0 (RFC6891) to avoid TCP fallback. EDNS0 suggests an MTU increase between 1280 and 1410 octets offers a reasonable result starting from a request of 4096 octets. A 1410 MTU offers a 2.4 times payload increase over the assumed MTU of 576 octets and is widely supported by Customer Premise Equipment. With increased MTUs being used with DNS over UDP, network amplification concerns increase accordingly. SPF macros can utilize SPF parameters derived from email messages that can modulate the names being queried in several ways without publishing additional DNS resources. The SPF macro feature permits malefactors a means to covertly orchestrate directed DDoS attacks from an array of compromised systems while expending little of their own resources. Since SPF does not make use of a dedicated resource record type or naming convention, this leaves few solutions available to DNS operations in offering a means to mitigate possible abuse. This type of abuse becomes rather pernicious when used in conjunction with synthetic domains now popular for tracking users without using web cookies. However, email providers can mitigate this type of abuse by ignoring SPF records containing macros. Very few domains make use of macros, and ignoring these records result in neutral handling. Some large providers have admitted they make use of this strategy without experiencing any notable problem. AOL began their support of SPF by saying they would use SPF to construct whitelists prior to receipt of email. Clearly, such whitelisting practices tends to preclude benefits derived from macro use. '--- As background information I read draft-otis-spfbis-macros-nixed-01. I read the messages where EDNS0 was mentioned [1]. I read the messages on the thread starting with msg-id: 9884b9cd-0ed3-4d89-a100-58d05ea4b...@gmail.com. I have followed the discussions about macros ever since the SPFBIS WG was chartered. The above suggestion is to add text in the Security Considerations section of the draft. The problem being pointed out is, in simple terms, DNS amplification. The first (quoted) paragraph argues that there can be an acute problem because of EDNS0 as specified in the Internet Standard. The second paragraph starts with SPF macros can utilize SPF parameters derived from email messages. I do not understand that. From what I understand the rest of the second (quoted) paragraph argues that the SPF macro feature permits evildoers to use it as an attack vector. Since this was not understood, I'll attempt to clarify. An effort to keep these conversations fairly concise seems to lead to a level of confusion with those not familiar with DNS. DNS UDP traffic lacks congestion avoidance when used to covertly direct attacks. Residential systems represent a large component of compromised systems involved with email although data centers measured by overall traffic is increasing. Network amplification is measured by gains beyond exchanges initiating a higher volume of exchanges. DNS caching tends to reduce subsequent exchanges. SPFbis macros inhibit normal caching protections by imposing mechanisms not directly supported by DNS and having targets constructed from email message components. SPFbis mechanism names can be misleading since they are given a related manipulated DNS resource name. One SPFbis mechanism can represent more than 100 subsequent DNS transactions where normally resolving the resource would represent a single transaction. Publishing new targets within DNS resources to circumvent caching would normally be expensive and unlikely to provide remarkable gain. SPFbis macros change this equation significantly. SPFbis offers macros to translate code points, restructure host labels, build labels from the client IP address, make use of the local-part of the message return path or some label in the EHLO hostname, etc. In other words, SPFbis macros permit malefactors a means to modulate the target of their queries while still leveraging their own cached DNS records. This means a malefactors' DNS resources can be highly leveraged as a result of recipient SPFbis macro processing. Secondly, SPFbis also ignores the overall size of the resources being queried in many cases. The most egregious is perhaps that of the unlimited PTR RRsets which then results in a series of address RRset resolutions cascading down the hostname labels that happens for a maximum of 10 PTRs that might be offered on either a random or round robin basis. It would be extremely difficult to
Re: Macro Expansion
Posting as the responsible AD for the document in question. On 9/18/13 1:20 PM, Douglas Otis wrote: Since this was not understood, I'll attempt to clarify. An effort to keep these conversations fairly concise seems to lead to a level of confusion with those not familiar with DNS. I'm afraid I'm going to have to end this thread here and now. The problem is not that Doug has tried to keep his explanations concise, or that people are not familiar with the DNS and therefore confused. The latter may or may not be true, but the problem here is precisely that Doug has failed to keep things concise and on point. This is not meant as an insult to Doug, and I apologize to him publicly just in case he feels offended. It is simply the fact that he is unable to clearly and concisely explain to others the security problem he believes exists in this protocol. For example: SPFbis macros inhibit normal caching protections by imposing mechanisms not directly supported by DNS and having targets constructed from email message components. Doug never explains in this sentence *what* the mechanisms are the SPFbis macros are using, he never explains *in what way* those mechanisms are not supported by the DNS, he never explains *how* use of these mechanisms inhibits caching, and never gives an example of *how* the targets (I presume attack targets) are constructed. After a long conversation with Doug, I *think* I may understand what he's raising. I *suspect* the issue could be addressed by a sentence or two added to 11.5.3 or, more likely, to the third and fourth bullet of 11.1. But I'm not sure, and even after that long conversation, I was unable to get a clean explanation of the problem or reasonable text for a solution. So, barring further information, I am simply forced to say that Doug is going to be in the rough part of the consensus. If someone else thinks they will be able to clearly and concisely characterize the problem and propose some text, I welcome such suggestions, though I ask that you communicate first with the SPFBIS chairs and/or myself to make sure that we all understand the specifics. We are far past the point of diminishing returns now, and I do not wish further disruption to either the IETF list or the SPFBIS list on this topic. Again, I intend no insult to Doug, and I again apologize to him for having to take this step publicly. I hope, if there is a problem here that needs to be noted, that Doug can work with someone else so that we can improve the document. Thanks. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
--On Thursday, September 19, 2013 07:57 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 17/09/2013 05:34, Alan Clark wrote: ... It should be noted that the duty to disclose IPR is NOT ONLY for the authors of a draft, and the IETF reminder system seems to be focused solely on authors. The duty to disclose IPR lies with any individual or company that participates in the IETF not just authors. Companies don't participate in the IETF; the duty of disclosure is specifically placed on individual contributors and applies to patents reasonably and personally known to them. IANAL but I did read the BCP. Brian, That isn't how I interpreted Alan's point. My version would be that, if the shepherd template writeup says make sure that the authors are up-to-date (or anything equivalent) it should also say ask/remind the WG participants too. IMO, that is a perfectly reasonable and orderly suggestion (and no lawyer is required to figure it out). One inference from Glen's point that authors have already certified that they have provided anything they need to provide by the time an I-D is posted with the full compliance language is that it may actually be more important to remind general participants in the WG than to ask the authors. john
Re: Last Call: draft-kolkman-proposed-standards-clarified-03.txt (Characterization of Proposed Standards) to Best Current Practice
At 11:18 18-09-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Characterization of Proposed Standards' draft-kolkman-proposed-standards-clarified-03.txt 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-10-16. Exceptionally, comments may be There is a typo in the heading of Section 2 ( Reveiew). I think that it is a fine idea for the IETF to document what it does. This document does that. During the last meeting Eliot Lear mentioned that Olaf has spent an enormous amount of time to defend and to advance the IETF's views on standardization. This document can make that work easier. Regards, S. Moonesamy
Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
--On Wednesday, September 18, 2013 17:22 -0400 Alan Clark alan.d.cl...@telchemy.com wrote: John, Brian Most standards organizations require that participants who have, or whose company has, IPR relevant to a potential standard, disclose this at an early stage and at least prior to publication. The participants in the IETF are individuals however RFC3979 addresses this by stating that any individual participating in an IETF discussion must make a disclosure if they are aware of IPR from themselves, their employer or sponsor, that could be asserted against an implementation of a contribution. The question this raises is - what does participation in a ... Alan, Variations on these themes and options have been discussed multiple times. Of course, circumstances change and it might be worth reviewing them again, especially if you have new information. However, may I strongly suggest that you take the question to the ipg-wg mailing list. Most or all of the people who are significantly interested in this topic, including those who are most responsible for the current rules and conventions, are on that list. Your raising it there would permit a more focused and educated discussion than you are likely to find on the main IETF list. Subscription and other information is at https://www.ietf.org/mailman/listinfo/ipr-wg best, john
majid mohamadi
HI/pleas dont email for me egain tanks
Last Call: draft-kolkman-proposed-standards-clarified-03.txt (Characterization of Proposed Standards) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'Characterization of Proposed Standards' draft-kolkman-proposed-standards-clarified-03.txt 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 i...@ietf.org mailing lists by 2013-10-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 2026 describes the review performed by the IESG on IETF Proposed Standard RFCs and states the maturity level of those documents. This document clarifies those descriptions and updates RFC 2026 by providing a new characterization Proposed Standards. The file can be obtained via http://datatracker.ietf.org/doc/draft-kolkman-proposed-standards-clarified/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kolkman-proposed-standards-clarified/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'Integrity Protection for Control Messages in NHDP and OLSRv2' to Proposed Standard (draft-ietf-manet-nhdp-olsrv2-sec-05.txt)
The IESG has approved the following document: - 'Integrity Protection for Control Messages in NHDP and OLSRv2' (draft-ietf-manet-nhdp-olsrv2-sec-05.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec/ Technical Summary This document specifies integrity and replay protection for the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp TLV based on POSIX time. The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444. This document updates RFC 6130 and the OLSRv2 spec (RFC ) by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2. Working Group Summary Working group consensus behind the document is observed as strong. There are numerous authors and contributors that feel this document is ready to proceed. Document Quality The document has received careful review. There are several implementations of the document. Personnel The Document Shepherd is Joseph Macker (jpmac...@gmail.com) The responsible AD is Adrian Farrel (adr...@olddog.co.uk) RFC Editor Note RFC Editor note: Please replace throughout this document with the RFC number assigned to [OLSRv2], and remove any associated notes.
