Re: PS Characterization Clarified
Based on the conversation below I converged to: t While less mature specifications will usually 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 and prominently communicated in the document e.g. in the abstract, the introduction, or a separate section or statement. /t I will be publishing version 02 shortly. --Olaf [This is a top-post, nothing but context below] On 16 sep. 2013, at 18:04, John C Klensin john-i...@jck.com wrote: --On Monday, September 16, 2013 10:43 -0400 Barry Leiba barryle...@computer.org wrote: ... I agree that we're normally requiring much more of PS documents than we used to, and that it's good that we document that and let external organizations know. At the same time, we are sometimes proposing things that we know not to be fully baked (some of these came out of the sieve, imapext, and morg working groups, for example), but we *do* want to propose them as standards, not make them Experimental. I want to be sure we have a way to continue to do that. The text Olaf proposes is, I think, acceptable for that. In case it wasn't clear, I have no problems with that at all. I was objecting to three things that Olaf's newer text has fixed: (1) It is a very strong assertion to say that the above is exceptional. In particular, exceptional would normally imply a different or supplemental approval process to make the exception. If all that is intended is to say that we don't do it very often, then commonly (Olaf's term), usually, or perhaps even normally are better terms. (2) While it actually may be the common practice, I have difficulty with anything that reinforces the notion that the IESG makes standardization decisions separate from IETF consensus. While it isn't current practice either, I believe that, were the IESG to actually do that in an area of significance, it would call for appeals and/or recalls. Olaf's older text implied that the decision to publish a not-fully-mature or incomplete specification was entirely an IESG one. While the text in 2026, especially taken out of context, is no better (and Olaf just copied the relevant bits), I have a problem with any action that appears to reinforce that view or to grant the IESG authority to act independently of the community. (3) As a matter of policy and RFCs of editorially high quality, I think it is better to have explanations of loose ends and not-fully-baked characteristics of standards integrated into the document rather than using IESG Statements. I don't think Olaf's new front page requirement is correct (although I can live with it) -- I'd rather just say clearly and prominently communicated in the document and leave the is it clear and prominent enough question for Last Call -- but don't want to see it _forced_ into an IESG statement. I do note that front page and Introduction are typically inconsistent requirements (header + abstract + status and copyright boilerplate + TOC usually force the Introduction to the second or third page). More important, if a real explanation of half-baked features (and why they aren't fully baked) may require a section, or more than one, on it own. One would normally like a cross reference to those sections in the Introduction and possibly even mention in the Abstract, but forcing the text into the Introduction (even with preferably given experience with how easily that turns into a nearly-firm requirement) is just a bad idea in a procedures document. We should say clearly, prominently, or both and then leave specifics about what that means to conversations between the authors, the IESG and community, and the RFC Editor. best, john signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
On 16 sep. 2013, at 17:31, John C Klensin john-i...@jck.com wrote: As actionable for this draft I take that I explicitly mention that Section 4.1 2026 is exclusively updated. While I understand your desire to keep this short, the pragmatic reality is that your non-IETF audience is likely to read this document (especially after you hand it to them) and conclude that it is the whole story. Since the natural question that immediately follows why should we accept your standards at all is why can't you hand them off to, e.g., ISO, the way that many national bodies and organizations like IEEE do with many of their documents. Suggestion in the interest of brevity: in addition to mentioning the above, mention explicitly that there are requirements in other sections of 2026 that affect what is standardized and how. Second paragraph of the introduction now reads: This document exclusively updates the characterization of Proposed Standards from RFC2026 Section 4.1.1 and does not speak to or alter the procedures for the maintenance of Standards Track documents from RFC 2026 and xref target=RFC6410RFC 6410/xref. For complete understanding of the requirements for standardization those documents should be read in conjunction with this document. By the way, while I understand all of the reasons why we don't want to actually replace 2026 (and agree with most of them), things are getting to the point that it takes far too much energy to actually figure out what the rules are. Perhaps it is time for someone to create an unofficial redlined version of 2026 that incorporates all of the changes and put it up on the web somewhere. I think we would want a clear introduction and disclaimer that it might be be exactly correct and that only the RFCs are normative, but the accumulation of changes may otherwise be taking us too far into the obscure. If we need a place to put it, it might be a good appendix to the Tao. And constructing it might be a good job for a relative newcomer who is trying to understand the ins and outs of our formal procedures. I guess this is a call for volunteers. --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: Based on the conversation below I converged to: t While less mature specifications will usually 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 and prominently communicated in the document e.g. in the abstract, the introduction, or a separate section or statement. /t I read John's message as being against the use of the phrase in exceptional cases. I would also like to avoid that; it suggests that some exceptional argument may have to be made, and has the implication that it essentially operates outside the process. I would prefer the less formidable-sounding on occasion, which still implies relative rarity. Dave.
Re: PS Characterization Clarified
On 17/09/2013 11:32, Dave Cridland wrote: On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman o...@nlnetlabs.nl mailto:o...@nlnetlabs.nl wrote: Based on the conversation below I converged to: t While less mature specifications will usually 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 and prominently communicated in the document e.g. in the abstract, the introduction, or a separate section or statement. /t I read John's message as being against the use of the phrase in exceptional cases. I would also like to avoid that; it suggests that some exceptional argument may have to be made, and has the implication that it essentially operates outside the process. I would prefer the less formidable-sounding on occasion, which still implies relative rarity. +1.
Re: PS Characterization Clarified
On Sep 17, 2013 6:33 AM, Dave Cridland d...@cridland.net wrote: On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: Based on the conversation below I converged to: t While less mature specifications will usually 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 and prominently communicated in the document e.g. in the abstract, the introduction, or a separate section or statement. /t I read John's message as being against the use of the phrase in exceptional cases. I would also like to avoid that; it suggests that some exceptional argument may have to be made, and has the implication that it essentially operates outside the process. I would prefer the less formidable-sounding on occasion, which still implies relative rarity. Dave. Exceptions and arguments for and against are part of the process. Having a process with no consideration for exceptions would be exceptional.
Re: PS Characterization Clarified
--On Tuesday, September 17, 2013 11:47 +0200 Olaf Kolkman o...@nlnetlabs.nl wrote: Based on the conversation below I converged to: t While less mature specifications will usually 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 and prominently communicated in the document e.g. in the abstract, the introduction, or a separate section or statement. /t I suggest that communicated in the document e.g. in... now essentially amounts to ... communicated in the document, e.g. in the document. since the examples span the entire set of possibilities. Consequently, for editorial reasons and in the interest of brevity, I recommend just stopping after prominently communicated in the document.. But, since the added words are not harmful, I have no problem with your leaving them if you prefer. john
Re: ORCID - unique identifiers for contributors
On 17 September 2013 00:19, Melinda Shore melinda.sh...@gmail.com wrote: I don't see any real downside to allowing people who have ORCIDs to put them in IETF documents. I'm not sure there's a lot of demand for them (this is the first time it's come up, as far as I know) but I don't see a problem with plopping one more piece of information - one that has a unique function - into our docs. Thank you. So how might we raise awareness of ORCID among RfC contributors and and encourage its use by them? Is there a how to guide or FAQ where it could be mentioned? How might we get the IETF to agree to wording along the lines of the IETF encourages (or recommends or requests) contributors to register for an ORCID and to include it...? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: ORCID - unique identifiers for contributors
On 9/17/13 3:56 AM, Andy Mabbett wrote: Thank you. So how might we raise awareness of ORCID among RfC contributors and and encourage its use by them? I'm not sure much needs to be done other than talking with Heather Flanagan (the RFC Editor), getting her sign-off, and then getting it into the xml2rfc schema and noting its existence. I hope that what's going on here is *not* that there's been little uptake and you're trying to promote its use. Melinda
Re: ORCID - unique identifiers for contributors
On 17 September 2013 13:07, Melinda Shore melinda.sh...@gmail.com wrote: I'm not sure much needs to be done other than talking with Heather Flanagan (the RFC Editor), getting her sign-off, and then getting it into the xml2rfc schema and noting its existence. Thank you. Is Heather on this list? I hope that what's going on here is *not* that there's been little uptake and you're trying to promote its use. On the contrary; the uptake from both individuals, and organisations incorporating ORCID into their publishing workflows - is impressive, as you can see form reading the ORCID website blog. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: PS Characterization Clarified
--On Tuesday, September 17, 2013 11:32 +0100 Dave Cridland d...@cridland.net wrote: I read John's message as being against the use of the phrase in exceptional cases. I would also like to avoid that; it suggests that some exceptional argument may have to be made, and has the implication that it essentially operates outside the process. Exactly. I would prefer the less formidable-sounding on occasion, which still implies relative rarity. And on occasion is at least as good or better than my suggestions of usually, commonly, or normally although I think any of the four would be satisfactory. --On Tuesday, September 17, 2013 07:06 -0400 Scott Brim scott.b...@gmail.com wrote: ... Exceptions and arguments for and against are part of the process. Having a process with no consideration for exceptions would be exceptional. Scott, it an IETF technical context, I'd completely agree, although some words like consideration for edge cases would be much more precise if that is actually what you are alluding to. But part of the intent of this revision to 2026 is to make what we are doing more clear to outsiders who are making a good-faith effort to understand us and our standards. In that context, what you say above, when combined with Olaf's text, is likely to be read as: We regularly, and as a matter of course, consider waiving our requirements for Proposed Standard entirely and adopt specifications using entirely different (and undocumented) criteria. That is misleading at best. In the interest of clarity, I don't think we should open the door that sort of interpretation if we can avoid it. I don't think it belongs in this document (it is adequately covered by Olaf's new text about other sections), but it is worth remembering that we do have a procedure for making precisely the type of exceptions my interpretation above implies: the Variance Procedure of Section 9.1 of 2026. I cannot remember that provision being invoked since 2026 was published -- it really is exceptional in that sense. Its existence may be another reason for removing exceptional from the proposed new text because it could be read as implying that we have to use the Section 9.1 procedure for precisely the cases of a well-documented, but slightly incomplete, that most of us consider normal. In particular, it would make the approval of the specs that Barry cited in his examples invalid without invoking the rather complex procedure of Section 9.1. I'd certainly not like to have text in this update that encourages that interpretation and the corresponding appeals -- it would create a different path to the restriction Barry is concerned about. john
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Fri, Sep 13, 2013 at 5:33 PM, Glen Wiley glen.wi...@gmail.com wrote: This discussion highlights the importance of making sure that hardware vendors understand the need for working clocks that can be easily bootstrapped. In addition to NTP radio clock receivers are ubiquitous, tiny and ridiculously cheap. It is unconscionable that any consumer electronics are sold today that boast a visible clock without including a radio clock receiver! This doesn't fix the mountain of already deployed SOHO gear, but it is time for vendors that know better (Cisco, Netgear, D-Link, etc.) to do the right thing. Radio clock receivers often don't work where these devices are deployed (like in my basement). Not enough view of the sky (and multiple layers of floors). Radios are nice to have, but can't be guaranteed to work. I put entropy in a similar class of problem as radio clock receivers. There are a number of reasonable sources for entropy that take up virtually no PCB space and can be built with a few discrete components (thinking of quantum effects between 2 transistor gates or zener breakdown noise on a zener diode). Stronger entropy sources get expensive - but something that provides reasonable entropy for light crypto should be available on SOHO class network gear. Yes, and probably will be someday, and we should all encourage them to do so. I agree that SOC vendors should be encouraged to include such generators (as but one of many sources of entropy: see the following discussion: https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J ). Doesn't help in the meanwhile - Jim On Sep 12, 2013, at 2:19 PM, robert bownes wrote: Chiming in a bit late here, however, the availability of stratum 1 clocks and stratum 2 class time data on non IP and/or non interconnected networks is now so large, I question why one would run NTP outside of the building in many cases, certainly in an enterprise of any size. A 1pulse per second aligned to GPS is good to a few ns. Fairly straightforward to plug into even a OpenWrt type of router. Turn on the pps in NTP on the router and you are good to go. On Tue, Sep 10, 2013 at 6:45 PM, Evan Hunt e...@isc.org wrote: On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote: My colleagues and I worked on OpenWrt routers to get Unbound to work there, what you need to do is to start DNS up in non-validating mode wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation. That's roughly what we did with BIND on OpenWrt/CeroWrt as well. We also discussed hacking NTP to set the CD bit on its initial DNS queries, but I don't think any of the code made it upstream. My real recommendation would be to run an NTP pool in an anycast cloud of well-known v4 and v6 addresses guaranteed to be reliable over a period of years. NTP could then fall back to those addresses if unable to look up the server it was configured to use. DNS relies on a well-known set of root server addresses for bootstrapping; I don't see why NTP shouldn't do the same. (Actually... the root nameservers could *almost* provide a workable time tick for bootstrapping purposes right now: the SOA record for the root zone encodes today's date in the serial number. So you do the SOA lookup, set your system clock, attempt validation; on failure, set the clock an hour forward and try again; on success, use NTP to fine-tune. Klugey! :) ) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list dn...@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list dn...@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: ORCID - unique identifiers for contributors
Heather Flanagan can be most easily reached at rfc-edi...@rfc-editor.org, the specified email address for reaching the rfc-editor. Note however that you need to be clear as to what you are asking her. If you are asking that she arrange for the tools to include provision for using ORCHIDs, that is a reasonable request. SUch a request would presumably be prioritized along with the other tooling improvement that are under consideration. On the other hand, if youa re asking that the IETF endorse or encourage such uses, there are two problems. First, the RFC Editor does not speak for the IETF. You need to actually get a determination of IETF rough consensus on the ietf email list. That consensus would need to be based on a more specific question than do we want to allow ORCHIDs, and then would be judged on that question by the IETF chair. Yours, Joel M. Halpern On 9/17/13 8:26 AM, Andy Mabbett wrote: On 17 September 2013 13:07, Melinda Shore melinda.sh...@gmail.com wrote: I'm not sure much needs to be done other than talking with Heather Flanagan (the RFC Editor), getting her sign-off, and then getting it into the xml2rfc schema and noting its existence. Thank you. Is Heather on this list? I hope that what's going on here is *not* that there's been little uptake and you're trying to promote its use. On the contrary; the uptake from both individuals, and organisations incorporating ORCID into their publishing workflows - is impressive, as you can see form reading the ORCID website blog.
Re: ORCID - unique identifiers for contributors
+1 Thank you for your input. Seems to me to be a conflict of interest issue. I support the basic concept but why not use a IETF registry instead? Solves several of the conflict of interest concerns, including about 3rd party entities disappearing, losing support, etc. -- HLS On 9/17/2013 8:56 AM, Joel M. Halpern wrote: Heather Flanagan can be most easily reached at rfc-edi...@rfc-editor.org, the specified email address for reaching the rfc-editor. Note however that you need to be clear as to what you are asking her. If you are asking that she arrange for the tools to include provision for using ORCHIDs, that is a reasonable request. SUch a request would presumably be prioritized along with the other tooling improvement that are under consideration. On the other hand, if youa re asking that the IETF endorse or encourage such uses, there are two problems. First, the RFC Editor does not speak for the IETF. You need to actually get a determination of IETF rough consensus on the ietf email list. That consensus would need to be based on a more specific question than do we want to allow ORCHIDs, and then would be judged on that question by the IETF chair. Yours, Joel M. Halpern On 9/17/13 8:26 AM, Andy Mabbett wrote: On 17 September 2013 13:07, Melinda Shore melinda.sh...@gmail.com wrote: I'm not sure much needs to be done other than talking with Heather Flanagan (the RFC Editor), getting her sign-off, and then getting it into the xml2rfc schema and noting its existence. Thank you. Is Heather on this list? I hope that what's going on here is *not* that there's been little uptake and you're trying to promote its use. On the contrary; the uptake from both individuals, and organisations incorporating ORCID into their publishing workflows - is impressive, as you can see form reading the ORCID website blog.
Re: ORCID - unique identifiers for contributors
Hi. I agree completely with Joel, but let me add a bit more detail and a possible alternative... --On Tuesday, September 17, 2013 08:56 -0400 Joel M. Halpern j...@joelhalpern.com wrote: If you are asking that she arrange for the tools to include provision for using ORCHIDs, that is a reasonable request. SUch a request would presumably be prioritized along with the other tooling improvement that are under consideration. And either explicit provision for ORCID or more general provisions for other identifying characteristics might easily be added as part of the still-unspecified conversions to support non-ASCII characters. That said, you could get ORCID IDs into RFCs on your own initiative by defining and registering a URN type that embedded the ORCID and then, in xml2rfc terms, using the uri element of authoraddress to capture it. If you want to pursue that course, RFCs 3044 and 3187 (and others) provide examples of how it is done although I would suggest that you also consult with the URNBIS WG before proceeding because some of the procedures are proposed to be changed. The RFC Editor (at least) would presumably need to decide that ORCID-based URNs were sufficiently stable, but no extra tooling would be required. On the other hand, if youa re asking that the IETF endorse or encourage such uses, there are two problems. First, the RFC Editor does not speak for the IETF. You need to actually get a determination of IETF rough consensus on the ietf email list. That consensus would need to be based on a more specific question than do we want to allow ORCHIDs, and then would be judged on that question by the IETF chair. And, if you asked that the ORCID be used _instead_ of other contact information, the issues and several people have raised would apply in that discussion and, at minimum, would make getting consensus harder. john
Re: ORCID - unique identifiers for contributors
I did not know about ORCID before this thread. I think it is brilliant, and what I've read about the mandate of orcid.org, and how it is managed, I am enthusiastic. I agree with what Joel wrote: Asking for ORCID support in the tool set and asking for IETF endorsement are two very different things. Having tool support for it is a necessary first step to permitting IETF contributors to gain experience with it. We need that experience before we can talk about consensus. So, permit ORCID, but not enforce. An interesting second (or third) conversation might be about how I could insert ORCIDs into the meta-data for already published documents. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ pgp9J1CDwgZwX.pgp Description: PGP signature
RE: ORCID - unique identifiers for bibliographers
--On Monday, September 16, 2013 22:28 -0400 John R Levine jo...@taugh.com wrote: I do have an identical twin brother, and hashing the DNA sequence collides more regularly than either random or MAC-based interface-identifiers in IPv6. Also, he doesn't have the same opinions. Clearly, one of you needs to get to know some retroviruses. Or you aren't identical enough. Clearly the hash should be computed over both your DNA sequence and a canonical summary of your opinions. Are we far enough down this rathole? john
Re: ORCID - unique identifiers for bibliographers
On Tue, Sep 17, 2013 at 3:43 PM, John C Klensin john-i...@jck.com wrote: Are we far enough down this rathole? john I'm not sure. Which John are you again? The car-buying psychiatric composer who lives in Edinburgh, Georgia?
Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
From 29 years experience in ATIS, CCITT, CEPT, ETSI, IETF, ITU, TIA and other standards organizations and extensive experience with standards that do have associated IPR it is apparent that asking for confirmation at multiple points in the standards development process IS necessary. For example: (a) The ITU requires that IPR holders make statements prior to the publication of a standard. A top 5 telecom equipment provider submitted a proposal to add an a new capability to an existing (IPR free) standard and did NOT state that they had IPR related to this - in fact the inventor on their patent was the person who wrote and submitted the contribution. Some years after the standard was published, when their patent was granted, they started writing to implementers to demand that they take out a license. Intentional abuse of the standards development process DOES happen. (b) We often hear from large organizations that, as they have thousands of patents, they can't possibly know whether they have patents related to a standard or not. Repeatedly asking questions about IPR disclosure IS important as it does make it harder for IPR holders to claim that they did not know. 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. Alan Clark On 9/16/13 1:00 PM, John C Klensin john-i...@jck.com wrote: --On Monday, September 16, 2013 19:35 +0700 Glen Zorn g...@net-zen.net wrote: ... The wording of this question is not a choice. As WG chairs we are required to answer the following question which is part of the Shepherd write-up as per the instructions from the IESG http://www.ietf.org/iesg/template/doc-writeup.txt: (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. We have no choice but to relay the question to the authors. I see, just following orders. For whatever it is worth, I think there is a rather different problem here. I also believe it is easily solved and that, if it is not, we have a far deeper problem. I believe the document writeup that the IESG posts at a given time is simply a way of identifying the information the IESG wants (or wants to be reassured about) and a template for a convenient way to supply that information. If that were not the case: (i) We would expect RFC 4858 to be a BCP, not an Informational document. (ii) The writeup template would need to represent community consensus after IETF LC, not be something the IESG put together and revises from time to time. (iii) The various experiments in alternative template formats and shepherding theories would be improper or invalid without community consensus, probably expressed through formal process experiment authorizations of the RFC 3933 species. The first sentence of the writeup template, As required by RFC 4858, this is the current template... is technically invalid because RFC 4858, as an Informational document, cannot _require_ anything of the standards process. Fortunately, it does not say you are required to supply this information in this form or you are required to ask precisely these questions, which would be far worse. From my point of view, an entirely reasonable response to the comments above that start As WG chairs we are required to answer the following question... and We have no choice but to relay... is that you are required to do no such thing. The writeup template is guidance to the shepherd about information and assurances the IESG wants to have readily available during the review process, nothing more. I also believe that any AD who has become sufficiently impressed by his [1] power and the authority of IETF-created procedures to insist on a WG chair's asking a question and getting an answer in some particular form has been on the IESG, or otherwise in the leadership much too long [2]. In fairness to the IESG, Has each author confirmed... doesn't require that the document shepherd or WG Chair ask the question in any particular way. Especially if I knew that some authors might be uncomfortable being, in Glen's words, treated as 8-year-old children, I think I would ask the question in a form similar to since the I-Ds in which you were involved were posted, have you had any thoughts or encountered any information that would require filing of additional IPR disclosures?. That question is a reminder that might be (and occasionally has been) useful. A negative answer to it would be fully as much confirming that any and all appropriate IPR disclosures... have been filed as one whose implications are closer to were you telling the truth when you posted that I-D. I think Glen's
Fwd: FW: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04
Hi Ben, I apologize for the delay in responding. I had initially missed this review - it either got cached directly with gen-art reviews or the tools alias burped. I'm not on the main IETF list with this email address. Anyways, thank you very much for your thorough review. Our responses are below [MB]. We have an update underway that addresses your's and other's LC comments. We can forward that to you to preview if you would like. Regards, Mary. -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Tuesday, July 16, 2013 6:52 PM To: draft-yusef-dispatch-ccmp-indication@tools.ietf.org Cc: gen-...@ietf.org Team; IETF-Discussion list Subject: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-yusef-dispatch-ccmp-indication-04 Reviewer: Ben Campbell Review Date: 2013-07-16 IETF LC End Date: 2013-07-16 Summary: This draft is almost ready for publication as a proposed standard, but I think there are some clarifications needed first. Major issues: -- None Minor issues: -- Abstract: Is the abstract current? It says you will discuss pros and cons of a few options, and recommend two. I guess you did recommend two, but the others have been relegated to the appendix. There are no pros and cons listed for the two recommended choices, which seems rather odd. [MB] You are correct, it's slightly out of date. We should just update this to reflect that this document defines two mechanisms. And, we'll add additional text to the selected solutions explaining the motivation for choosing those. So, we suggest the following change (also removing the references as this document actually doesn't update any normative behavior in either 3261 or 4575): OLD: This document describes a few options to address the above limitation with the pros and cons for each approach, and recommends two to be used depending on the need of the UA. The first approach uses the Call-Info header and as a result this document updates RFC 3261 [RFC3261]. The second approach defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package, and as a result this document updates RFC 4575 [RFC4575]. NEW: This document describes two mechanisms, depending upon the need of the UA, to address the above limitation. The first mechanism uses the Call-Info header, and the second mechanism defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package. [/MB] It also mentions that these are mechanisms to be used by SIP clients. That's not repeated in the introduction. Is this entire draft intended exclusively for SIP clients? [MB] We can fix that. The intent is for SIP clients to use this, in particular since the Call-Info header is SIP specific. The service-uri that is being used could also be in the XCON-Data. But, there would be no reason for an XCON client to care about that URI since they are using XCON methods to create conferences, the URI they have for communicating with the conference server MUST be an XCON URI. We propose adding text to the Intro something like the following: OLD: The CCMP protocol defines a way for a client to determine if a conference control server supports CCMP, but it does not define a way for a client to determine if a conference focus supports CCMP. This document defines two mechanisms to address the above limitation. Other mechanisms that we considered are listed in Appendix A. NEW: The CCMP defines a way for an XCON-aware client to discover whether a conference control server supports CCMP. However, it does not define a way for a SIP client involved in a conference to determine if the conference focus [RFC4353] supports CCMP. Knowing that a focus supports CCMP would allow a SIP client (that is also XCON-aware) that joins a conference using SIP based conferencing [RFC4579] to also register for the XCON conference event package [RFC6502] and take advantage of CCMP operations on the conference. This document describes two options to address the above limitation, depending on the need of the UA. The first option uses the Call-Info [RFC3261] header, and the second option defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package [RFC4575]. Other options considered are described in Appendix A. [/MB] -- 2. It would be helpful to give more guidance on when one would use one method over the other. 2.1 mentions that it might be an easier way for a UA that is not interested in the URI. [MB] Would the following address this concern? OLD: This section defines the mechanisms that can be use to discover that a focus supports CCMP. NEW: This section
RE: Gen-ART IETF LC review of draft-allen-dispatch-imei-urn-as-instanceid-10
Roni Thank you for the review My responses below prepended with [AA] Andrew From: Roni Even [mailto:ron.even@gmail.com] Sent: Monday, August 05, 2013 8:35 AM To: draft-allen-dispatch-imei-urn-as-instanceid@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: Gen-ART IETF LC review of draft-allen-dispatch-imei-urn-as-instanceid-10 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-allen-dispatch-imei-urn-as-instanceid-10 Reviewer: Roni Even Review Date:2013-8-5 IETF LC End Date: 2013-8-16 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: Why is it going to be an Informational RFC, considering that there is a lot of normative language in the document. [AA] I think there are many other informational RFCs that contain normative language (e.g. RFC 3325 is informative and full of MUST statements). There is no intention to make this an IETF standard so therefore it cannot be standards track. This is being specified for 3GPP usage to meet the requirements of RFC 5626 that require publication of an RFC for specifying URNs that are used as instance-IDs. Nits/editorial comments: According to RFC editor guidelines (http://www.rfc-editor.org/policy.html#policy.abstract) the abstract section should not contain citations unless they are completely defined within the Abstract. [AA] This specification defines how the Uniform Resource Name namespace reserved for the GSMA (GSM Association) identities and its sub- namespace for the IMEI (International Mobile station Equipment Identity) can be used as an instance-id as specified in RFC 5626 [1] and also as used by RFC 5627 [2]. Its purpose is to fulfil the requirements in RFC 5626 [1] that state If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the +sip.instance Contact header field parameter for outbound behavior. [AA] I think I can remove the as specified in RFC 5626 [1] and also as used by RFC 5627 [2] from the first sentence however I think the second sentence contains the relevant statement from the RFC so this is OK. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: ORCID - unique identifiers for contributors
--On Tuesday, September 17, 2013 11:20 -0400 Michael Richardson m...@sandelman.ca wrote: I did not know about ORCID before this thread. I think it is brilliant, and what I've read about the mandate of orcid.org, and how it is managed, I am enthusiastic. I agree with what Joel wrote: Asking for ORCID support in the tool set and asking for IETF endorsement are two very different things. Having tool support for it is a necessary first step to permitting IETF contributors to gain experience with it. We need that experience before we can talk about consensus. So, permit ORCID, but not enforce. The more I think about it, the more I think that Andy or someone else who understands ORCIDs and the relevant organizations, etc., should be working on a URN embedding of the things. Since we already have provisions for URIs in contact information, an ORCID namespace would permit the above without additional tooling or special RFC Editor decision making. It would also avoid entanglement with and controversies about the rather long RFC Editor [re]tooling queue. Doing the write-up would require a bit of effort but, in principle, URN:ORICD: is pretty close to trivially obvious. Comments about dogfood-eating and not inventing new mechanisms when we have existing ones might be inserted by reference here. An interesting second (or third) conversation might be about how I could insert ORCIDs into the meta-data for already published documents. With a URN embedding that question would turn into the much more general one about how URIs in contact metadata could be retroactively inserted and updated. In some ways, that is actually an easier question. best, john
Re: ORCID - unique identifiers for contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Asking for ORCID support in the tool set and asking for IETF endorsement are two very different things. Having tool support for it is a necessary first step to permitting IETF contributors to gain experience with it. We need that experience before we can talk about consensus. The toolset already lets you put in URIs. What else do you think it needs? R's, John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlI4gwcACgkQkEiFRdeC/kXqJQCfRBk5uNBf+EEMHlj6BWSRvQCL YsUAnA6ynSuwlRSigpjw/dhQgQNZltmy =1xR4 -END PGP SIGNATURE-
Re: PS Characterization Clarified
FYI. I just posted the third version of the draft at: http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02 Diff with the previous document: http://tools.ietf.org/rfcdiff?url2=draft-kolkman-proposed-standards-clarified-02.txt I will let Jari know that I believe we converged and that as far as I am concerned its last call time. --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [IETF] Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 11:20 AM, Michael Richardson m...@sandelman.ca wrote: I did not know about ORCID before this thread. I think it is brilliant, and what I've read about the mandate of orcid.org, and how it is managed, I am enthusiastic. I agree with what Joel wrote: Asking for ORCID support in the tool set and asking for IETF endorsement are two very different things. I must admit that I'm still somewhat confused by what exact problem we are trying to solve here. Things that I write in an IETF context are fundamentally different to things that I write on other contexts, so I don't really see a need for a *global* identifier (If folk think that I wrote a particularly funny anecdote about fish they are not likely to be looking for drafts that I have co-authored. Anyway, what I author in the IEFT context should reflect WG consensus, so who the actual author is is somewhat irrelevant). So, all I really need is to disambiguate myself in the IETF context. This seems simple -- when I arrived here, no-one mistook me for some other Warren Kumari, so I have stuck with that identifier. If there was already a Warren Kumari participating I would simply have used my middle name (embarrassingly enough, Kim) and been Warren Kim Kumari. Had there already been a Warren Kim Kumari, I could refer to myself as Warren Monkey Kumari, Warren Ace Kumari, Warren Dumbass Kumari, etc. If there were multiple Warren Kumari's participating folk are more likely to remember me as Dumbass Warren than that Warren guy with the ORCID -0002-2404-6244. If the purpose it to try prevent folk intentionally passing themselves off as someone else, well, putting in an ORCID doesn't really accomplish that either. I guess I see no harm in this, I just don't really get the point. W Having tool support for it is a necessary first step to permitting IETF contributors to gain experience with it. We need that experience before we can talk about consensus. So, permit ORCID, but not enforce. An interesting second (or third) conversation might be about how I could insert ORCIDs into the meta-data for already published documents. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ -- There are only 10 types of people in this world -- those who understand binary arithmetic and those who don't. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ORCID - unique identifiers for contributors
I'm in agreement. We have not had any standards so far regarding maintenance of the validity of contact information. For example, my contact information for the April 1, 1995 RFC 1776 is: Steve Crocker CyberCash, Inc. 2086 Hunters Crest Way Vienna, VA 22181 Phone: +1 703 620 1222 EMail: croc...@cybercash.com The email address, phone number and postal address became stale a long time ago. If ORCID is introduced, it's likely to be at least as good as email addresses, etc. Let's avoid or at least defer trying to endow them with additional properties such as permanence until there is some experience. Steve On Sep 17, 2013, at 12:16 PM, John C Klensin john-i...@jck.com wrote: --On Tuesday, September 17, 2013 11:20 -0400 Michael Richardson m...@sandelman.ca wrote: I did not know about ORCID before this thread. I think it is brilliant, and what I've read about the mandate of orcid.org, and how it is managed, I am enthusiastic. I agree with what Joel wrote: Asking for ORCID support in the tool set and asking for IETF endorsement are two very different things. Having tool support for it is a necessary first step to permitting IETF contributors to gain experience with it. We need that experience before we can talk about consensus. So, permit ORCID, but not enforce. The more I think about it, the more I think that Andy or someone else who understands ORCIDs and the relevant organizations, etc., should be working on a URN embedding of the things. Since we already have provisions for URIs in contact information, an ORCID namespace would permit the above without additional tooling or special RFC Editor decision making. It would also avoid entanglement with and controversies about the rather long RFC Editor [re]tooling queue. Doing the write-up would require a bit of effort but, in principle, URN:ORICD: is pretty close to trivially obvious. Comments about dogfood-eating and not inventing new mechanisms when we have existing ones might be inserted by reference here. An interesting second (or third) conversation might be about how I could insert ORCIDs into the meta-data for already published documents. With a URN embedding that question would turn into the much more general one about how URIs in contact metadata could be retroactively inserted and updated. In some ways, that is actually an easier question. best, john
RE: ORCID - unique identifiers for contributors
Given this comment in John Levin's post: PS: Now that I think about it, you can already put in a personal URL in rfc2xml, so if someone wants to use an ORCID URL, they can do so right now. it seems like there isn't any need to change the schema. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, September 17, 2013 5:57 AM To: Andy Mabbett Cc: ietf@ietf.org Subject: Re: ORCID - unique identifiers for contributors Heather Flanagan can be most easily reached at rfc-edi...@rfc-editor.org, the specified email address for reaching the rfc-editor. Note however that you need to be clear as to what you are asking her. If you are asking that she arrange for the tools to include provision for using ORCHIDs, that is a reasonable request. SUch a request would presumably be prioritized along with the other tooling improvement that are under consideration. On the other hand, if youa re asking that the IETF endorse or encourage such uses, there are two problems. First, the RFC Editor does not speak for the IETF. You need to actually get a determination of IETF rough consensus on the ietf email list. That consensus would need to be based on a more specific question than do we want to allow ORCHIDs, and then would be judged on that question by the IETF chair. Yours, Joel M. Halpern On 9/17/13 8:26 AM, Andy Mabbett wrote: On 17 September 2013 13:07, Melinda Shore melinda.sh...@gmail.com wrote: I'm not sure much needs to be done other than talking with Heather Flanagan (the RFC Editor), getting her sign-off, and then getting it into the xml2rfc schema and noting its existence. Thank you. Is Heather on this list? I hope that what's going on here is *not* that there's been little uptake and you're trying to promote its use. On the contrary; the uptake from both individuals, and organisations incorporating ORCID into their publishing workflows - is impressive, as you can see form reading the ORCID website blog.
Re: ORCID - unique identifiers for contributors
On Tue, Sep 17, 2013 at 1:22 PM, Pat Thaler ptha...@broadcom.com wrote: Given this comment in John Levin's post: PS: Now that I think about it, you can already put in a personal URL in rfc2xml, so if someone wants to use an ORCID URL, they can do so right now. it seems like there isn't any need to change the schema. +1. Those who are concerned about name collisions can add a pointer to any sort of additional information.
Re: ORCID - unique identifiers for contributors
On 9/17/13 9:55 AM, Michael Tuexen wrote: ... and that is my point. One level of indirection might be useful here. I would prefer to update only one mapping and not go through a list of RFCs and change the mapping for each document. I really think that you all are completely over-engineering this. But that's what I think. What I *know* is that you're looking at this from the perspective of IETF contributors. Librarians have a problem, too, and the ORCID stuff primarily addresses that problem, not ours. There's been a long history of difficulty in name usage on documents and that's confounded librarians, who for some reason (- sarcasm) feel the need to be able to group works by the same author. This has been dealt with through authority control mechanisms, where the cataloger tries to ascertain if a given Scott Smith is the same person as one of the many other Scott Smiths already in the catalog, and if not, creates a new authority record. Discrimination is encoded in the authority records in the form of middle names/initials, dates of birth and death, etc. Again, this is something the *cataloger* does, and it's actually rather difficult. So, in a cataloging record the contents of the author field are normalized under authority control and the author name as it appears on the title page is carried in the body of the cataloging record, and not indexed. There's a quite good discussion of this here: http://kcoyle.blogspot.com/2007/09/name-authority-control-aka-name.html What ORCID does is allow the author to help catalogers out by providing a unifying identifier. It's not intended to be authenticative or provide identity information - it just helps group documents (which is why I think it belongs in a separate piece of metadata). I don't think this is a huge deal and i don't think it requires community consensus. I imagine most IETF authors, who for the most part are not academics, will bother with it, and that's just fine. Melinda
Re: Fwd: Gen-ART LC Review of draft-ietf-karp-ops-model-07
Hi. I somehow missed the genart review and Stewart kindly forwarded me a copy I will shortly be publishing a new version that includes fixes discussed below. genart == Stewart Bryant stbry...@cisco.com writes: genart Major issues: genart None. genart Minor issues: genart -- This abstract claims that this draft is a discussion of genart issues. From that per spective, I don't think the use of genart 2119 language is appropriate. There are some specific areas genart (mentioned below) where 2119 language is used in imprecise genart ways, and may do harm to the reader's understanding. There genart are other uses that may be more reasonable. But I think the genart draft would be better off dispensing with 2119 language genart altogether. We disagree. I think that the draft provides requirements that if followed will make management of the security aspects of routers easier to depend on. I believe 2119 language is useful in that. I think this is well within an area where there is no IETF-wide consessus and the judgment of the individual WGs and to a lesser extent editors should control. genart -- Section 3, paragraph 4: genart This seems like a place where descriptive language would be genart better than 2119 lan guage. In particular, and so on genart leaves things too open ended and imprecise. Al so, the use genart of 2119 language in an example seems a bit off. So, the requirement is stated in the first clause using 2119 language: Operational Requirements: implementations of this model MUST support configuration of keys at the most general scope for the underlying protocol; The sentence goes on to apply that requirement to some common cases: protocols supporting per-peer keys MUST permit configuration of per-peer keys, protocols supporting per-interface keys MUST support configuration of per-interface keys, and so on. You might prefer different style rules; you might prefer that the restatements of the general requirement to specific situations not use 2119 language. I think the right approach for that is to try and build community consensus on those style rules and not to apply those rules until such a consensus is achieved. I do agree that care should be used when using 2119 in a restatement, but in this instance believe it is OK. I've removed the 2119 language from the example, although I think it was harmless. genart -- section 3.1, last paragraph: genart I'm not sure what guidance is intended in this paragraph. It genart offers an example, then refutes it. Are there better genart examples to offer? Is the point that one shoul dn't make genart such checks? The point is that we're not recommending such checks here; added text to clarify. Thanks. genart -- section 3.2, paragraph 2: genart What distinguishes SHOULD from desirable in this context? genart That is, why use 211 9 language for one and not the other? The sentences including desirable are giving motivation for the sentences including SHOULD. That is the SHOULDS are the take-aways, the desirables are expansions/explanations of why the SHOULDS make sense. genart -- section 3.2, last paragraph: Implementations SHOULD genart permit a configuration i n which if no unexpired key is genart available, existing security associations continu e using genart the expired key with which they were established. genart This may need further guidance. For example, it seems risky genart to do this silently. I think this was explicitly discussed in the WG and is where we got in our discussions. There's discussion of alerts for security events elsewhere. However I think the current text represents a fairly informed WG consensus. genart -- section 3.3, last paragraph: ... then there is genart complexity in key management protocols. genart Can you elaborate? Too much complexity? Are there key genart management systems that ar e not complex? Clarified to indicate that there's complexity that can be avoided if you don't need key IDs to be globally unique. genart -- section 4, 2nd to last paragraph: genart Seems like other disadvantages are worth mentioning. For genart example, the potential impact of a compromised CA. I spent a few minutes trying to come up with an argument whether CA compromise was better or worse than other systems compromise profile, particularly focusing on central management system compromise in the preshared key case. I think it's difficult to come up with an argument about whether that's actually a disadvantage of CAs in this case and I think getting consensus would be non-trivial. I also think that managing CA compromise can either be handled on the cost axis (secure offline CA) or the complexity axis (push out new CA certs and end-entity certs on compromise). So, I think the current text is accurate. If there are specific disadvantages that can
Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 19:37, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I was always wondering the authors can't get an @ietf.org address, which is listed in the RFC and is used to forward e-mail to another account. +1. (Remarkably, all the RFCs I co-authored show the same email address. Not so for the ones I only contributed to, even though all of those addresses still work. But even for the co-authored ones that seems to be the exception.) Grüße, Carsten
Re: ORCID - unique identifiers for contributors
On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I was always wondering the authors can't get an @ietf.org address, which is listed in the RFC and is used to forward e-mail to another account. The email address associated with the draft, for example draft-kutscher-icnrg-netinf-pr...@tools.ietf.org, apparently stays with the RFC. If you go to tracker for any RFC you can click email authors. I don't think there's a way to update the authors' current addresses.
Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 6:36 PM, Steve Crocker st...@shinkuro.com wrote: I'm in agreement. We have not had any standards so far regarding maintenance of the validity of contact information. For example, my contact information for the April 1, 1995 RFC 1776 is: Steve Crocker CyberCash, Inc. 2086 Hunters Crest Way Vienna, VA 22181 Phone: +1 703 620 1222 EMail: croc...@cybercash.com The email address, phone number and postal address became stale a long time ago. If ORCID is I was always wondering the authors can't get an @ietf.org address, which is listed in the RFC and is used to forward e-mail to another account. Best regards Michael introduced, it's likely to be at least as good as email addresses, etc. Let's avoid or at least defer trying to endow them with additional properties such as permanence until there is some experience. Steve On Sep 17, 2013, at 12:16 PM, John C Klensin john-i...@jck.com wrote: --On Tuesday, September 17, 2013 11:20 -0400 Michael Richardson m...@sandelman.ca wrote: I did not know about ORCID before this thread. I think it is brilliant, and what I've read about the mandate of orcid.org, and how it is managed, I am enthusiastic. I agree with what Joel wrote: Asking for ORCID support in the tool set and asking for IETF endorsement are two very different things. Having tool support for it is a necessary first step to permitting IETF contributors to gain experience with it. We need that experience before we can talk about consensus. So, permit ORCID, but not enforce. The more I think about it, the more I think that Andy or someone else who understands ORCIDs and the relevant organizations, etc., should be working on a URN embedding of the things. Since we already have provisions for URIs in contact information, an ORCID namespace would permit the above without additional tooling or special RFC Editor decision making. It would also avoid entanglement with and controversies about the rather long RFC Editor [re]tooling queue. Doing the write-up would require a bit of effort but, in principle, URN:ORICD: is pretty close to trivially obvious. Comments about dogfood-eating and not inventing new mechanisms when we have existing ones might be inserted by reference here. An interesting second (or third) conversation might be about how I could insert ORCIDs into the meta-data for already published documents. With a URN embedding that question would turn into the much more general one about how URIs in contact metadata could be retroactively inserted and updated. In some ways, that is actually an easier question. best, john
Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 7:48 PM, Scott Brim scott.b...@gmail.com wrote: On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I was always wondering the authors can't get an @ietf.org address, which is listed in the RFC and is used to forward e-mail to another account. The email address associated with the draft, for example draft-kutscher-icnrg-netinf-pr...@tools.ietf.org, apparently stays with the RFC. If you go to tracker for any RFC you can click email authors. I don't think there's a way to update the authors' current addresses. ... and that is my point. One level of indirection might be useful here. I would prefer to update only one mapping and not go through a list of RFCs and change the mapping for each document. Best regards Michael
Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 8:19 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 9/17/13 9:55 AM, Michael Tuexen wrote: ... and that is my point. One level of indirection might be useful here. I would prefer to update only one mapping and not go through a list of RFCs and change the mapping for each document. I really think that you all are completely over-engineering this. But that's what I think. What I *know* is that you're Really? Each RFC lists the addresses of the authors. My understanding is that this information might be used to contact the authors in case of questions, errata, ... At least this happened in the past. For example http://www.ietf.org/rfc/rfc3237.txt has 7 authors. I know that at least 4 affiliations have changed and at least you can't reach me anymore via the given e-mail address or telephone number. Best regards Michael looking at this from the perspective of IETF contributors. Librarians have a problem, too, and the ORCID stuff primarily addresses that problem, not ours. There's been a long history of difficulty in name usage on documents and that's confounded librarians, who for some reason (- sarcasm) feel the need to be able to group works by the same author. This has been dealt with through authority control mechanisms, where the cataloger tries to ascertain if a given Scott Smith is the same person as one of the many other Scott Smiths already in the catalog, and if not, creates a new authority record. Discrimination is encoded in the authority records in the form of middle names/initials, dates of birth and death, etc. Again, this is something the *cataloger* does, and it's actually rather difficult. So, in a cataloging record the contents of the author field are normalized under authority control and the author name as it appears on the title page is carried in the body of the cataloging record, and not indexed. There's a quite good discussion of this here: http://kcoyle.blogspot.com/2007/09/name-authority-control-aka-name.html What ORCID does is allow the author to help catalogers out by providing a unifying identifier. It's not intended to be authenticative or provide identity information - it just helps group documents (which is why I think it belongs in a separate piece of metadata). I don't think this is a huge deal and i don't think it requires community consensus. I imagine most IETF authors, who for the most part are not academics, will bother with it, and that's just fine. Melinda
Re: ORCID - unique identifiers for contributors
On 9/17/13 11:14 AM, Michael Tuexen wrote: For example http://www.ietf.org/rfc/rfc3237.txt has 7 authors. I know that at least 4 affiliations have changed and at least you can't reach me anymore via the given e-mail address or telephone number. This is not the problem ORCID addresses, except indirectly. It's a way to establish that the author Melinda Shore who worked at Cisco is the same author Melinda Shore who worked at the Center for Research Libraries. It is NOT a contact mechanism, a personal tracking mechanism, etc. Melinda
Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 9:24 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 9/17/13 11:14 AM, Michael Tuexen wrote: For example http://www.ietf.org/rfc/rfc3237.txt has 7 authors. I know that at least 4 affiliations have changed and at least you can't reach me anymore via the given e-mail address or telephone number. This is not the problem ORCID addresses, except indirectly. It's a way to establish that the author Melinda Shore who worked at Cisco is the same author Melinda Shore who worked at the Center for Research Libraries. It is NOT a contact mechanism, a personal tracking mechanism, etc. Agreed. Maybe the wrong thread... I replied to a statement that the authors e-mail addresses went stale... Best regards Michael Melinda
Re: I-D Action: draft-kolkman-proposed-standards-clarified-02.txt
Is it just me, or does this sentence now seem like hubris? In fact, the IETF review is more extensive than that done in other SDOs owing to the cross- area technical review performed by the IESG, a position that is further strengthened by the common presence of interoperable running code and implementation before publication as a Proposed Standard. At the least, I would prefer to see it start thus: The IETF review is possibly more extensive than ... Regards Brian
Re: ORCID - unique identifiers for contributors
On 9/17/2013 8:07 AM, Melinda Shore wrote: I'm not sure much needs to be done other than talking with Heather Flanagan (the RFC Editor), getting her sign-off, and then getting it into the xml2rfc schema and noting its existence. What would the ORCID reference look like? My understanding is that it would look like this: http://orcid.org/-0003-0437- 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. Tony Hansen
Re: [IETF] Re: ORCID - unique identifiers for contributors
On 9/17/13 1:08 PM, Warren Kumari wrote: On Sep 17, 2013, at 4:52 PM, Yoav Nir y...@checkpoint.com wrote: Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, Would it? Why? It's useful to librarians/archivists/people who organize things. Melinda
Re: [IETF] Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 4:52 PM, Yoav Nir y...@checkpoint.com wrote: On Sep 17, 2013, at 10:44 PM, Hector Santos hsan...@isdg.net wrote: On 9/17/2013 1:55 PM, Michael Tuexen wrote: On Sep 17, 2013, at 7:48 PM, Scott Brim scott.b...@gmail.com wrote: On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I was always wondering the authors can't get an @ietf.org address, which is listed in the RFC and is used to forward e-mail to another account. Me too! I would even suggest that all I-D authors, at the very least, should need to register with the IETF to submit documents. Optional @ietf.org offered. Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, Would it? Why? I publish some papers in other places. I wear substantially different hats in other areas -- drafts published in the IETF reflect (in theory) IETF consensus, so they are not really *my* views, they are the views of a group of folk. So, it is not that folk can read a document in another context and then say Wow, that's interesting, let me see what Warren's views on IETF subjects is and then go find *my* IETF views (if they wanted that, looking at mailing lists is probably a better option :-)) I guess a universal identifier could be useful so that future employers / people in bars could look me up, see that I've contributed to N documents in M SDOs and then be all impressed. This does not seem very useful to me. W and that single identifier is not going to be an @ietf.org email address. -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment. -- Terry Practhett
Re: ORCID - unique identifiers for contributors
Yes, you can do this using RDFa [1] into HTML tags. If Dr. Krafft had used RDFa so his page: a. Will be a entry point and used as SPARQL[2] queries. This entry point will be found in his contribuition to, or participation in the IETF (e.g. in the Attendance List of the IETF meetings). b. Could be subjected to a destiller[3] to obtain a RDF / RDFS / OWL file. c. This file will be part of an (upper) ontology for the IETF, with specific vocabulary (or metadata) as DCMI[4]. d. And so on... Julião A simple example: http://www.braga.eti.br/People/Juliao_Braga/. Get the source of this page. You will see the vocabulary used into the HTML tags. [1] http://www.w3.org/TR/xhtml-rdfa-primer [2] http://www.w3.org/TR/rdf-sparql-query/ [3] http://www.w3.org/2012/pyRdfa/ [4] http://dublincore.org/ Em 16/09/2013 13:49, Scott Brim escreveu: It's a good idea but I would generalize it. Why have a system just for I*? I would allow people to provide a pointer to their public information in one (or more?) of many places. For example, http://vivo.cornell.edu/display/individual8772 and if necessary we can explore federated identity. Scott
Re: ORCID - unique identifiers for contributors
On 9/17/2013 1:55 PM, Michael Tuexen wrote: On Sep 17, 2013, at 7:48 PM, Scott Brim scott.b...@gmail.com wrote: On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I was always wondering the authors can't get an @ietf.org address, which is listed in the RFC and is used to forward e-mail to another account. Me too! I would even suggest that all I-D authors, at the very least, should need to register with the IETF to submit documents. Optional @ietf.org offered. The email address associated with the draft, for example draft-kutscher-icnrg-netinf-pr...@tools.ietf.org, apparently stays with the RFC. If you go to tracker for any RFC you can click email authors. I don't think there's a way to update the authors' current addresses. ... and that is my point. One level of indirection might be useful here. I would prefer to update only one mapping and not go through a list of RFCs and change the mapping for each document. If there are other purposes for ORCID, then what are those? These are things the IETF can do in general to improve its electronic participant and network of world wide contributors. The idea is great. By why use ORCID? Why not Facebook? linked-in? etc. So many issues when its 3rd party. While ORCID does offer an API (another conflict issue when API changes), I think the IETF should offer its own registry database of contributors. -- HLS
Re: ORCID - unique identifiers for contributors
On 9/17/2013 3:24 PM, Melinda Shore wrote: On 9/17/13 11:14 AM, Michael Tuexen wrote: For example http://www.ietf.org/rfc/rfc3237.txt has 7 authors. I know that at least 4 affiliations have changed and at least you can't reach me anymore via the given e-mail address or telephone number. This is not the problem ORCID addresses, except indirectly. It's a way to establish that the author Melinda Shore who worked at Cisco is the same author Melinda Shore who worked at the Center for Research Libraries. It is NOT a contact mechanism, a personal tracking mechanism, etc. But how much of a problem is that? Why not advocate gmail.com, google+, facebook.com, linked-in? I registered at ORCID and it found a similar named registrant. It only wanted to know if it was me, if not then continue. But all the newsletter spam potential and privacy issues and even more in there, well, scared me. It had multiple levels of privacy to select and too much reading required to follow it. So I punted on that. Why can't the IETF offers its own signup requirement for I-D submissions where a contact id can be provided? The focus should be within the @IETF.ORG, not try to steer folks to use some 3rd party contact id where the IETF has no legal hold or control of any kind, in case, well, of the many things that can happen. Thanks -- HLS
Re: ORCID - unique identifiers for contributors
On 9/17/2013 4:52 PM, Yoav Nir wrote: Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, and that single identifier is not going to be an @ietf.org email address. Then for these unique individuals, a single source id is useful for them and should be recommended to consolidate contact consistent and persistent information. People are increasingly doing that now with what was once alias junk domains, i.e. gmail.com, google+, even facebook, twitter, etc. I know I have move away from a using a corporate id in public that are now protected (in spirit) by ADSP and DKIM. But as a total, don't you think the ietf.org will benefit in the long run maintaining its own registry? -- HLS
Re: Why we don't want to actually replace 2026
On 17/09/2013 17:49, S Moonesamy wrote: Hi John, At 08:31 16-09-2013, John C Klensin wrote: By the way, while I understand all of the reasons why we don't want to actually replace 2026 (and agree with most of them), things are getting to the point that it takes far too much energy to actually figure out what the rules are. Perhaps it is time for someone to create an unofficial redlined version of 2026 that incorporates all of the changes and put it up on the web somewhere. I think we would want a clear introduction and I posted draft-moonesamy-stds-process-00 (expired) [1] in 2010. I have to update the draft as it does not take into account the two-track change. I would not post a revision on the web as the IETF Trust might not like it. In my opinion it might be related to the original negotiating position of CNRI. For some years I've maintained http://www.ietf.org/about/process-docs.html to assist IETF participants in navigating the labyrinth. It does carefully avoid red-lining or commentary, and I think it also shows the complexity that we have created. Brian Regards, S. Moonesamy 1. http://tools.ietf.org/html/draft-moonesamy-stds-process-00
Re: PS Characterization Clarified
On 9/17/13 11:27 AM, Olaf Kolkman wrote: I just posted the third version of the draft at: http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02 I would like to change IESG to IETF in five places: Section 1: the IESG has evolved its review processes Section 2: IESG Reveiew of Proposed Standards the IESG strengthened its review last chance for the IESG to ensure the quality cross-area technical review performed by the IESG The IETF as a whole, through directorate reviews, area reviews, doctor reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., its reviews. Saying the IESG in these places implies precedent setting that I think would be bad. If the IETF capitulated to the IESG changing the rules on its own in the past, so be it, but I think it would be bad to indicate in a BCP that we think it's OK for the IESG to do so unilaterally. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 10:44 PM, Hector Santos hsan...@isdg.net wrote: On 9/17/2013 1:55 PM, Michael Tuexen wrote: On Sep 17, 2013, at 7:48 PM, Scott Brim scott.b...@gmail.com wrote: On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I was always wondering the authors can't get an @ietf.org address, which is listed in the RFC and is used to forward e-mail to another account. Me too! I would even suggest that all I-D authors, at the very least, should need to register with the IETF to submit documents. Optional @ietf.org offered. Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, and that single identifier is not going to be an @ietf.org email address.
Re: PS Characterization Clarified
1/ I believe that change would be factually incorrect 2/ I do not see that being factually correct about what happened says anything about the community opinion about any future IESG decision to change processes. Scott On Sep 17, 2013, at 6:48 PM, Pete Resnick presn...@qti.qualcomm.com wrote: On 9/17/13 11:27 AM, Olaf Kolkman wrote: I just posted the third version of the draft at: http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02 I would like to change IESG to IETF in five places: Section 1: the IESG has evolved its review processes Section 2: IESG Reveiew of Proposed Standards the IESG strengthened its review last chance for the IESG to ensure the quality cross-area technical review performed by the IESG The IETF as a whole, through directorate reviews, area reviews, doctor reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., its reviews. Saying the IESG in these places implies precedent setting that I think would be bad. If the IETF capitulated to the IESG changing the rules on its own in the past, so be it, but I think it would be bad to indicate in a BCP that we think it's OK for the IESG to do so unilaterally. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: PS Characterization Clarified
On 9/17/13 5:52 PM, Scott O. Bradner wrote: On Sep 17, 2013, at 6:48 PM, Pete Resnickpresn...@qti.qualcomm.com wrote: I would like to change IESG to IETF in five places: Section 1: the IESG has evolved its review processes Section 2: IESG Reveiew of Proposed Standards the IESG strengthened its review last chance for the IESG to ensure the quality cross-area technical review performed by the IESG 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? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: [IETF] Re: ORCID - unique identifiers for contributors
On 18/09/2013 09:11, Melinda Shore wrote: On 9/17/13 1:08 PM, Warren Kumari wrote: On Sep 17, 2013, at 4:52 PM, Yoav Nir y...@checkpoint.com wrote: Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, Would it? Why? It's useful to librarians/archivists/people who organize things. It's very useful to people who maintain citation databases, where uniquely identifying authors is necessary. It's practically essential for academics whose career depends on attribution of publications and on citation counts (and for the people who hire or promote them). At first sight, it doesn't seem to matter too much for the IETF itself, until the day we have two authors with the same name, or one author with two names. I think we have several instances of the latter, and I can't really tell you easily if the following set of RFC authors contains 10 people or more: A. Li, C. Li, D. Li, H. Li, J. Li, K. Li, T. Li, X. Li, Y. Li, Z. Li. A. Li, who authored RFC 2363, is an especially interesting case. Probably the same person as A. Lin, who authored RFC 2764, but worked for a different company. I see that R.T. Braden, R. Braden and B. Braden have all authored RFCs. One person or three? In other words, objective identification would actually help sometimes. Brian
Re: PS Characterization Clarified
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. 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. john
Re: ORCID - unique identifiers for contributors
Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, and that single identifier is not going to be an @ietf.org email address. If you want Yahoo mail or gmail or pobox.com, you know where to find it. Or people here are, I expect, mostly able to arrange for their own vanity domains. R's, John, ab...@no.sp.am
Re: [IETF] Re: ORCID - unique identifiers for contributors
It's practically essential for academics whose career depends on attribution of publications and on citation counts (and for the people who hire or promote them). Gee, several of the other John Levines have published way more than I have. If what we want is citation counts, confuse away. R's, John PS: If you think I think this topic has been beaten to death and back, you wouldn't be mistaken.
Re: ORCID - unique identifiers for contributors
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) On that basis, things we do which make it easier for academic and research assessment processes for STEM careers to consider our work as 'worthy' are good and useful, because they help to direct skilled new brains into our zombie pool. I think ORCID would be the kind of thing which helps. -G On Wed, Sep 18, 2013 at 11:08 AM, John Levine jo...@taugh.com wrote: Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, and that single identifier is not going to be an @ietf.org email address. If you want Yahoo mail or gmail or pobox.com, you know where to find it. Or people here are, I expect, mostly able to arrange for their own vanity domains. R's, John, ab...@no.sp.am
Re: ORCID - unique identifiers for contributors
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. Cheers, Andy On Mon, Sep 16, 2013 at 10:39 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: [First post here] Hello, I'm a contributor to RFC 6350 - but I'm listed there by name only, and there is nothing to differentiate me from some other Andy Mabbett (the problem is no doubt worse for people with less unusual family names). Like many such contributors, I don't want to publish my email address as an identifier, in case I get spammed, and if I give an affiliation or even the URL of my website, that may change over time. This problem is addressed by Open Research Contributor Identifiers (ORCID; http://orcid.org), UIDs (and URIs) for scientific and other academic authors. Mine is below. As the website says: ORCID is an open, non-profit, community-driven effort to create and maintain a registry of unique researcher identifiers and a transparent method of linking research activities and outputs to these identifiers. Individuals can sign up for an ORCID at http://orcid.org/ and then include it in their attribution in RfCs, in their research papers, and in other publications. I'd like to propose that we strongly encourage, or even mandate, this for future RfCs. How should I proceed? Is this list the best place for discussion of this topic? Does it need an RfC? If so, would someone care to assist me, please? -- Andy Mabbett @pigsonthewing Website: http://pigsonthewing.org.uk ORCID: http://orcid.org/-0001-5882-6823
Re: ORCID - unique identifiers for contributors
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. On that basis, things we do which make it easier for academic and research assessment processes for STEM careers to consider our work as 'worthy' are good and useful, because they help to direct skilled new brains into our zombie pool. I think ORCID would be the kind of thing which helps. -G On Wed, Sep 18, 2013 at 11:08 AM, John Levine jo...@taugh.com wrote: Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, and that single identifier is not going to be an @ietf.org email address. If you want Yahoo mail or gmail or pobox.com, you know where to find it. Or people here are, I expect, mostly able to arrange for their own vanity domains. R's, John, ab...@no.sp.am
Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'RPKI-Based Origin Validation Operation' draft-ietf-sidr-origin-ops-21.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-01. 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 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present those which are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ballot/ No IPR declarations have been submitted directly on this I-D.
Results of IETF-conflict review for draft-pfaff-ovsdb-proto-03
The IESG has completed a review of draft-pfaff-ovsdb-proto-03 consistent with RFC5742. The IESG has no problem with the publication of 'The Open vSwitch Database Management Protocol' draft-pfaff-ovsdb-proto-03.txt as an Informational RFC. The IESG has concluded that this work is related to IETF work done in WGs I2RS, NETCONF, TRILL and NVO3, but this relationship does not prevent publishing. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-pfaff-ovsdb-proto/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-pfaff-ovsdb-proto/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Protocol Action: 'Using LDP Multipoint Extensions on Targeted LDP Sessions' to Proposed Standard (draft-ietf-mpls-targeted-mldp-04.txt)
The IESG has approved the following document: - 'Using LDP Multipoint Extensions on Targeted LDP Sessions' (draft-ietf-mpls-targeted-mldp-04.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching 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-mpls-targeted-mldp/ Technical Summary RFC 6388 specifies how the Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to- Multipoint (MP2MP) Label Switched Paths. RFC 6388 presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification (RFC 5036) allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a Targeted LDP session. This document provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. Document Quality An implementation poll has been sent to the working group and the information on implementations will be updated as soon as we received information from this poll. There is no need for MIB Doctor or Media Type reviews. This document had a fairly normal working group last call, with good comments that have been addressed. Personnel Loa Andersson (l...@pi.nu) is the document shepherd. Adrian Farrel (adr...@olddog.co.uk) is the responsible AD.
IETF 88 - Meeting Information
88th IETF Meeting Vancouver, BC, Canada November 3-8, 2013 Host: Huawei Meeting venue: Hyatt Regency Vancouver: http://vancouver.hyatt.com/en/hotel/home.html Register online at: http://www.ietf.org/meetings/88/ 1. Registration 2. Visas Letters of Invitation 3. Accommodations 4. Companion Program 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 25 October 2013 UTC 24:00 B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 28 October 2013 at UTC 24:00. Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 1 November 2013, 1700 local Vancouver time. G. On-site Registration starting Sunday, 3 November 2013 at 1100 local Vancouver time. 2. Visas Letters of Invitation: Information on Visiting Canada, please visit: http://www.cic.gc.ca/english/visit/index.asp After you complete the registration process, you can request an electronic IETF letter of invitation as well. The registration system also allows for you to request a hard copy IETF letter of invitation. You may also request one at a later time by following the link provided in the confirmation email. Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to enter Canada. 3. Accommodations The IETF is holding a block of guest rooms at the Hyatt Regency Vancouver, the meeting venue, as well as at the overflow hotel Fairmont Hotel Vancouver, which is located across the street from the Hyatt. Room Rates include in room high-speed Internet access. Taxes of 16.5% (hotel room tax, GST and Destination Management Fee) are excluded from the guestroom rate and are subject to change. Room rates DO NOT include daily breakfast. Reservations Cut off Date: Hyatt Regency Vancouver - 20 October 2013 Fairmont Hotel Vancouver - 11 October 2013 For additional information on rates and policies, please visit: http://www.ietf.org/meeting/88/hotel.html 4. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 25.00 Benefits include: - A special welcome reception for companions from 1630-1730 on Sunday, 3 November - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 3 November - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website or onsite at the meeting. To join the 88 companions mailing list only see: https://www.ietf.org/mailman/listinfo/88companions Only 47 days until the Vancouver IETF!
Results of IETF-conflict review for draft-dolmatov-gost34102012-00
The IESG has completed a review of draft-dolmatov-gost34102012-00 consistent with RFC5742. The IESG has no problem with the publication of 'GOST R 34.10-2012: Digital Signature Algorithm' draft-dolmatov-gost34102012-00.txt as an Informational RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-dolmatov-gost34102012/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-dolmatov-gost34102012/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
RFC 7025 on Requirements for GMPLS Applications of PCE
A new Request for Comments is now available in online RFC libraries. RFC 7025 Title: Requirements for GMPLS Applications of PCE Author: T. Otani, K. Ogaki, D. Caviglia, F. Zhang, C. Margaria Status: Informational Stream: IETF Date: September 2013 Mailbox:tm-ot...@kddi.com, ke-oog...@kddi.com, diego.cavig...@ericsson.com, zhangfa...@huawei.com, cyril.marga...@coriant.com Pages: 12 Characters: 26498 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pce-gmpls-aps-req-09.txt URL:http://www.rfc-editor.org/rfc/rfc7025.txt The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE. This document is a product of the Path Computation Element Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
