Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Hi John, On 9/9/12 8:43 PM, John Levine wrote: Let's say I write to the IESG and say this: Due to a late night editing error, draft-foo-bar-42 which I submitted yesterday contains several paragraphs of company confidential information which you can easily see are irrelevant to the draft. My boss wants it taken down pronto, even though he realizes that third parties may have made copies of it in the meantime. I will probably lose my job if it stays up for more than a few days. Thanks for your consideration. Is this the response? You didn't make any legal threats, and now that we know the situation, we wouldn't believe any legal threats you might make in the future, so you better check out those burger flipping opportunities. No, the response is that we refer you to our policy. As an open organization we do not remove information once posted, except under extraordinary circumstances. What was wrong with the original version which gave the IESG the latitude to remove an I-D if they feel, for whatever reason, that it would be a good idea to do so? What original? The draft policy states: An I-D will only be removed from the public I-D archive in compliance with a duly authorized court order. If the IESG were so screwed up that they started deleting I-Ds for bad reasons, no amount of process verbiage would help. Certainly, but let's not start from the wrong place to begin with. Let's also set expectations that the IESG may be used to clean up after other peoples' messes. They have enough to do. And again, this is best developed with counsel. Regards, Eliot
Re: IETF...the unconference of SDOs
Michael Richardson {quigon} m...@sandelman.ca wrote:
Let me suggest that at the IETF, where the mailing list is king, you
can't join the Elite if you can't quote email properly. Maybe we should
*state* this.
:-)
Maybe I'm also concerned because many in the former elite have moved
to Apple Mail, and it seems that it is bug compatible with Outlook in
it's assumption that format=flowed is the default, an act which destroys
email quoting, and therefore discussion.
I feel a bit sorry for Apple Mail. It used to use format=flowed very
nicely, but stopped presubably for bug compatibility with Outlook which
treats a flowed paragraph as a sequence of one-line paragraphs.
There are some other interop problems caused by Outlook's gratuitous
disregard for standards:
multipart/mixed; Content-Disposition: inline doesn't work very well.
(I predict Apple Mail will stop generating this too.)
message/rfc822 attachments don't work. If it did it would be a much better
way to do forwarding and top-posting repliesthan at present. (For
instance, Outlook can hide those horrible confusing email addresses rather
than stripping them out.)
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
RE: the usual mail stuff, was IETF...the unconference of SDOs
If someone wants to provide guidance on how to do a least bad job with Outlook, that will be gratefully received. But advice that says don't use Outlook will be filed with the advice that says pick another employer to work for. -- 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 John Levine Sent: 09 September 2012 20:26 To: ietf@ietf.org Subject: Re: the usual mail stuff, was IETF...the unconference of SDOs --! 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 have to say that I'm baffled at the perverse pride that people seem to take in being so technically backward that they're unable to handle the mail that 99% of the world uses today. While not being a fan of overdecorated HTML and endless font changes, and strongly preferring a mail program that lets me keep my fingers on the keyboard, I can deal with it. (I use Alpine, keep meaning to take another look at mutt.) I remember how to punch drum cards, but I have no interest in using one to send mail in 2012. For the large majority of mail that is written in paragraphs rather than tables, line wrapping is a useful feature, regardless of the character set, particularly for those of us who sometimes read our mail on a tablet or phone while changing planes. For mail that is a table and stuff has to line up in columns, use HTML tables. That's what they're for. R's, John PS: Yes, this is top posted. You can deal with that, too. Unfortunately there's some stuff going around that line wrapping with hard line terminations is retrograde and goes back to punch cards. I guess that's probably true but aside from the fact that I'm retrograde and go back to punch cards, myself, application line wrapping and flowed text don't deal well (yet) with multiple character sets, fonts, etc. and I'll take readability over application purity every single time. 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.
Re: the usual mail stuff, was IETF...the unconference of SDOs
On Sep 10, 2012, at 12:46, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: If someone wants to provide guidance on how to do a least bad job with Outlook, that will be gratefully received. I'm not an expert for this, but, as far as I am aware of, it has not been possible to productively participate in e-mail conversations using Outlook. But advice that says don't use Outlook will be filed with the advice that says pick another employer to work for. For a while, the stock advice has been slightly different: Get a $WEBMAIL account, where one popular value for WEBMAIL is gmail. Of course, if policies prevent using the Web from workplace, I feel your pain. Grüße, Carsten
Re: the usual mail stuff, was IETF...the unconference of SDOs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/10/2012 03:46 AM, Dearlove, Christopher (UK) wrote: If someone wants to provide guidance on how to do a least bad job with Outlook, that will be gratefully received. But advice that says don't use Outlook will be filed with the advice that says pick another employer to work for. OK, here's how your post looks in my mailer: http://ietf.implementers.org/irony.png - -- Marc Petit-Huguenin Email: m...@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQTgtwAAoJECnERZXWan7EOXwQANMQLtZ8JajzX3VK2M1PrpT/ ORkEVIva9GseZWo15zQre8NGdVlY/omRyGjAaoIFXKuWIRObXu4rftZ2HHQ2OKe1 FQZoqKFSx8i2G6yBie9VL1NNmBS0InPYcflK0aZOGr7jNjGBP3EGHCnX5ouJtcB/ pXDTXQbXOM71jPujyV6JJZ2sFGKtdNSOltd8FwkqqogkMK6S5PxJmYnV/4I+iBVl c82wD04nx+vS5UiF3gJiSWGdmIZ48m5ShODxYTTYPvXZhLRS/lTYpTcx+Rv9RCam Xwo+MYW0qiW89x4SGXMzCXAEtP2VxBfII/jWxiKGdcoH9877++c6yW2fFDQU/Qv4 x4uw9+rigncwSmLAQnr1UZ+APWRmq0DLH2X6J4pMFsMH9NuTCaLlRVHgizrgG6LW nrTI34Xsp3A0WmP2H6IZCFtur1BAVio2JMp26MZsWKDAa0aD3ClJvlk/Ju37VsKV JVujmJVnS0JHYJjK1BY1TWLhumusgEIrtl+4jM9yVMOS+DCJj5fB66Lnw1DJq/e3 hwhwRZcTk+obmdCf9eQIsAeH1HXxzkupJDQKDnMQe8gF3su6QeWap7YFFCAc7PXT Xycq9qw2YskkWGNHwsZW/LId33M/SuKlKsqZgrEFoKBe/AwkBeQntdIoLQp/Rw4Y uRoC3rlQDqpgdENYw0vV =KpjV -END PGP SIGNATURE-
RE: Proposed IETF Meeting Calendar 2018 - 2022
The first week of November dates for 2018, 2021 and 2022 are likely to conflict with T10 (SCSI storage standards body). Thanks, --David (storm WG co-chair) -Original Message- From: wgchairs-boun...@ietf.org [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF Administrative Director Sent: Thursday, September 06, 2012 3:16 PM To: IETF Announcement List Cc: i...@ietf.org; i...@iab.org; ietf@ietf.org; wgcha...@ietf.org Subject: Proposed IETF Meeting Calendar 2018 - 2022 All; Below are suggested Meeting dates for 2018 - 2022, IETF's 101 - 115. The IAOC is soliciting the community's feedback before adopting. Comments appreciated to ietf@ietf.org by 20 September 2012. Ray 2018 IETF 101 18-23 March 2018 IETF 102 22-27 July 2018 IETF 103 4 - 9 November 2018 2019 IETF 104 24 - 29 March 2019 IETF 105 21 - 26 July 2019 IETF 106 17 - 22 November 2019 2020 IETF 107 22 - 27 March 2020 IETF 108 26 - 31 July 2020 IETF 109 15 - 20 November 2020 2021 IETF 110 21 - 26 March 2021 IETF 111 25 - 30 July 2021 IETF 112 7 - 12 November 2021 2022 IETF 113 20 - 25 March 2022 IETF 114 24 - 29 July 2022 IETF 115 6 - 11 November 2022
Re: IETF 95 Date Change Proposal - Round 2
Hi Ray, 1-3 April 2016 will be holiday in China. If the time is 3-8 April, then many Chinese attendees have to give up the holiday. Would you propose another time? Thank you. Lizhong - Forwarded on 2012-09-10 09:40 - IETF Administrative Director i...@ietf.org Sender: ietf-boun...@ietf.org 2012-09-07 03:11 To IETF Announcement List ietf-annou...@ietf.org CC i...@ietf.org, i...@iab.org, ietf@ietf.org, wgcha...@ietf.org, i...@ietf.org Subject IETF 95 Date Change Proposal - Round 2 All The IAOC is seeking community feedback on a proposed date change for IETF 95 originally scheduled for 27 March to 1 April 2016. After considering community feedback on a proposed change to 20 - 25 March 2016, the IAOC is proposing 3 - 8 April 2016 to avoid the impact on travel and attendance during the 20 - 25 March period. Comments appreciated to ietf@ietf.org by 20 September 2012. Ray Pelletier IETF Administrative Director
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On Sep 8, 2012, at 8:36 PM, Joe Touch to...@isi.edu wrote: On 9/8/2012 11:59 AM, Melinda Shore wrote: On 9/8/12 10:51 AM, Joe Touch wrote: Nothing about an ID is inherently obsolete or out of date after 6 months except its being publicly available on authorized sites (up until now). I think this is absolutely incorrect. Internet Drafts are IETF documents, and expiration changes the relationship between the draft and the IETF. I have to say that I think it's terribly unprofessional not to hang onto archival material Draft != archival Or do you keep copies of all versions of papers you publish, including the ones submitted for review? In case lawyers might need it, or for the benefit of the public? and frankly it's in the interest of the IETF as an *open* standards organization to keep archival material accessible. Agreed. When you're working on a problem that's been around forever and still hasn't been solved (like, oh, I dunno - firewall/NAT traversal?), easy access to expired drafts is an enormous help. The needs of the community - including the lawyers - do not outweigh the rights of the author or the agreement they make with the IETF to date. The original point of having drafts expire seems to have been forgotten here. That's a pity. It did have a reason, and it was useful. The original reason for expiring drafts, along with giving them long, complicated names that includes the word draft, was to keep them from being referenced as if they were standards, based on experience gathered from the short lived IDEA document series. I don't think that having an archive of expired drafts weakens that original goal. -David Borman Would you be more comfortable if there were some sort of visual flag that a draft had expired? If you post it, it's not expired. There's no point in claiming otherwise. Joe -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
I'm happier, Made comments in another thread on why I believe it opens a security hole wider rather than trying to close it. I guess I could leave with it, when this downgrade is only done from a SMTPUTF8 compatible MTA to an ASCII MTA. I mean a SMTPUTF8 MTA MUST reject such downgrade. Let's not try to legitimize an attack vector (Friendly from having nothing to do with the author of the email). On 9/9/12 2:01 PM, Barry Leiba barryle...@computer.org wrote: I will make the change. I'll also remind the EAI group that there have been a couple of objections to the 5322upd-from-group spec, which I have to address. I might do that by scoping it down a bit with some SHOULD NOT use sort of language to address those concerns. Have to review them and see. My suggestion is to say something like the following: ... That could be either in Security Considerations or a separate section. You could even do something radical and incorporate it as a section called Applicability and use the words LIMITED USE (and, since no one seems to remember, a citation of RFC 2026 Section 3.3). I have just posted drft-leiba-5322upd-from-group-04: http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/ That changes the definition of Sender as well as From, and also adds a new Applicability Statement section that has an edited version of John's suggested text. I like the result, and I hope others do as well. I will post something to the 5322upd-from-group thread, asking that those who had objected look at the new text and see if they're happy (or at least somewhat happier) with it. Barry ___ IMA mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ima
Re: IETF...the unconference of SDOs
On 9/10/2012 1:47 AM, Tony Finch wrote:
Michael Richardson {quigon} m...@sandelman.ca wrote:
Let me suggest that at the IETF, where the mailing list is king, you
can't join the Elite if you can't quote email properly. Maybe we should
*state* this.
...
message/rfc822 attachments don't work. If it did it would be a much better
way to do forwarding and top-posting repliesthan at present. (For
instance, Outlook can hide those horrible confusing email addresses rather
than stripping them out.)
Plaintive humor notwithstanding, this all starts to look as if some sort
of BCP or even protocol profile is warranted, to describe preferred
practices in the creation and interpretation of RFC5322 objects within
conversational exchanges.
I'd be happy to participate in a specification effort, assuming
community interest.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Re: IETF...the unconference of SDOs
On Sat, Sep 8, 2012 at 12:49 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Randy Bush ra...@psg.com i say scott should teach emacs :) Epsilon, dude! Who the heck wants to write their editor extensions in freaking LISP? :-) http://xkcd.com/297/ Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Noel
Re: the usual mail stuff, was IETF...the unconference of SDOs
Le 2012-09-10 06:46, Dearlove, Christopher (UK) a écrit : If someone wants to provide guidance on how to do a least bad job with Outlook, that will be gratefully received. Found this using the Google: http://home.in.tum.de/~jain/software/outlook-quotefix/ No idea if it's any good as I don't have access to Outlook... Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: IETF 95 Date Change Proposal - Round 2
lizhong@zte.com.cn wrote: 1-3 April 2016 will be holiday in China. If the time is 3-8 April, then many Chinese attendees have to give up the holiday. Would you propose another time? Thank you. I think there's probably always either a major holiday somewhere or another conference that the IETF wants to avoid conflicting with, so avoiding significant holidays in all parts of the world is not a practical pursuit. The goal of this date change proposal seems to be to avoid holding an IETF when there is a major travel disruption, or days when travel and other public services are shut down, in the place where the IETF meeting is to be held. IETF 95 lists target location: Europe, and holding a meeting in Europe overlapping with Easter would probably cause challenges. However, I do wonder how major a holiday this is? While there are parts of the world where it would not be challenging to hold an IETF meeting over Christmas, international organizations with major US+Europe participation seem to avoid doing so nonetheless. Is this one a special case of similar magnitude? Searching the web suggests that it may be: https://en.wikipedia.org/wiki/Qingming_Festival Since I'm not planning to attend in person, I'll keep my comments general. -- Cos
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/9/12 8:43 PM, John Levine wrote: Let's say I write to the IESG and say this: Due to a late night editing error, draft-foo-bar-42 which I submitted yesterday contains several paragraphs of company confidential information which you can easily see are irrelevant to the draft. My boss wants it taken down pronto, even though he realizes that third parties may have made copies of it in the meantime. I will probably lose my job if it stays up for more than a few days. Thanks for your consideration. Is this the response? You didn't make any legal threats, and now that we know the situation, we wouldn't believe any legal threats you might make in the future, so you better check out those burger flipping opportunities. No, the response is that we refer you to our policy. As an open organization we do not remove information once posted, except under extraordinary circumstances. Exactly. This sort of thing is wh a policy is needed, although I note in passing that the folks at this hypothetical might want to read up on the Streisand Effect. What was wrong with the original version which gave the IESG the latitude to remove an I-D if they feel, for whatever reason, that it would be a good idea to do so? What original? The draft policy states: An I-D will only be removed from the public I-D archive in compliance with a duly authorized court order. If the IESG were so screwed up that they started deleting I-Ds for bad reasons, no amount of process verbiage would help. Certainly, but let's not start from the wrong place to begin with. Let's also set expectations that the IESG may be used to clean up after other peoples' messes. They have enough to do. That is if anything an understatement. And again, this is best developed with counsel. A very emphatic +1 to this. Ned
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Let's say I write to the IESG and say this: Due to a late night editing error, draft-foo-bar-42 which I submitted yesterday contains several paragraphs of company confidential information which you can easily see are irrelevant to the draft. My boss wants it taken down pronto, even though he realizes that third parties may have made copies of it in the meantime. I will probably lose my job if it stays up for more than a few days. Thanks for your consideration. Exactly. This sort of thing is wh a policy is needed, although I note in passing that the folks at this hypothetical might want to read up on the Streisand Effect. Note that I phrased it as a polite request, not a threat. And again, this is best developed with counsel. A very emphatic +1 to this. Sure, but keep in mind that it's one thing to minimize legal risk, is not the same as minimizing cost or complexity, or doing what's best for the IETF and the community. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On Mon, Sep 10, 2012 at 11:26:29AM -0700, ned+i...@mauve.mrochek.com wrote: No, the response is that we refer you to our policy. As an open organization we do not remove information once posted, except under extraordinary circumstances. Exactly. This sort of thing is wh a policy is needed I attempted to hint at it already in this thread, but frankly, this sort of thing is why a policy _is not_ needed. The IESG has that discretion already, and I would prefer to trust their judgement than to write a policy governing all future action, thereby running the risk that we'll have overlooked something and having a resulting problem with policies down the road. I do not understand this nearly constitutional obsession with writing down policies for everything we do and don't do. It turns us into a bureaucratic process slaves for no benefit I can see. Best, A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Let's say I write to the IESG and say this: Due to a late night editing error, draft-foo-bar-42 which I submitted yesterday contains several paragraphs of company confidential information which you can easily see are irrelevant to the draft. My boss wants it taken down pronto, even though he realizes that third parties may have made copies of it in the meantime. I will probably lose my job if it stays up for more than a few days. Thanks for your consideration. Exactly. This sort of thing is wh a policy is needed, although I note in passing that the folks at this hypothetical might want to read up on the Streisand Effect. Note that I phrased it as a polite request, not a threat. I don't see that as especially relevant: There have been plenty of cases where a polite request called attention to something that would otherwise have been ignored, although of course the ones that get reported at http://www.thestreisandeffect.com/ tend to be the ones where bad behavior was involved. And again, this is best developed with counsel. A very emphatic +1 to this. Sure, but keep in mind that it's one thing to minimize legal risk, is not the same as minimizing cost or complexity, or doing what's best for the IETF and the community. The narrow goal of minimizing the immediate legal risk is hardly the only, or even an especially good, reason to seek advice of counsel. Counsel is there to assist you in understanding the legal implications of your possible choices and then in implementing the choice you make. They are not there to make your decisions for you. Ned
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/10/2012 8:24 AM, David Borman wrote: ... The original reason for expiring drafts, along with giving them long, complicated names that includes the word draft, was to keep them from being referenced as if they were standards, based on experience gathered from the short lived IDEA document series. It was also to encourage authors to post half-baked* ideas without having them persist - either as standards, or in general as something the author needed to continue to defend. I don't think that having an archive of expired drafts weakens that original goal. It weakens both goals. A key complaint has been that the doc disappears from an IETF site. Neither the length nor the name has been an impediment Joe
Re: [ietf-privacy] draft-moonesamy-privacy-identifiers-00
Absolutely Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wil...@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 10 Sep 2012, at 11:58, Bryan McLaughlin (brmclaug) wrote: HI Robin, I agree it is ’blurry’ My point was that we, the IETF, cannot determine the requirement for consent and the nature of an identifier to be personal data. The answer will always vary on context and may vary on jurisdiction. My reason for using the IP address is it’s a great example of this very point. Cheers Bryan smime.p7s Description: S/MIME cryptographic signature ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Last Call: draft-ietf-dime-erp-12.txt (Diameter Support for the EAP Re-authentication Protocol (ERP)) to Proposed Standard
The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Support for the EAP Re-authentication Protocol (ERP)' draft-ietf-dime-erp-12.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-09-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-erp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-erp/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'Definition of Managed Objects for the Neighborhood Discovery Protocol' to Proposed Standard (draft-ietf-manet-nhdp-mib-19.txt)
The IESG has approved the following document: - 'Definition of Managed Objects for the Neighborhood Discovery Protocol' (draft-ietf-manet-nhdp-mib-19.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ Technical Summary This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. Working Group Summary The process for reaching working group consensus on this was smooth; no controversy existed. Working Group consensus behind the document is solid. Document Quality This document shepherd is not aware of existing implementations of this MIB although seveal implementers have indicated interest in the work. The responsible AD performed a detailed MIB review at publication request. A MIB Doctor review was requested in parallel to IETF last call, but was not forthcoming. The GenArt review by Joel Halpern was addressed in a new revision after IETF last call. The MIB Doctor review during IESG evaluationproduced a significant number of issues that were fixed in late revisions. Personnel Stan Ratliff (sratl...@cisco.com) is the Document Shepherd. Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD
RFC 6712 on Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
A new Request for Comments is now available in online RFC libraries. RFC 6712 Title: Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) Author: T. Kause, M. Peylo Status: Standards Track Stream: IETF Date: September 2012 Mailbox:t...@ssh.com, martin.pe...@nsn.com Pages: 10 Characters: 21308 Updates:RFC4210 I-D Tag:draft-ietf-pkix-cmp-transport-protocols-20.txt URL:http://www.rfc-editor.org/rfc/rfc6712.txt This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It is the CMPtrans document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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/rfcsearch.html. 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
RFC 6716 on Definition of the Opus Audio Codec
A new Request for Comments is now available in online RFC libraries. RFC 6716 Title: Definition of the Opus Audio Codec Author: JM. Valin, K. Vos, T. Terriberry Status: Standards Track Stream: IETF Date: September 2012 Mailbox:jmva...@jmvalin.ca, koenvo...@gmail.com, tterribe...@mozilla.com Pages: 326 Characters: 977743 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-codec-opus-16.txt URL:http://www.rfc-editor.org/rfc/rfc6716.txt This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK] This document is a product of the Internet Wideband Audio Codec Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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/rfcsearch.html. 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
RFC 6719 on The Minimum Rank with Hysteresis Objective Function
A new Request for Comments is now available in online RFC libraries. RFC 6719 Title: The Minimum Rank with Hysteresis Objective Function Author: O. Gnawali, P. Levis Status: Standards Track Stream: IETF Date: September 2012 Mailbox:gnaw...@cs.uh.edu, p...@cs.stanford.edu Pages: 13 Characters: 29637 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-roll-minrank-hysteresis-of-11.txt URL:http://www.rfc-editor.org/rfc/rfc6719.txt The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK] This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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/rfcsearch.html. 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
RFC 6724 on Default Address Selection for Internet Protocol Version 6 (IPv6)
A new Request for Comments is now available in online RFC libraries. RFC 6724 Title: Default Address Selection for Internet Protocol Version 6 (IPv6) Author: D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown Status: Standards Track Stream: IETF Date: September 2012 Mailbox:dtha...@microsoft.com, ric...@microsoft.com, arif...@nttv6.net, t...@ecs.soton.ac.uk Pages: 32 Characters: 74407 Obsoletes: RFC3484 I-D Tag:draft-ietf-6man-rfc3484bis-06.txt URL:http://www.rfc-editor.org/rfc/rfc6724.txt This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK] This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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/rfcsearch.html. 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
