Re: Updating RFC2119
On 22/07/2012 17:26, Melinda Shore wrote: On 7/22/12 3:17 AM, Abdussalam Baryun wrote: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, Yes: you might try to explain what problem you think you're solving. Melinda Preferable with a list of RFC text snippets that would have been more readable if these keywords had been used. Stewart
Re: Proposed IETF 95 Date Change
On Jul 20, 2012, at 18:36 , Joel jaeggli wrote: On 7/20/12 09:06 , IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. 20 march is palm sunday on the western calender. If one's a conflict presumably the other is too... True, but if I can choose I would say 20-25 is better... L. Ray Pelletier IETF Administrative Director
Re: [OAUTH-WG] oauth-bearer and rfc 2617/httpbis authentication framework
On 2012-07-23 00:33, Stephen Farrell wrote: Hi all, I'd like to check that some recent minor changes to this document [1] don't cause technical or process-grief. The version [2] of the oauth bearer draft that underwent IETF LC and IESG evaluation had a normative dependency on the httpbis wg's authentication framework. [3] After resolving IESG discuss positions the authors and wg chairs felt that it would be better to replace the normative reference to the httpbis wg draft [3] with one to RFC 2617 [4] so that the OAuth drafts wouldn't be held in the RFC editor queue waiting on the httpbis wg to get done. I believe there is no impact on interop resulting from this change but there has been some disagreement about making it and how it was made. After some offlist discussion I think we now have an RFC editor note [5] that means that the current scheme of referring to RFC 2617 is ok. ... Quoting: NEW: The Authorization header for this scheme follows the usage of the Basic scheme [RFC2617]. Note that, as with Basic, this is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], though does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: That helps, but it still hides the fact that the syntax is not compatible with the RFC 2617 framework. Also, s/header/header field/ Proposal: The syntax of the Authorization header field for this scheme follows the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note that, as with Basic, it does not conform to the generic syntax defined in Section 1.2 of [RFC2617], but that it is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], although it does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: ... Best regards, Julian
Re: Proposed IETF 95 Date Change
On 20/07/2012 18:06, IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director If March 27 is Easter, then I'm not sure if the change solves the problem. Sunday March 20 is Palm Sunday, the Thursday and Friday before Easter (as well as the Monday after) are religious holidays in many European countries. If you want to avoid a clash with Easter and related days, then one will have to move the meeting to either the week of 13-18 March, or the week of 3-8 April. Henk -- -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- Read my blog at http://www.uijterwaal.nl/henks_hands.html
Re: Proposed IETF 95 Date Change
On Mon, 2012-07-23 at 10:08 +0200, Henk Uijterwaal wrote: On 20/07/2012 18:06, IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director If March 27 is Easter, then I'm not sure if the change solves the problem. Sunday March 20 is Palm Sunday, the Thursday and Friday before Easter (as well as the Monday after) are religious holidays in many European countries. If you want to avoid a clash with Easter and related days, then one will have to move the meeting to either the week of 13-18 March, or the week of 3-8 April. I agree, and prefer the former. Henk
Re: Updating RFC2119
Hi Stewart, Usually the (IF x, THEN y) means if x happens then y is a MUST, so I don't see the important reflection of a MUST in many documentation when using *if*. That is why I prefer to find requirements more easily while skimming any IETF document, the MUST, SHOULD, and IF, these are important requirement words in specifications. Please see below as examples per your requested. -- RFC4861page36 IMO suggest to use IF, THEN If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. -- RFC4861page 49 IMO suggest to use IF and ELSE IF If the router already has a Neighbor Cache entry for the solicitation’s sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, then the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation’s sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a multicast or a unicast router advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation’s sender exists (or is created) the entry’s IsRouter flag MUST be set to FALSE. -- RFC5715page 19 If R changes before T, then a loop will form around R, T, and S. --- RFC6052 page 10 suggest delete *will* and to add as IF, THEN If a packet bound to 192.0.2.33 reaches the translator, the destination address will be translated to 2001:db8:122:344:c0:2:2100::, and the packet will be routed towards R and then to A. --- There are many examples that ignore the use of IF , THEN requirements, which I suggest to be in the I-D update of RFC2119 that I working on and will submit in 30 July, Regards Abdussalam Baryun University of Glamorgan, UK == Preferable with a list of RFC text snippets that would have been more readable if these keywords had been used. Stewart On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi All, I am working on an I-D which is intended as proposed standard but need some addition requirement language. Therefore, I want to propose to write a draft to update RFC2119 to add some other language requirement as below: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, That doesn't have to be in 2119. Lots of RFCs have pseudocode at various levels of rigor. Just look around at some protocol specs for examples.
Re: [OAUTH-WG] oauth-bearer and rfc 2617/httpbis authentication framework
Hiya, On 07/23/2012 08:56 AM, Julian Reschke wrote: On 2012-07-23 00:33, Stephen Farrell wrote: Hi all, I'd like to check that some recent minor changes to this document [1] don't cause technical or process-grief. The version [2] of the oauth bearer draft that underwent IETF LC and IESG evaluation had a normative dependency on the httpbis wg's authentication framework. [3] After resolving IESG discuss positions the authors and wg chairs felt that it would be better to replace the normative reference to the httpbis wg draft [3] with one to RFC 2617 [4] so that the OAuth drafts wouldn't be held in the RFC editor queue waiting on the httpbis wg to get done. I believe there is no impact on interop resulting from this change but there has been some disagreement about making it and how it was made. After some offlist discussion I think we now have an RFC editor note [5] that means that the current scheme of referring to RFC 2617 is ok. ... Quoting: NEW: The Authorization header for this scheme follows the usage of the Basic scheme [RFC2617]. Note that, as with Basic, this is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], though does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: That helps, but it still hides the fact that the syntax is not compatible with the RFC 2617 framework. hides isn't a goal:-) Also, s/header/header field/ Proposal: The syntax of the Authorization header field for this scheme follows the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note that, as with Basic, it does not conform to the generic syntax defined in Section 1.2 of [RFC2617], but that it is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], although it does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: ... That looks better. I've updated the RFC editor note to use your text. Thanks, S. Best regards, Julian
Re: Updating RFC2119
comments in line I'd encourage you to not try change 2119. thanks for your comment Instead, add whatever new definitions you feel you need to your own draft that addresses some technical, and not process, topic. I agree that I will need to add to the technical draft for now. If people find your new definitions useful they'll say and if enough of that happens they'll be included in a 2119bis whenever that's done. this is the reason for this thread to see the feedback of the community including me (at this time and the comings) and IMO the submission of the I-D to update RFC2119 that includes new definition may help the discussion, in the end the community will decide AB === On 07/23/2012 12:08 PM, Abdussalam Baryun wrote: Hi Stewart, Usually the (IF x, THEN y) means if x happens then y is a MUST, so I don't see the important reflection of a MUST in many documentation when using *if*. That is why I prefer to find requirements more easily while skimming any IETF document, the MUST, SHOULD, and IF, these are important requirement words in specifications. Please see below as examples per your requested. -- RFC4861page36 IMO suggest to use IF, THEN If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. -- RFC4861page 49 IMO suggest to use IF and ELSE IF If the router already has a Neighbor Cache entry for the solicitation’s sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, then the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation’s sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a multicast or a unicast router advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation’s sender exists (or is created) the entry’s IsRouter flag MUST be set to FALSE. -- RFC5715page 19 If R changes before T, then a loop will form around R, T, and S. --- RFC6052 page 10 suggest delete *will* and to add as IF, THEN If a packet bound to 192.0.2.33 reaches the translator, the destination address will be translated to 2001:db8:122:344:c0:2:2100::, and the packet will be routed towards R and then to A. --- There are many examples that ignore the use of IF , THEN requirements, which I suggest to be in the I-D update of RFC2119 that I working on and will submit in 30 July, Regards Abdussalam Baryun University of Glamorgan, UK == Preferable with a list of RFC text snippets that would have been more readable if these keywords had been used. Stewart On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi All, I am working on an I-D which is intended as proposed standard but need some addition requirement language. Therefore, I want to propose to write a draft to update RFC2119 to add some other language requirement as below: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, That doesn't have to be in 2119. Lots of RFCs have pseudocode at various levels of rigor. Just look around at some protocol specs for examples.
Re: Proposed IETF 95 Date Change
On Jul 23, 2012, at 14:28, DRAGE, Keith (Keith) wrote: you need to take into account at least both the Friday and Monday in some countries. +1 In much of Europe, the Easter holidays run from Good Friday to Easter Monday, and exhibit -- strong travel activity -- zero to reduced opening times of various essential facilities -- reduced public transport schedules (*) When meeting in Europe, avoid both weeks around Easter. (Clearly, we need to have IETF95 in Bali. :-) Grüße, Carsten (*) A bit counterintuitive -- the reason is that public transport agencies tend to cater to their employees as opposed to their customers, and these employees want to enjoy the holidays, too. Since everybody knows that public transport is overcrowded on these long weekends, there isn't even any backlash.
Re: Proposed IETF 95 Date Change
On Jul 23, 2012, at 4:08 AM, Henk Uijterwaal wrote: On 20/07/2012 18:06, IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director If March 27 is Easter, then I'm not sure if the change solves the problem. Sunday March 20 is Palm Sunday, the Thursday and Friday before Easter (as well as the Monday after) are religious holidays in many European countries. If you want to avoid a clash with Easter and related days, then one will have to move the meeting to either the week of 13-18 March, 13 - 18 March 2016 are the dates for the IEEE-802 Plenary. Ray or the week of 3-8 April. Henk -- -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- Read my blog at http://www.uijterwaal.nl/henks_hands.html
RE: Feedback Requested on Draft Fees Policy
+1 Excellent idea in principle ..IMHO just a matter of working out details. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Bradner, Scott Sent: Friday, July 20, 2012 10:17 AM To: Scott Brim Cc: wgcha...@ietf.org; ietf@ietf.org; i...@ietf.org; i...@iab.org; IETF Announcement List Subject: Re: Feedback Requested on Draft Fees Policy great idea - just does not jive with the legal system which often need authenticated copies of documents Scott On Jul 20, 2012, at 10:14 AM, Scott Brim wrote: On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote: The draft policy entitled Draft Fee Policy for Legal Requests can be found at: http://iaoc.ietf.org/policyandprocedures.html Fine idea.
Re: Updating RFC2119
On 7/23/2012 4:26 AM, Stephen Farrell wrote: I'd encourage you to not try change 2119. Instead, add whatever new definitions you feel you need to your own draft that addresses some technical, and not process, topic. If people find your new definitions useful they'll say and if enough of that happens they'll be included in a 2119bis whenever that's done. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
RE: Feedback Requested on Draft Fees Policy
As a working assumption let's say at least 750 USD or Euros per hour to calculate cost recovery. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Friday, July 20, 2012 10:40 AM To: IETF Administrative Director Cc: ietf@ietf.org Subject: Re: Feedback Requested on Draft Fees Policy --On Friday, July 20, 2012 06:07 -0700 IETF Administrative Director i...@ietf.org wrote: The IAOC is seeking community feedback on a proposed policy by the IAOC to impose fees to produce information and authenticate documents in response to subpoenas and other legal requests. ... Before adopting a policy the IAOC would like feedback on this before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Seems entirely reasonable. Knowing how much effort some of these requests can produce, I do wonder if the fees are a bit too low but trust that the IAOC has determined that they will at least cover costs. john
Re: [IAOC] Feedback Requested on Draft Fees Policy
I did it once - it took 2 or 3 hours *it was quite a while back and I do not remember) there were no significant expenses - the depo was in Boston my only expense was a few hours parking - the depo was done in the office of the law firm that was providing the IETF with pro-bono legal services at the time Scott On Jul 22, 2012, at 3:58 PM, John R Levine wrote: For people with unique skills or knowledge, $800/hr is not unusual. So long as the rate is published ahead of time, you're not going to get much argument. (Yes, we know it's high. But we've already told you how to download stuff yourself for free.) Please note : out of pocket expenses (if someone has to travel to a hearing, say) would be reimbursed, but IETF volunteers will not be paid from these fees. If you know, how often have people been deposed on behalf of the IETF, and how long does it typically take? My thought is that in a depo or trial, the other side pays both for the expenses and the time of the person being deposed, so it would be good idea to say up front here's what it'll cost if you want a live witness. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly.
Re: [IAOC] Feedback Requested on Draft Fees Policy
I did not do them any favor - I did the IETF a favor (as the then ISOC VP for Standards) Scott On Jul 22, 2012, at 4:43 PM, John R Levine wrote: I did it once - it took 2 or 3 hours *it was quite a while back and I do not remember) there were no significant expenses - the depo was in Boston my only expense was a few hours parking - the depo was done in the office of the law firm that was providing the IETF with pro-bono legal services at the time If the opposing party didn't pay you for your time in the depo, you did them an unnecessary favor. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly.
RE: Proposed IETF 95 Date Change
Let's forget the religious discussion that seems to have broken out as a result of this. While Easter may be a major Christian festival, I don't believe the issue is such (I can think of no reasons why Christians would have a doctrinal reason other than those that apply to any other Sunday and those obligations could mostly be met at the venue rather than at home). Rather it is Easter the secular public holiday that happens to occur in many countries. This is the set of days when schools take an extended break, parents take said children off on short holidays; cheap air tickets cease to be available; when you get on the plane, it is full of screaming children; local transport all works to a reduced timetable; for those IETFers who end up wishing to travel by train, they find themselves moving to busses to cater for the engineering works which a 4 day weekend seems to encourage. So my advice would be, change the dates if it looks like you are going to hold the meeting in a country that takes such holidays, or where a significant number of people would need to transit through such a country. If so you need to take into account at least both the Friday and Monday in some countries. Keith P.S. Trying to avoid every religious and public holiday is an impossible task. Do what other organizations have done and concentrate on the impact of such holidays on holding the meeting in any location. -Original Message- From: wgchairs-boun...@ietf.org [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF Administrative Director Sent: 20 July 2012 17:06 To: IETF Announcement List Cc: i...@ietf.org; i...@iab.org; ietf@ietf.org; wgcha...@ietf.org Subject: Proposed IETF 95 Date Change The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director
RE: Proposed IETF 95 Date Change
At 07:28 AM 7/23/2012, DRAGE, Keith (Keith) wrote: Let's forget the religious discussion that seems to have broken out as a result of this. While Easter may be a major Christian festival, I don't believe the issue is such (I can think of no reasons why Christians would have a doctrinal reason other than those that apply to any other Sunday and those obligations could mostly be met at the venue rather than at home). Rather it is Easter the secular public holiday that happens to occur in many countries. This is the set of days when schools take an extended break, parents take said children off on short holidays; cheap air tickets cease to be available; when you get on the plane, it is full of screaming children; kinda like we're all going to experience at next year's IETF86 timed exactly in the middle of US spring break going to/from Orlando (home to 4(?) amusement parks including Disneyworld)? Air travel will be crazy (families book tickets many months - like 6 - in advance), and depending on which hotel we're in, it could be worse than staying at the airport each day. -j local transport all works to a reduced timetable; for those IETFers who end up wishing to travel by train, they find themselves moving to busses to cater for the engineering works which a 4 day weekend seems to encourage. So my advice would be, change the dates if it looks like you are going to hold the meeting in a country that takes such holidays, or where a significant number of people would need to transit through such a country. If so you need to take into account at least both the Friday and Monday in some countries. Keith P.S. Trying to avoid every religious and public holiday is an impossible task. Do what other organizations have done and concentrate on the impact of such holidays on holding the meeting in any location. -Original Message- From: wgchairs-boun...@ietf.org [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF Administrative Director Sent: 20 July 2012 17:06 To: IETF Announcement List Cc: i...@ietf.org; i...@iab.org; ietf@ietf.org; wgcha...@ietf.org Subject: Proposed IETF 95 Date Change The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director
Re: Feedback Requested on Draft Fees Policy
No objection. Thank you for asking. Just as with any project that you don't really want to take on, make sure the price is high enough that you're willing to do it should someone be foolish enough to pay the asking price. Also consider adding an automatic fee escalation clause (e.g. permit the IAD to raise the fee by up to 5% per year without further IAOC action). -- Sam
Re: Proposed IETF 95 Date Change
On Fri, 20 Jul 2012, Behcet Sarikaya wrote: I don't understand why this issue is coming up. Maybe you don't know, IETF 84 falls in the month of Ramadan for Muslims and nobody asked to change it? I think focusing on the religious roots of the holiday is misguided. The question is what effect the holiday is likely to have on meeting attendance. I think the IETF also tries to avoid secular holidays that would interfere with the attendance of a large number of typical IETF attendees. Here's an example: we avoid the (secular) Thanksgiving holiday in the US -- it falls on a Thursday in late November, and it's common for people to take both the Thursday and Friday as holiday. Thanksgiving is such a big deal in the US, and we get so many US attendees, that the IETF would avoid that holiday no matter where the meeting was being held. Similarly, I think we would take into account local and regional holidays at our meeting sites, both religious and secular. We would probably avoid having a meeting in Amsterdam's center (or, really, anywhere in the Netherlands) on Queen's Day. Would overlapping with Easter draw down attendance enough to warrant avoiding it? Probably. It's a big enough risk that shifting a week seems sane. While Ramadan is religiously very significant, I think it is observed by relatively few of our regular meeting attendees and even those that do observe it may be willing to travel during it. Hence the difference in how they're being handled. -- Sam
Re: Proposed IETF 95 Date Change
John Levine wrote: [ Charset UTF-8 unsupported, converting... ] You're not going to find cool temperatures again in July or August unless you go as far south as Argentina or New Zealand. Not only is there life north of the 60th parallel (N), there are even hotels and restaurants and airports. Anchorage is probably large enough for an IETF meeting, although trying to hold a meeting there during tourist season would almost certainly be a mistake. But still. I believe it, but remember that the issue was to minimize daylight fasting during the North American summer. Reykjavik is big enough, too, and has the advantage of being roughly equally inconvenient to get to from North America and Europe. We could have the social event at the Blue Lagoon. The issue with Reykjavik is more about is closeness to the Arctic circle. You don't seem to have a lot of sunsetnight there during the summer. Take into account that ramadan is related to the lunar calender and is 11 days earlier every year to the next (on the gregorian calendar) then a hypothetical IETF meeting in Reykjavik, 22th June - 26th June 2015 could turn out challenging for some folks. The currently scheduled date for IETF 93 is 19-24 July, 2015, so I assume it will be after Ramadan. -Martin
Last Call: draft-ietf-abfab-usecases-03.txt (Application Bridging for Federated Access Beyond web (ABFAB) Use Cases) to Informational RFC
The IESG has received a request from the Application Bridging for Federated Access Beyond web WG (abfab) to consider the following document: - 'Application Bridging for Federated Access Beyond web (ABFAB) Use Cases' draft-ietf-abfab-usecases-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-08-06. 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 Federated identity is typically associated with Web-based services at present, but there is growing interest in its application in non Web- based contexts. The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ballot/ Some references need updating: RFC 2060 - RFC 3501 and RFC 2821 -RFC 5321. No IPR declarations have been submitted directly on this I-D.
IAB IPv6 privacy survey posted, response requested
The IAB is working on http://tools.ietf.org/html/draft-iab-privacy-considerations 'Privacy Considerations for Internet Protocols'. In order to better understand the implementation status of IPv6 privacy mechanisms in operating system stacks, those familiar with OS IPv6 implementations are asked to complete a short survey http://www.iab.org/wp-content/IAB-uploads/2012/07/IPv6-Privacy-Survey.doc . The survey responses will be used in a detailed write-up on IPv6 privacy; privacy reviews of other IETF protocols are available here. http://www.iab.org/activities/programs/privacy-program/privacy-reviews/ Please send responses to iab-ipv6-privacy-sur...@i1b.org by August 13, 2012. If you have questions, please send them to iab-ipv6-privacy-sur...@i1b.org.
Protocol Action: 'The Atom deleted-entry Element' to Proposed Standard (draft-snell-atompub-tombstones-18.txt)
The IESG has approved the following document: - 'The Atom deleted-entry Element' (draft-snell-atompub-tombstones-18.txt) as Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/ Technical Summary This specification adds mechanisms to the Atom Syndication Format which publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. Working Group Summary This document is not the product of a working group, but has been reviewed and discussed on the list of the former atompub WG. Document Quality The document has received adequate review by Atom implementers and on the ietf-ty...@ietf.org list. There is agreement among the Atom implementation community that this feature is needed and that this document defines the right approach. In addition, there are existing implementations. Personnel The Document Shepherd and Responsible Area Director is Barry Leiba.
Document Action: 'An IETF URN Sub-Namespace for OAuth' to Informational RFC (draft-ietf-oauth-urn-sub-ns-06.txt)
The IESG has approved the following document: - 'An IETF URN Sub-Namespace for OAuth' (draft-ietf-oauth-urn-sub-ns-06.txt) as Informational RFC This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/ Technical Summary This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. Working Group Summary There was no significant controversy in the working group, to my knowledge. I suppose there really wasn't an argument about how to spell oauth. Document Quality The document is as long and short as it needs to be to register a URN entry with IANA. Personnel Document Shepherd: Derek Atkins Responsible AD: Stephen Farrell IANA Note OLD: - Establishment of a new registry for URNs subordinate to urn:ietf:params:oauth. Instructions for a registrant to request the registration of such a URN are in Section 3. NEW: - Establishment of a new registry called the oAuth URI registry for URNs subordinate to urn:ietf:params:oauth. The registry oAuth URI will be added to a new top-level registry called OAuth Parameters as defined by draft-ietf-oauth-v2. Instructions for a registrant to request the registration of such a URN are in Section 3.
Protocol Action: 'Indicating Email Handling States in Trace Fields' to Proposed Standard (draft-ietf-appsawg-received-state-04.txt)
The IESG has approved the following document: - 'Indicating Email Handling States in Trace Fields' (draft-ietf-appsawg-received-state-04.txt) as Proposed Standard This document is the product of the Applications Area Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state/ Technical Summary This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. This allows inspection of the trace information to reveal that the cause for a time gap in trace fields was an imposed delay rather than one caused by transient technical difficulties. Working Group Summary The WG discussed appropriate IANA procedure for the new registry created by the document. The WG was deciding between Expert Review and FCFS. Consensus was a rough on this one. Otherwise the document is really non controversial. Document Quality There is at least one existing implementation of this specification. At least two more are planned. No special purpose reviews are needed for this document. Personnel Alexey Melnikov is the document shepherd. Barry Leiba is the responsible AD.
Document Action: 'Publishing the Tao of the IETF as a Web Page' to Informational RFC (draft-hoffman-tao-as-web-page-04.txt)
The IESG has approved the following document: - 'Publishing the Tao of the IETF as a Web Page' (draft-hoffman-tao-as-web-page-04.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/ Technical Summary This document proposes a change to the process of publishing the Tao of the IETF, making the Tao a page on the IETF web site instead of as an RFC. Working Group Summary This document is not the product of any IETF WG. Document Quality The document describes a process that is yet to be implemented; however, the publication of the Tao as a page on the IETF web site has been discussed on the IETF mail list. Personnel Paul Hoffman is the document editor and document shepherd. Russ Housley is the responsible AD.
Protocol Action: 'Default Address Selection for Internet Protocol version 6 (IPv6)' to Proposed Standard (draft-ietf-6man-rfc3484bis-06.txt)
The IESG has approved the following document: - 'Default Address Selection for Internet Protocol version 6 (IPv6)' (draft-ietf-6man-rfc3484bis-06.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484bis/ Technical Summary 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. Working Group Summary The working group has been working on this replacement to RFC3484 for several years. There has been a very active discussion and there is a strong consensus to move it forward. Document Quality This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Personnel Bob Hinden is the Document Shepherd. Brian Haberman is the Responsible Area Director.
Protocol Action: 'DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates' to Proposed Standard (draft-ietf-dnsext-dnssec-registry-update-03.txt)
The IESG has approved the following document: - 'DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates' (draft-ietf-dnsext-dnssec-registry-update-03.txt) as Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ Technical Summary The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry. Working Group Summary The changes this draft makes were originally bound up with some changes from a previous WG draft that was not published. Some of the WG and, particularly, the IESG objected to the way that draft altered the registry; this draft and another one were the results. This draft is not bound up with the other draft, and makes the uncontroversial changes to the registry. Document Quality This draft makes no changes to any protocol, but cleans up a number of errors and omissions in the relevant registry. Personnel Andrew Sullivan is the Document Shepherd. Ralph Droms is the Responsible Area Director.
