Farewell IETF
IETF Friends: My last day with ICANN/IANA/PTI is approaching. (https://mailarchive.ietf.org/arch/msg/ietf-announce/XChBVmmviU5mWMVi3PAxaMSpiNY/) It has been a pleasure working with all of you over the years. Stay safe. I wish you all health and happiness for 2022. --Michelle Cotton Future contact email: mscotton5...@yahoo.com smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: REMINDER: 2021 IANA Annual Customer Engagement Survey
Hello IETF Participants! The IANA Annual Customer Engagement Survey period has been extended and will be closing on December 3, 2021. If you have not done so already, please help us by providing your valuable feedback. Thank you, Michelle Cotton IANA Services From: Michelle Cotton Date: Monday, November 15, 2021 at 3:15 PM To: IETF Announcement List Subject: REMINDER: 2021 IANA Annual Customer Engagement Survey Hello! This is a reminder to participate in the IANA Annual Customer Engagement Survey. Please help us by providing your feedback. It is very much appreciated. Thank you, Michelle Cotton IANA Services From: Michelle Cotton Date: Thursday, October 28, 2021 at 2:55 PM To: IETF Announcement List Subject: 2021 IANA Annual Customer Engagement Survey Dear IETF colleagues, We strive to continuously improve the delivery of the IANA Services to our customers and ensure that we are providing the right level of engagement. We have contracted Echo Research, LLC, an independent research firm to run our 2021 customer survey. Echo Research is committed to protecting the confidentiality of all respondents, and in doing so will follow GDPR guidelines as detailed by EFAMRO, the European Research Federation, written for market research members of ESOMAR world research, and The Market Research Society (MRS). The survey only takes 5-10 minutes to complete. Results will be announced in early 2022. Please click here to participate: https://Ianasurveyg11.echoresearchinsights.com[ianasurveyg11.echoresearchinsights.com] We understand some of you are participants of multiple Internet communities. If you have received an individual invitation from ruth.da...@echoresearchinsights.com to participate in our survey, or if you are subscribed to other mailing lists where we are inviting customers to participate, we kindly ask that you only take the survey once. This survey will close on 24 November 2021. We appreciate your time and look forward to incorporating your feedback in our engagement activities. If you have any questions, please contact marilia.hir...@iana.org. Sincerely, The IANA team smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
REMINDER: 2021 IANA Annual Customer Engagement Survey
Hello! This is a reminder to participate in the IANA Annual Customer Engagement Survey. Please help us by providing your feedback. It is very much appreciated. Thank you, Michelle Cotton IANA Services From: Michelle Cotton Date: Thursday, October 28, 2021 at 2:55 PM To: IETF Announcement List Subject: 2021 IANA Annual Customer Engagement Survey Dear IETF colleagues, We strive to continuously improve the delivery of the IANA Services to our customers and ensure that we are providing the right level of engagement. We have contracted Echo Research, LLC, an independent research firm to run our 2021 customer survey. Echo Research is committed to protecting the confidentiality of all respondents, and in doing so will follow GDPR guidelines as detailed by EFAMRO, the European Research Federation, written for market research members of ESOMAR world research, and The Market Research Society (MRS). The survey only takes 5-10 minutes to complete. Results will be announced in early 2022. Please click here to participate: https://Ianasurveyg11.echoresearchinsights.com[ianasurveyg11.echoresearchinsights.com] We understand some of you are participants of multiple Internet communities. If you have received an individual invitation from ruth.da...@echoresearchinsights.com to participate in our survey, or if you are subscribed to other mailing lists where we are inviting customers to participate, we kindly ask that you only take the survey once. This survey will close on 24 November 2021. We appreciate your time and look forward to incorporating your feedback in our engagement activities. If you have any questions, please contact marilia.hir...@iana.org. Sincerely, The IANA team smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
2021 IANA Annual Customer Engagement Survey
Dear IETF colleagues, We strive to continuously improve the delivery of the IANA Services to our customers and ensure that we are providing the right level of engagement. We have contracted Echo Research, LLC, an independent research firm to run our 2021 customer survey. Echo Research is committed to protecting the confidentiality of all respondents, and in doing so will follow GDPR guidelines as detailed by EFAMRO, the European Research Federation, written for market research members of ESOMAR world research, and The Market Research Society (MRS). The survey only takes 5-10 minutes to complete. Results will be announced in early 2022. Please click here to participate: https://Ianasurveyg11.echoresearchinsights.com[ianasurveyg11.echoresearchinsights.com] We understand some of you are participants of multiple Internet communities. If you have received an individual invitation from ruth.da...@echoresearchinsights.com to participate in our survey, or if you are subscribed to other mailing lists where we are inviting customers to participate, we kindly ask that you only take the survey once. This survey will close on 24 November 2021. We appreciate your time and look forward to incorporating your feedback in our engagement activities. If you have any questions, please contact marilia.hir...@iana.org. Sincerely, The IANA team smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
FW: IANA Interim Office Hours: September 29-30, 2021
This is a reminder that the IANA Services Team will be holding Interim Office Hours. Please see the message below for details. From: Michelle Cotton Date: Friday, September 17, 2021 at 9:19 AM To: IETF Announcement List , "i...@ietf.org" , "wgcha...@ietf.org" Subject: IANA Interim Office Hours: September 29-30, 2021 IETF Community: As part of our 2020 IANA Customer Satisfaction survey, we received a suggestion to have a virtual presence between meetings. In response to this suggestion we will hold trial interim office hours in Gather in between IETF 111 and IETF 112. IETF participants can stop by during a time that works best for them. This is an opportunity to discuss an Internet-Draft or an idea for registry improvements. Appointments can also be made so that if there is any preparation work needed, we can be made aware in advance. Interim office hours will be held in Gather on the following dates: Wednesday, September 29, 2021 12:00 noon UTC - Thursday, September 30, 2021 03:00 AM UTC 0500-2000 US/Canada Pacific 0600-2100 US/Canada Mountain 0700-2200 US/Canada Central 0800-2300 US/Canada Eastern 1200-0300 UTC 1300-0400 United Kingdom 1400-0500 France, Germany 1500-0600 Finland 2000-1100 China Please drop in to Gather using the following link: https://gather.town/app/L4fNNdm1NJa1sE2v/ietf Password: notewell We will be located at the IANA Office Hours desk. This information can also be found here: https://www.ietf.org/how/meetings/gather/ If you would like to make an appointment for a preferred time, please email i...@iana.org and we can make arrangements. Future interim office hours will be determined by the success of this trial. We look forward to “seeing” you. Thank you, Your IANA Services Team i...@iana.org smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IANA Interim Office Hours: September 29-30, 2021
IETF Community: As part of our 2020 IANA Customer Satisfaction survey, we received a suggestion to have a virtual presence between meetings. In response to this suggestion we will hold trial interim office hours in Gather in between IETF 111 and IETF 112. IETF participants can stop by during a time that works best for them. This is an opportunity to discuss an Internet-Draft or an idea for registry improvements. Appointments can also be made so that if there is any preparation work needed, we can be made aware in advance. Interim office hours will be held in Gather on the following dates: Wednesday, September 29, 2021 12:00 noon UTC - Thursday, September 30, 2021 03:00 AM UTC 0500-2000 US/Canada Pacific 0600-2100 US/Canada Mountain 0700-2200 US/Canada Central 0800-2300 US/Canada Eastern 1200-0300 UTC 1300-0400 United Kingdom 1400-0500 France, Germany 1500-0600 Finland 2000-1100 China Please drop in to Gather using the following link: https://gather.town/app/L4fNNdm1NJa1sE2v/ietf Password: notewell We will be located at the IANA Office Hours desk. This information can also be found here: https://www.ietf.org/how/meetings/gather/ If you would like to make an appointment for a preferred time, please email i...@iana.org and we can make arrangements. Future interim office hours will be determined by the success of this trial. We look forward to “seeing” you. Thank you, Your IANA Services Team i...@iana.org smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: 2020 IANA Annual Engagement Survey
Reminder: If you have not already, please participate in the 2020 IANA Annual Engagement Survey. The last day to complete the survey is 25 November 2020. Thank you! Michelle Cotton Protocol Parameters Engagement Sr. Manager IANA Services From: Michelle Cotton Date: Wednesday, October 28, 2020 at 12:13 PM To: IETF Announcement List Subject: 2020 IANA Annual Engagement Survey Dear IETF community, Help IANA evolve their engagement. As a valued customer, your opinion matters. We have revamped the IANA annual engagement survey using the feedback received last year. We also want to share our findings with you. As a thank you for taking part, you will receive a complimentary summary of our findings and outcomes. WHAT NEXT? Please use this link to take part: https://surveys6.jibunu.com/EchoResearch_0002/index.aspx?l=2=uvh3 [surveys6.jibunu.com] ABOUT THE SURVEY It only takes up to 5 minutes to complete Conducted by Echo Research, an independent market research company, on behalf of the IANA services provider PTI (an affiliate of ICANN). Data confidentiality assured Echo Research is committed to protecting the confidentiality of all respondents, and in doing so will follow GDPR guidelines as detailed by EFAMRO, the European Research Federation, written for market research members of ESOMAR world research, and The Market Research Society (MRS). If you have any questions about the survey, please contact Marilia Hirano at: marilia.hir...@iana.org Thank you very much for your time, Michelle Cotton on behalf of our vendor, Ruth David Senior Account Executive Echo Research ruth.da...@echoresearch.com www.echoresearch.com smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
2020 IANA Annual Engagement Survey
Dear IETF community, Help IANA evolve their engagement. As a valued customer, your opinion matters. We have revamped the IANA annual engagement survey using the feedback received last year. We also want to share our findings with you. As a thank you for taking part, you will receive a complimentary summary of our findings and outcomes. WHAT NEXT? Please use this link to take part: https://surveys6.jibunu.com/EchoResearch_0002/index.aspx?l=2=uvh3 [surveys6.jibunu.com] ABOUT THE SURVEY It only takes up 5 minutes to complete Conducted by Echo Research, an independent market research company, on behalf of the IANA services provider PTI (an affiliate of ICANN). Data confidentiality assured Echo Research is committed to protecting the confidentiality of all respondents, and in doing so will follow GDPR guidelines as detailed by EFAMRO, the European Research Federation, written for market research members of ESOMAR world research, and The Market Research Society (MRS). If you have any questions about the survey, please contact Marilia Hirano at: marilia.hir...@iana.org Thank you very much for your time, Michelle Cotton on behalf of our vendor, Ruth David Senior Account Executive Echo Research ruth.da...@echoresearch.com www.echoresearch.com smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Virtual IANA Office Hours - IETF107
Hello IETF, Just a reminder that although we are not physically in Vancouver sitting at our IANA office hours desk, we are always available to answer questions and perform early reviews of documents. Please email i...@iana.org if there is anything we can assist you with. Stay safe and be well. --Michelle Michelle Cotton Protocol Parameters Engagement Sr. Manager smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Reminder: 2019 IANA Annual Engagement Survey
Dear valued IANA customer, We would like to remind you that the Annual IANA Engagement Survey is open until October 11th. If you have not done so yet, please take 5 minutes to respond by clicking on this link: 2019 IANA Engagement Survey: IETF Community [surveys.jibunu.com] https://surveys.jibunu.com/EchoResearch_0001/index.aspx?L=2=11 The survey is administered by a third party vendor – Echo Research, LLC. We look forward to your feedback. Sincerely, The IANA team From: Michelle Cotton Date: Wednesday, September 18, 2019 at 2:21 PM To: Subject: 2019 IANA Annual Engagement Survey Dear IETF Community members, We strive to continuously improve the delivery of the IANA Services to our customers and ensuring that we are providing the right level of engagement. This year, we have contracted Echo Research, LLC, an independent research firm to run our 2019 customer survey. Echo Research is committed to protecting the confidentiality of all respondents, and in doing so will follow GDPR guidelines as detailed by EFAMRA, the European Research Federation, written for market research members of ESOMAR world research, and The Market Research Society (MRS). The survey only takes 5-10 minutes to complete. Results will be announced towards the end of this year. Please click here to participate: 2019 IANA Engagement Survey: IETF Community [surveys.jibunu.com] https://surveys.jibunu.com/EchoResearch_0001/index.aspx?L=2=11 We understand some of you are participants of multiple Internet communities.. If you have received an individual email to participate in our survey, or if you are subscribed to other mailing lists where we are inviting customers to participate, we kindly ask that you only take the survey once. We appreciate your time and look forward to incorporating your feedback in our engagement activities. If you have any questions, please contact marilia.hir...@iana.org Sincerely, The IANA team smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
2019 IANA Annual Engagement Survey
Dear IETF Community members, We strive to continuously improve the delivery of the IANA Services to our customers and ensuring that we are providing the right level of engagement. This year, we have contracted Echo Research, LLC, an independent research firm to run our 2019 customer survey. Echo Research is committed to protecting the confidentiality of all respondents, and in doing so will follow GDPR guidelines as detailed by EFAMRA, the European Research Federation, written for market research members of ESOMAR world research, and The Market Research Society (MRS). The survey only takes 5-10 minutes to complete. Results will be announced towards the end of this year. Please click here to participate: 2019 IANA Engagement Survey: IETF Community [surveys.jibunu.com] https://surveys.jibunu.com/EchoResearch_0001/index.aspx?L=2=11 We understand some of you are participants of multiple Internet communities.. If you have received an individual email to participate in our survey, or if you are subscribed to other mailing lists where we are inviting customers to participate, we kindly ask that you only take the survey once. We appreciate your time and look forward to incorporating your feedback in our engagement activities. If you have any questions, please contact marilia.hir...@iana.org Sincerely, The IANA team smime.p7s Description: S/MIME cryptographic signature ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: An IANA Registry for DNS TXT RDATA (I-D Action: draft-klensin-iana-txt-rr-registry-00.txt)
This is helpful feedback. We are looking at how the listing of the registries is used by the community. There have been suggestions of adding keywords to help when people search for registries. As the list of registries grows, we want to make sure it is useful and that registries can easily be found. We may be requesting community feedback in the near future about how the listing of registries could change. Thank you, --Michelle Michelle Cotton Manager, IANA Services ICANN On 8/30/13 9:13 AM, John C Klensin john-i...@jck.com wrote: --On Friday, August 30, 2013 11:48 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: I believe that draft was superseded by RFC6335 and all service names (SRV prefix labels) are now recorded at http://www.iana.org/** assignments/service-names-**port-numbers/service-names-** port-numbers.xhtmlhttp://www.iana.org/assignments/service-na mes-port-numbers/service-names-port-numbers.xhtml - indeed several of those come from RFCs I have written that add new SRV names. Ah, its there but not in the DNS area where I was looking. And that is exactly the reason why that temporary appendix calls for some rethinking and reorganization of how the registries are organized so as to make that, and similar registries, easier to find. While I continue to believe that doing the work would be a good exercise for a relative newcomer, if one of you wants to go at it, please do so with my blessings. john smime.p7s Description: S/MIME cryptographic signature
Re: Deprecate
We are working on 5226bis right now and have a plans to discuss the term in there. --Michelle Cotton Michelle Cotton Manager, IANA Services ICANN On 8/29/13 5:22 AM, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: It's definitely an ISO term, I see it used for features of C++. There's then discussion even there of what it means. It is, I think, meant to be used for we don't think you should use this, there's something better, and this is a warning that it may get removed in a future version. In the case of computer languages there is an additional possibility of your compiler may emit a warning if you persist in using it. But the only major feature (export) removed in the last C++ version went straight from part of the standard, but only one compiler ever implemented it, and thus found out it was a bad realisation of an idea to removed, with no intermediate deprecated stage. And other features just hang around deprecated. So it really doesn't guarantee anything in that instance, neither than if deprecated will go, not if not deprecated won't go. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.p. Sent: 29 August 2013 12:56 To: ietf Subject: Deprecate --! WARNING ! -- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. I recently saw 'deprecate' used in an IANA Considerations and turned to IANA Considerations [RFC5226] to see how it was defined only to find no mention of it there. I am used to the term from SMI, as quoted below, but that seems not quite right, in that a deprecated IANA entry never disappears, as in http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number s-5 Are there other, perhaps better definitions of the term 'deprecated' in use outside SMI (and yes, I know about praying nuns!)? Tom Petch - Original Message - From: Fred Baker (fred) f...@cisco.com To: IPv6 Maintanence i...@ietf.org Sent: Monday, July 29, 2013 3:32 PM Subject: Deprecate At the mike a moment ago, I referred to an existing formal definition of deprecate. For the record, the reference is to RFC 1158, which reads: 3.1. Deprecated Objects In order to better prepare implementors for future changes in the MIB, a new term deprecated may be used when describing an object. A deprecated object in the MIB is one which must be supported, but one which will most likely be removed from the next version of the MIB (e.g., MIB-III). IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. smime.p7s Description: S/MIME cryptographic signature
Holiday Closure
IETF Community: ICANN Offices will be closed December 26th through January 2nd. We will be checking all IANA related queues for requests/inquiries during the holiday closure. If there are any emergencies, please sent email to i...@iana.org. Thank you! Happy Holidays and Happy New Year to you all! Michelle * Michelle Cotton Manager, IANA Services Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536
IANA Office Hours at IETF-82 in Taipei
Greetings! IANA will be holding Office Hours at the IETF-82 in Taipei. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions/suggestions you may have. We will have a table near the IETF registration area, staffed during the following hours: Monday – Thursday, 0900 – 1600 Thank you and see you soon! Michelle Cotton Manager, IETF Relations - IANA ICANN ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Additional registries converted to XML and announcement of new registry for Service Names and Port Numbers
IETF Community: This is a message for your information. Last year we archived some legacy text files and notified the IETF community which ones those were. This is follow-up message with a new set of registries that have been both converted and archived. A total of 78% of the registries we maintain have been converted to xml. We will repeat this step again in January 2012 with the registries that we convert between July 21, 2011 and December 31, 2011. Attention: We recently combined and converted the Service Names and Port Numbers registry in accordance with a recently approved document to become an RFC. The legacy registries will be maintained for 2 more weeks so that anyone running scripts or gathering information can adjust/update what they need to. Legacy URLs: http://www.iana.org/assignments/service-names/service-names.xml http://www.iana.org/assignments/port-numbers NEW URL: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml We are aware that the new registry is very slow to load in some browsers and we are working on resolving the speed issue. If you have any questions, please do not hesitate to contact me. Thank you, Michelle Cotton Manager, IETF Relations - IANA ICANN List of Registries that have been converted to XML between June 30, 2010 and July 20, 2011: http://www.iana.org/assignments/bgp-data-collection-communities-std http://www.iana.org/assignments/channel-binding-types/ http://www.iana.org/assignments/enum-services http://www.iana.org/assignments/eapsimaka-numbers http://www.iana.org/assignments/eappotp-identifiers http://www.iana.org/assignments/http-parameters http://www.iana.org/assignments/inst-man-values http://www.iana.org/assignments/integ-serv http://www.iana.org/assignments/icmp-parameters http://www.iana.org/assignments/ikev2-parameters http://www.iana.org/assignments/ipp-registrations http://www.iana.org/assignments/ipv6-address-space http://www.iana.org/assignments/ipv6-anycast-addresses http://www.iana.org/assignments/iana-ipv6-special-registry http://www.iana.org/assignments/ipv6-unicast-address-assignments http://www.iana.org/assignments/ipv6-parameters http://www.iana.org/assignments/ipv6-tla-assignments http://www.iana.org/assignments/isns-parameters http://www.iana.org/assignments/idxp-options http://www.iana.org/assignments/isis-tlv-codepoints http://www.iana.org/assignments/language-tags http://www.iana.org/assignments/lmp-parameters http://www.iana.org/assignments/mtqp-options http://www.iana.org/assignments/milnet-parameters http://www.iana.org/assignments/mpls-id-type http://www.iana.org/assignments/text-directory-registrations http://www.iana.org/assignments/pppoe-parameters http://www.iana.org/assignments/port-numbers http://www.iana.org/assignments/pwe3-parameters http://www.iana.org/assignments/public-data-network-numbers http://www.iana.org/assignments/rmt-fec-parameters http://www.iana.org/assignments/rsvp-parameters http://www.iana.org/assignments/ssh-parameters http://www.iana.org/assignments/svrloc-cryptographic-bsd http://www.iana.org/assignments/svrloc-error-numbers http://www.iana.org/assignments/service-names http://www.iana.org/assignments/sip-table http://www.iana.org/assignments/sip-priv-values http://www.iana.org/assignments/sieve-extensions http://www.iana.org/assignments/sieve-environment-items http://www.iana.org/assignments/sasl-mechanisms http://www.iana.org/assignments/smtp-enhanced-status-codes http://www.iana.org/assignments/snmp-number-spaces http://www.iana.org/assignments/sun-rpc-numbers http://www.iana.org/assignments/tcp-header-flags http://www.iana.org/assignments/sdp-security-descriptions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
+1 Michelle On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen, We do have some technical expertise within the IANA staff, however our expertise is more aligned with the process of creating and maintaining registries. Part of that includes relying on the experts that the IESG designates to make the decisions for requests that utilize the Expert Review policy in RFC 5226. In the past, if there is strong disagreement from an expert and the requester disagrees, we have brought the Transport Area Directors into the communications to see if all parties can come to an agreement. In almost all cases, this is where a final decision is made. If that set of folks can not come to a conclusion, we then would default to going to the IESG. With all requests, if there is any uncertainty as to what decision should be made, we go to the IESG for guidance. We do rely on the technical expertise of the appointed experts for all registries, but we ALWAYS have the possibility to seek guidance form the IESG. I don't believe we have ever had an official appeals with ports (Knocking on wood really hard!). Does that help? --Michelle On 1/31/11 8:33 AM, Cullen Jennings flu...@cisco.com wrote: So IANA has a huge amount of technical expertise and takes maintaing the registries very seriously. I've seen them catch technical mistakes that made all the way through WG and IESG review. I've got huge respect for technical competence of IANA and in particular Michelle. So I'm not questions that but I don't recall seeing them override an expert on a technical issue. I'd be happy to hear of examples but lets consider the example I am actually concerned about here. I put in a request for a latency sensitive protocol that uses DTLS and request a different port for the secure version. Joe as expert review says we should redesign the protocol to use something like STARTLS and run on one port. I assert, with very little evidence, that will not meet the latency goals of the protocol. Joe does not agree. So Michelle, in that case, would you be willing to override Joe? I'm sure you would be willing to help facilitate any conversations, bring in other people such as ADs that can help etc. I was sort of working on the assumption that you would not override Joe in this case and the the only path forward would be an appeal to Lars but perhaps that is just a bad assumption on my part. Appeals are really the worst way possible to resolve things. I have a hard time imagining that IANA would want to engage in a technical discussion to resolve this and instead relies on the expert reviewer. I'll note that the expert review may report to IANA but they are selected by and replaced by the IESG. The important point here is that I really don't care if it is Joe or IANA that is saying no - I think this document should be clear that this BCP can not be used as grounds for rejecting the request for a second port for security. On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote: Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote: Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
We are changing that process right now. We have begun to report the reviewer (with the review) in the email to the requester. We just need to make sure this small change is communicated to those experts that are part of review teams as their individual names are not published on the main list of registries. I don't think it needs to go in this document as this is already in progress. Let me know if you have any questions. --Michelle On 1/27/11 5:10 PM, Joe Touch to...@isi.edu wrote: On 1/27/2011 12:52 AM, Lars Eggert wrote: ... Small Issue #3: I object to anonymous review The current review is anonymous and this draft does not seem to change that. I don't like anonymous review - it's not how we do things at IETF and it encourages really bad behavior. I have several emails with an expert reviewer relayed via IANA where the conversation was going no where - once I knew the name of the reviewer, the whole conversation changed and stuff quickly came back to the realm of sane. I'm not willing to forward these emails to the list as that would just not be kind to anyone but I am happy to forward them to the IESG if they think looking at them is really critical. I can see your point, and I personally have no problem with disclosing the reviewer identity. What do others think? AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I.e., we are advisors to IANA. Further, many requests are handled my multiple reviewers. Many of us do have specific conversations with applicants, and identify ourselves when that happens, but it doesn't seem important to codify that in this doc. Again, this doc is about the unification of the registries. It is NOT about all the other policies that govern them. The info that's there is advisory ONLY (it is not binding to IANA). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Many believe it makes it very clear to the users of the registry what is available for assignment. Something we will be rolling out soon (for those registries with a finite space) will be small charts showing how much of the registry space is unassigned, assigned and reserved (utilizing the unassigned entries). --Michelle On 1/12/11 6:35 AM, Julian Reschke julian.resc...@gmx.de wrote: On 12.01.2011 15:22, Adrian Farrel wrote: Entirely at random I clicked on: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml http://www.iana.org/assignments/calipso/calipso.xhtml http://www.iana.org/assignments/lmp-parameters Looks like IANA tries to fill up all the blanks with markers of unassigned. Is that harmful? Minimally, it's redundant. Also, it only makes sense on certain types of registries. I just checked the XML version of the first registry, and, indeed, it contains entries for unassigned values. /me shakes head in disbelief. What *should* be done is computing the unassigned ranges for *presentation*; that is, they should not be part of the actual registry. The way it's done currently defeats one of the reasons of having a machine-readable registry (consumers will have to hard-wire knowledge of the specific unassigned entry to make sense of the registry). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-78 in Beijing
Greetings! IANA will be holding Office Hours at the IETF-79 in Beijing. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. We will have a table near the IETF registration area, staffed during the following hours: Monday – Thursday, 0900 – 1600 Thank you and see you soon! Michelle Cotton Manager, IETF Relations - IANA ICANN ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Archiving more legacy text files
IETF Community: Earlier this year we archived some legacy text files and notified the IETF community which ones those were. This is follow-up message with a new set of registries that will be archived soon. Background: In cooperation with the IETF Community, we have been working on a project to publish the registries we maintain for the IETF in XML. With the help of RFC authors, WG chairs, Area Directors and Experts we have made considerable progress. In order to give the community plenty of time to change scripts, pointers or just become aware of the new formats, we have been updating and making available both the old legacy text files and the new XML versions for newly converted registries. Since we believe sufficient time has now passed and maintaining the legacy files has a non-trivial administrative impact, we will no longer be making available the old legacy text files and will archive them. The old URLs will contain information for the location of the new versions available (TXT, XML and XHTML). The legacy text registries will be changed to the pointer text beginning on August 9, 2010. We will repeat this step again in January 2011 with the registries that we convert between July 1, 2010 and December 31, 2010. Thank you, Michelle Cotton Manager, IETF Relations - IANA ICANN List of Registries that have been converted to XML between January 1, 2010 and June 30, 2010: http://www.iana.org/assignments/dkim-parameters http://www.iana.org/assignments/eap-numbers http://www.iana.org/assignments/eap-pax http://www.iana.org/assignments/gmpls-sig-parameters http://www.iana.org/assignments/gssapi-service-names http://www.iana.org/assignments/method-tokens http://www.iana.org/assignments/location-type-registry http://www.iana.org/assignments/gsmpv3-adapt http://www.iana.org/assignments/gsmpv3-event http://www.iana.org/assignments/gsmpv3-failure http://www.iana.org/assignments/gsmpv3-label http://www.iana.org/assignments/gstn-extensions http://www.iana.org/assignments/im-srv-labels http://www.iana.org/assignments/ipv4-tos-byte http://www.iana.org/assignments/ipv6-multicast-addresses http://www.iana.org/assignments/ip-xns-mapping http://www.iana.org/assignments/machine-names http://www.iana.org/assignments/mail-encoding http://www.iana.org/assignments/media-feature-tags http://www.iana.org/assignments/multicast-addresses http://www.iana.org/assignments/ospf-authentication-codes http://www.iana.org/assignments/ospf-sig-alg http://www.iana.org/assignments/operating-system-names http://www.iana.org/assignments/pronet80-type-numbers http://www.iana.org/assignments/radius-types http://www.iana.org/assignments/rip-types http://www.iana.org/assignments/spi-numbers http://www.iana.org/assignments/scsp-numbers http://www.iana.org/assignments/sip-events http://www.iana.org/assignments/sip-precond-types http://www.iana.org/assignments/sieve-notification http://www.iana.org/assignments/notification-capability-parameters http://www.iana.org/assignments/sgmp-vendor-specific-codes http://www.iana.org/assignments/safi-namespace http://www.iana.org/assignments/tsig-algorithm-names ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-78 in Maastricht
Greetings! IANA will be holding Office Hours at the IETF-78 in Maastricht. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. We will have a table near the IETF registration area, staffed during the following hours: Monday - Thursday, 0900 - 1600 Thank you and see you soon! Michelle Cotton Manager, IETF Relations - IANA ICANN ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IANA Office Hours at IETF-77 in Anaheim
Greetings! IANA will be holding Office Hours at the IETF-77 in Anaheim. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. We will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 (May also have additional hours on Thursday) Thank you and see you soon! Michelle Cotton Manager, IETF Relations - IANA ICANN ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Archiving legacy text files
Attention IETF Community: In cooperation with the IETF Community, we have been working on a project to publish the registries we maintain for the IETF in XML. With the help of RFC authors, WG chairs, Area Directors and Experts we have made considerable progress. In order to give the community plenty of time to change scripts, pointers or just become aware of the new formats, we have been updating and making available both the old legacy text files and the new XML versions for over a year. Since we believe sufficient time has now passed and maintaining the legacy files has a non-trivial administrative impact, we will no longer be making available the old legacy text files and will archive them. The old URLs will contain information for the location of the new versions available (TXT, XML and XHTML). The legacy text registries will be changed to the pointer text beginning on April 5, 2010. We will repeat this step again in July with the registries that we convert between January 1, 2010 and June 30, 2010. Thank you, Michelle Cotton Manager, IETF Relations - IANA ICANN List of Registries that have been converted to XML prior to January 1, 2010: http://www.iana.org/assignments/aodv-parameters http://www.iana.org/assignments/address-family-numbers http://www.iana.org/assignments/arp-parameters http://www.iana.org/assignments/apex http://www.iana.org/assignments/acap-registrations http://www.iana.org/assignments/link-relations http://www.iana.org/assignments/aead-parameters http://www.iana.org/assignments/aka-version-namespace http://www.iana.org/assignments/aaa-parameters http://www.iana.org/assignments/auto-submitted-keywords http://www.iana.org/assignments/as-numbers http://www.iana.org/assignments/bfcp-parameters http://www.iana.org/assignments/beep-parameters http://www.iana.org/assignments/bgp-parameters http://www.iana.org/assignments/capability-codes http://www.iana.org/assignments/bgp-well-known-communities http://www.iana.org/assignments/building-blocks http://www.iana.org/assignments/caller-id-plans http://www.iana.org/assignments/card-parameters http://www.iana.org/assignments/ex-mobility-subtypes http://www.iana.org/assignments/cert-rr-types http://www.iana.org/assignments/cnrp-parameters http://www.iana.org/assignments/cpim-headers http://www.iana.org/assignments/message-header-types http://www.iana.org/assignments/cxtp-parameters http://www.iana.org/assignments/capwap-parameters http://www.iana.org/assignments/crypto-suites http://www.iana.org/assignments/cga-message-types http://www.iana.org/assignments/dccp-parameters http://www.iana.org/assignments/dccp-ccid2-parameters http://www.iana.org/assignments/dccp-ccid3-parameters http://www.iana.org/assignments/ds-rr-types http://www.iana.org/assignments/dsn-types http://www.iana.org/assignments/dscp-registry http://www.iana.org/assignments/directory-system-names http://www.iana.org/assignments/dnssec-nsec3-parameters http://www.iana.org/assignments/dnskey-flags http://www.iana.org/assignments/dns-sshfp-rr-parameters http://www.iana.org/assignments/dns-key-rr http://www.iana.org/assignments/dns-sec-alg-numbers http://www.iana.org/assignments/auth-namespaces http://www.iana.org/assignments/bootp-dhcp-parameters http://www.iana.org/assignments/dhcpv6-parameters http://www.iana.org/assignments/dsr-parameters http://www.iana.org/assignments/ecml-parameters http://www.iana.org/assignments/ecmlv2-parameters http://www.iana.org/assignments/emsk-parameters http://www.iana.org/assignments/eap-psk-parameters http://www.iana.org/assignments/eap-fast-parameters http://www.iana.org/assignments/eap-ikev2-payloads http://www.iana.org/assignments/eap-sake-parameters http://www.iana.org/assignments/fc-port-types http://www.iana.org/assignments/foobar-af-numbers http://www.iana.org/assignments/forces-parameters http://www.iana.org/assignments/os-specific-parameters http://www.iana.org/assignments/gre-parameters http://www.iana.org/assignments/gsmpv3-model http://www.iana.org/assignments/gsmpv3-port http://www.iana.org/assignments/gsmpv3-result http://www.iana.org/assignments/gsmpv3-service http://www.iana.org/assignments/gsmpv3-traffic http://www.iana.org/assignments/hash-function-text-names http://www.iana.org/assignments/hip-parameters http://www.iana.org/assignments/http-dig-alg http://www.iana.org/assignments/http-upgrade-tokens http://www.iana.org/assignments/params http://www.iana.org/assignments/imdn http://www.iana.org/assignments/iax-parameters http://www.iana.org/assignments/imap-threading-algorithms http://www.iana.org/assignments/urlauth-authorization-mechanism-registry http://www.iana.org/assignments/message-store-events http://www.iana.org/assignments/ipv4-address-space http://www.iana.org/assignments/ipv6-address-space http://www.iana.org/assignments/iana-ipv6-special-registry http://www.iana.org/assignments/ipv6-unicast-address-assignments http
IANA Office Hours at IETF-76 in Hiroshima
Greetings! The IANA will be holding Office Hours at the IETF-76 in Hiroshima. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 (May also have additional hours on Thursday) Thank you and see you soon! Michelle Cotton Manager, IETF Relations ICANN/IANA ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: IANA tickets
IANA is looking into the tickets immediately. Thank you, Michelle Cotton IANA On 7/8/09 4:16 AM, Julian Reschke julian.resc...@gmx.de wrote: Hi, does anybody know whether something is broken with respect to IANA's mail system? I have two outstanding issues, one almost 4 months old, for which I'm not getting any feedback, and a follow up email was ignored as well... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-74 in San Francisco
Greetings! The IANA will be holding Office Hours at the IETF-74 in San Francisco. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 (May also have additional hours on Thursday) Thank you and see you soon! Michelle Cotton Manager, IETF Relations Internet Assigned Numbers Authority ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-73 in Minneapolis
Greetings! The IANA will be holding Office Hours at the IETF-73 in Minneapolis. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 Thank you and see you soon! Michelle Cotton Manager, IETF Relations Internet Assigned Numbers Authority ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IANA Update: Project to convert registries to XML
FTP access to the assignments directory has been restored. It may take up to 24 hours to properly resolve ftp.iana.org. As James mentioned in his message below, rsync was never operational, however we plan to make that available in the next few weeks. We are also working on other new services such as the ability to subscribe to be notified when specific registries are updated. Thanks again for the feedback. Michelle Cotton IANA On 7/21/08 1:29 PM, James Cloos [EMAIL PROTECTED] wrote: Stephane == Stephane Bortzmeyer [EMAIL PROTECTED] writes: Stephane Why a dVCS? Any VCS would make it, and Subversion, for Stephane instance, would be a good choice. If we use a dVCS, More efficient. Everything works better with local history. Svn wastes a lot of disk by keeping two copies of every file in each checkout. At least a dVCS can compress the store. Stephane I vote for darcs. Doesn't darcs have a bug they can't fix? esr's recent survey of the dVCSs concluded that git, hg and bzr are the best choices. He considered performance, as well as community involvement and how many other projects are using each dVCS, on the theory that bugs get fixed faster when more people use it. -JimC (As a side note, my initial mention of rsync breaking was a misnomer. My rsync job only grabs rfcs and i-ds. I had conflated that with a request I sent some months (years?) back to make ftp.iana.org rsyncable. It is only ftp which hadn't been updated since April. And in a off-list reply IANA said they plan to fix that.) -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-72 in Dublin
Greetings! The IANA will be holding Office Hours at the IETF-72 in Dublin. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 Please stop by and say hello. IANA will also be participating in the Document Lifecycle Tutorial on Sunday. There we will describe IANA's role in the document lifecycle and provide tips on making sure your document has the necessary information if protocol registrations are needed. Thank you and see you in Ireland! Michelle Cotton Manager, IETF Relations Internet Assigned Numbers Authority ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Problem with IANA MIME media types registry
We are working on fixing the media-types page. Michelle Cotton IANA On 7/15/08 5:24 AM, Laura Webster [EMAIL PROTECTED] wrote: do you have a pic for chris lilley do you have is dvd naw can you email back from laura webster 2005-12-12 08:30 Chris Lilley kirjoitti: On Sunday, December 11, 2005, 3:39:58 PM, Bruce wrote: BL [CC'd to IETF discussion list and ietf-types discussion list] BL Hello, BL Recent changes to the page at BL http://www.iana.org/assignments/media-types/index.html BL accessed via the link from the IANA Assigned numbers page BL http://www.iana.org/numbers.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Update: Project to convert registries to XML
IETF Community: As first announced in April 2008, IANA is improving the formatting of its protocol registries by migrating the source format of these registries to structured XML format. We are pleased to announce the first set of migrated registries have now come online. Prior to this migration, typically protocol registries were formatted in a plain text version. Now, with XML formatted source documents, IANA will publish a number of different formats for converted registries. In particular, converted registries will initially be available in XML, XHTML and plain text versions. It is intended that XHTML become the preferred format for viewing registries, with plain text being made available for accessibility reasons. The remainder of the registries which are not yet converted require further consultation on formatting issues. It is intended that over the coming months these issues will be resolved and the conversion will be completed. Some registries that have specific formatting requirements, such as Management Information Base (MIB) files, will not be converted. In order to make the transition as smooth as possible, IANA will continue to maintain the legacy plain text formats until 30 November 2008. After this date, plain text versions will only be provided that are derived from the XML formats. However, implementors who intend to parse the contents of an IANA protocol registry should migrate to using the XML versions, rather than the plain text version. All existing URLs to protocol registries shall continue to work, and the new formats will be available from our website at http://www.iana.org/protocols/ as they are rolled out. An example of a converted registry is: http://www.iana.org/assignments/aaa-parameters (legacy text version) http://www.iana.org/assignments/aaa-parameters/aaa-parameters.txt (new text version) http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml (new HTML version) http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml (new XML version) The next steps (in addition to completing the remaining registries) includes introducing new services such as the ability to subscribe to be notified of registry changes. IANA will continue to provide updates to the IETF list as more steps are completed. If you have any questions regarding this project or regarding the format of the registries, please contact IANA ([EMAIL PROTECTED]) or myself (contact information found below). Thank you, Michelle Cotton IANA IETF Liaison Email: [EMAIL PROTECTED] *** Initial Announcement: Wed, 23 Apr 2008 Subject: IANA Update: Project to convert registries to XML IANA is currently engaged in a project to convert the IETF related registries to XML to provide the community with multiple ways of viewing registry information. When conversion to XML is done, XML will become the source format for the registries and the current formats of html and plain text will be generated from the XML source. Stylesheets and schemas will also be made available together with XML. Users will be able to access the registries in new and useful ways, while still having the ability to see the registries in the original style. Part of the conversion requires IANA to clean-up the registries in order to fit with the XML schemas. IANA is not changing the data in the registries. IANA is cleaning up the formatting including regularizing spacing and providing consistent display of titles, references and registration procedures. For those registries that need extensive format changes, IANA will be working with the appropriate working groups and area directors to make sure that the format changes do not affect the content of the registry. Those registries that are required to be in specific formats, for example the MIBs and language subtags registries, will still be produced in the existing formats. IANA has consulted with the IETF XML directorate to make sure that the XML schemas are properly formulated. Certain decisions on schemas reflect the needs of IANA in maintaining the registries moving forward. In the coming months, cleaned-up versions of the registries will begin appearing on the IANA website. If you notice any content issues with the updated versions, or if they are not accessible, please notify IANA staff immediately and we will work with the appropriate parties to correct any inconsistencies. We look forward to providing the XML versions of the registries to better serve the community's needs. IANA will announce in advance when the registry conversion will be completed. After the conversion is complete, we intend to introduce new services such as the ability to subscribe to be notified when specific registries are updated Thank you, Michelle Cotton IANA IETF Liaison Email: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Update: Project to convert registries to XML
IETF Community: IANA is currently engaged in a project to convert the IETF related registries to XML to provide the community with multiple ways of viewing registry information. When conversion to XML is done, XML will become the source format for the registries and the current formats of html and plain text will be generated from the XML source. Stylesheets and schemas will also be made available together with XML. Users will be able to access the registries in new and useful ways, while still having the ability to see the registries in the original style. Part of the conversion requires IANA to clean-up the registries in order to fit with the XML schemas. IANA is not changing the data in the registries. IANA is cleaning up the formatting including regularizing spacing and providing consistent display of titles, references and registration procedures. For those registries that need extensive format changes, IANA will be working with the appropriate working groups and area directors to make sure that the format changes do not affect the content of the registry. Those registries that are required to be in specific formats, for example the MIBs and language subtags registries, will still be produced in the existing formats. IANA has consulted with the IETF XML directorate to make sure that the XML schemas are properly formulated. Certain decisions on schemas reflect the needs of IANA in maintaining the registries moving forward. In the coming months, cleaned-up versions of the registries will begin appearing on the IANA website. If you notice any content issues with the updated versions, or if they are not accessible, please notify IANA staff immediately and we will work with the appropriate parties to correct any inconsistencies. We look forward to providing the XML versions of the registries to better serve the community's needs. IANA will announce in advance when the registry conversion will be completed. After the conversion is complete, we intend to introduce new services such as the ability to subscribe to be notified when specific registries are updated Thank you, Michelle Cotton IANA IETF Liaison Email: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Query
Yes. For ports specifically see http://www.iana.org/assignments/port-numbers Most registrations with individuals listed as the contact applied directly to IANA. Other registrations were made through publication of RFCs. Let us know if you have any further questions. Thank you, Michelle Cotton IANA On 3/25/08 6:16 AM, Gupta, Kapil [EMAIL PROTECTED] wrote: Good Day All, I have a question. Did any one try to register any port for his/their application/service through IANA? Please help. Thank You, Kapil The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-71 in Philadelphia
Greetings! The IANA will be holding Office Hours at the IETF-71 in Philadelphia. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 Please stop by and say hello. Thank you and see you in Philly! Michelle Cotton Manager, IETF Relations Internet Assigned Numbers Authority ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IANA Office Hours at IETF-70 in Vancouver
Greetings! The IANA will be holding Office Hours at the IETF-70 in Vancouver. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 Please stop by and say hello. Thank you and see you in Vancouver! Michelle Cotton Manager, IETF Relations Internet Assigned Numbers Authority ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
Keep in mind that the interview with Mr. McBride was back in April 2004. The response times back then may not have been great, but IANA has never charged an applicant for their request for protocol parameters including port numbers. IANA response times have greatly improved over the last few years. See: http://www.iana.org/reporting-and-stats/index.html (Performance Charts) In cases where experts are used, IANA has a reminder system in place as well as an escalation process to notify the IESG if an expert is not responding to IANA. With regards to the protocol numbers described in arkko-rfc2780-proto-upate, there are only approximately 115 that are unassigned in the registry. This is a scarce resource and care should taken in making assignments. This document does not change much in actual procedures with the IANA as a protocol number has not been assigned under NDA for at least 6 years if not longer. Hope this information is helpful. Michelle Cotton Manager, IETF Relations IANA -- From: Bernard Aboba [EMAIL PROTECTED] To: ietf@ietf.org Date: Tue, 6 Nov 2007 07:02:08 -0800 (PST) Subject: Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP I also think this is an appropriate, even if significant, change of policy. I really don't see why we would give away a precious resource such as a protocol number for secret usage. I also agree that the change is appropriate. However, I am also aware of significant frustration being voiced with respect to the speed by which the expert review process moved -- and this change could slow it further. It's worth keeping in mind that the IETF has no power to prevent people from using unallocated protocol numbers. For example, see: http://kerneltrap.org/node/2873 Quoting from Ryan McBride: The IANA has a heavily bureaucratic process for getting official number assignments. There are essentially two options for getting a protocol number assigned: The first is to run your protocol through the IETF on a standards track. This avenue is closed to us - the IETF has become monopolized by large corporate interests, and they have no problem with using patented protocols. They're perfectly happy using VRRP, and they won't support another standard. The second path is their proprietary path; you pay for experts to review your protocol and if they agree that it requires the numbers you're asking for, you get it. If you look at the list of assigned protocol numbers, this method appears to be the favored one. Getting a number allocation has more to do with having money. Obviously, since we're not a large multinational corporation, we can't afford to take this path. Since they were unable to help us by providing a real alternative, our only option is to simply pick an unused number and go with that. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --- End of Forwarded Message ___ Ietf-iana mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-iana ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-69 in Chicago
Greetings! The IANA will be holding Office Hours at the IETF-69 in Chicago. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Thursday, 0900 - 1600 Please stop by and say hello. Thank you and see you in Chicago! Michelle Cotton IETF IANA Liaison (on behalf of the IANA team) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IANA Office Hours at IETF-68 in Prague
Greetings! The IANA will be holding Office Hours at the IETF-68 in Prague. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Thursday, 0900 - 1600 Please stop by and say hello. Thank you and see you in Prague! Michelle Cotton IETF IANA Liaison (on behalf of the IANA team) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
FW: [EMAIL PROTECTED]: Re: Problem with IANA MIME media types registry]
Bruce, This has been fixed. The index file was accidentally overwritten with the application media types page. Thank you for letting us know. Best regards, Michelle Cotton IANA - Forwarded message from Bruce Lilly [EMAIL PROTECTED] - Date: Sun, 11 Dec 2005 10:42:22 -0500 Subject: Re: Problem with IANA MIME media types registry From: Bruce Lilly [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], ietf@ietf.org, [EMAIL PROTECTED] On Sun December 11 2005 10:06, Allison Mankin wrote: Bruce, FYI, the other top-level media types are still there on their FTP site, so this looks like something went wrong with their web generating approach, whatever that is... ftp://ftp.iana.org/assignments/media-types/ Allison P.S. I happened to have the FTP version on my radar. Thanks for the information -- the index.html file at the ftp site has a revision date of 23-Aug-2005, whereas the file served via HTTP is dated 30-November-2005. I would have expected the same file to be served by both protocols, with index.html being the default for HTTP. That that is evidently not happening is yet another cause for concern, as it means that different access methods yield different registration information. Possibly the IANA HTTP server is sending the application data (only) instead of index.html. I've taken the liberty of copying the lists and IANA to update the information regarding the registry. Best regards, Bruce Lilly ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf - End forwarded message - -- Kent Crispin [EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649 [EMAIL PROTECTED] SIP: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
