FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Hi Alexa, Please be aware of this document that has just entered a four-week IETF last call. The document describes a proposed IETF process experiment under the rules of RFC 3933. The proposed experiment calls on the IETF Secretariat to take specific actions under certain circumstances in corner cases of the experiment. Could you please have someone in the Secretariat look at the draft and comment on the practicalities of the actions. Note that, at this stage, no changes to the tools are proposed so any actions would require manual intervention (if the experiment were successful and resulted in permanent changes to IETF process we might make changes to the tools at some future time). Thanks, Adrian -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 11 January 2013 15:15 To: IETF-Announce Subject: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as Experimental 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 ietf@ietf.org mailing lists by 2013-02-08. 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 This memo describes an optional, fast-track way to progress a working group document to IESG review. It is provided as a process experiment as defined in RFC 3933 for use when working group chairs believe that there is running code that implements a working group Internet-Draft. The motivation is to have the IETF process explicitly consider running code, consistent with the IETF's overall philosophy of running code and rough consensus. In this process all of working group last call, IETF last call, and Area Director review are carried out in the same two week period. Only comments that meet IESG Discuss criteria need to be addressed during this stage, and authors are required to make any changes within two weeks. This experiment will run for one year. The file can be obtained via http://datatracker.ietf.org/doc/draft-farrell-ft/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-farrell-ft/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
At 07:14 11-01-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as Experimental 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 ietf@ietf.org mailing lists by 2013-02-08. Exceptionally, comments may be In Section 1: Additionally, the experiment will only require issues raised during these three stages to be addressed if they meet the IESG's Discuss criteria. Does this mean that a document does not have to represent consensus? In contrast, a -bis RFC that aims for Proposed Standard or Experimental is likely to be a fine candidate. I read what the document proposes as lowering the barrier of entry for first publication. My preference is to say nothing about -bis RFCs (see quoted text). Some of the -bis drafts I have come across (note that this is not related to a draft being discussed currently) are not well-written even though there is running code. The running code might be due to author intervention instead of a blind test of the specification. In Section 2: Implementations developed during the production of an Internet-draft can indicate that a working group has had the opportunity to get early confirmation of its engineering choices. Agreed. In Section 3: Any Working Group Last Call (WGLC) or Area Director (AD) review (which are routinely done, though not part of the formal [BCP9] process) will run in parallel with the two-week IETF Last Call (IETF-LC) period. I am not suggesting changing the two weeks. It can cause logistical problems. I'll take the risk of trying this experiment. Only comments that would be DISCUSS-worthy according to the IESG Discuss Criteria [DCRIT] need be handled during last call. Other comments can be handled or not, at the authors/editors discretion. See my previous comment about this criteria. In Section 4: The fast-track process can be used for bis RFCs and might well be quite suitable for those. I suggest removing this. If the timers (IETF LC or the two-weeks after IETF LC for fixing things) co-incide with a major holiday period or IETF meeting then the responsible AD can add a week or two as appropriate. I suggest not using the Fast-Track if it is less than two weeks before or after an IETF meeting. Some people only do IETF work during that period and that results in a spike. I don't think that it is a good idea for this experiment to encourage work during the meeting phase instead of the mailing list. In Section 5: An AD who wishes to do her review in parallel with Last Call is always free to make that choice. his or a gender neutral term. This memo itself has no impact on appeal processes. However, in considering an appeal that relates to a document that has been fast-track processed, the relevant judge (WG chair, AD, IESG or IAB as appropriate) should consider the requirements posited here. The WG Chair is not a judge in such cases as it would be his/her decision being appealed. Some people are discouraged from bringing work into the IETF because of the long debates (which I likely contributed to). Big companies have an incentive to do work within the IETF. There is a perception in open source circles than there isn't much to gain in having a specification published as a RFC. The young, free and wild will not listen to the fogies. The better approach, in my opinion, is not to act as a gatekeeper or encourage a wall-garden attitude. Regards, -sm
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Hiya, On 01/11/2013 07:33 PM, SM wrote: At 07:14 11-01-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as Experimental 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 ietf@ietf.org mailing lists by 2013-02-08. Exceptionally, comments may be In Section 1: Additionally, the experiment will only require issues raised during these three stages to be addressed if they meet the IESG's Discuss criteria. Does this mean that a document does not have to represent consensus? You mean rough consensus of the IETF I guess? Good question. First, WG rough consensus is formally unaffected. As is IESG review. And if IETF LC comments are received that do meet the IESG discuss criteria then those should be handled as now. So I guess we're left with cases where there's a lack of rough consensus during IETF LC but where the meat of the disagreement is something that doesn't qualify for an IESG discuss ballot. I'd say that'd be quite likely to allow the responsible AD to say that there had been so much debate during IETF LC that this experiment ought not be used. So, I don't think this experiment has any major effect there really but maybe has a subtle one. I'll be interested in seeing if this happens if we do the experiment. In contrast, a -bis RFC that aims for Proposed Standard or Experimental is likely to be a fine candidate. I read what the document proposes as lowering the barrier of entry for first publication. My preference is to say nothing about -bis RFCs (see quoted text). Some of the -bis drafts I have come across (note that this is not related to a draft being discussed currently) are not well-written even though there is running code. The running code might be due to author intervention instead of a blind test of the specification. I don't get what you mean. Can you explain? (I get that you don't want to mention -bis cases, but I don't get why.) In Section 2: Implementations developed during the production of an Internet-draft can indicate that a working group has had the opportunity to get early confirmation of its engineering choices. Agreed. In Section 3: Any Working Group Last Call (WGLC) or Area Director (AD) review (which are routinely done, though not part of the formal [BCP9] process) will run in parallel with the two-week IETF Last Call (IETF-LC) period. I am not suggesting changing the two weeks. It can cause logistical problems. I'll take the risk of trying this experiment. Only comments that would be DISCUSS-worthy according to the IESG Discuss Criteria [DCRIT] need be handled during last call. Other comments can be handled or not, at the authors/editors discretion. See my previous comment about this criteria. In Section 4: The fast-track process can be used for bis RFCs and might well be quite suitable for those. I suggest removing this. If the timers (IETF LC or the two-weeks after IETF LC for fixing things) co-incide with a major holiday period or IETF meeting then the responsible AD can add a week or two as appropriate. I suggest not using the Fast-Track if it is less than two weeks before or after an IETF meeting. Some people only do IETF work during that period and that results in a spike. I don't think that it is a good idea for this experiment to encourage work during the meeting phase instead of the mailing list. Not a bad idea. Something like fast-track must be started at least one month (longer?) before an IETF meeting starts ? I guess the only problem I'd have with that is that for an experiment that'd run for one year, that takes out about 4 months (3 meetings and the year-end holidays) which is a lot. If we extended the experiment to 18 months duration I'd have no problem with something like that though. Or with leaving it as-is. Let's see if we get any other opinions. In Section 5: An AD who wishes to do her review in parallel with Last Call is always free to make that choice. his or a gender neutral term. I'll leave that to the rfc editor. He'll fix it:-) This memo itself has no impact on appeal processes. However, in considering an appeal that relates to a document that has been fast-track processed, the relevant judge (WG chair, AD, IESG or IAB as appropriate) should consider the requirements posited here. The WG Chair is not a judge in such cases as it would be his/her decision being appealed. Can be. If a WG participant says the decision you made on that draft is broken: I appeal then they first send that to the WG chair. Some people are discouraged from bringing work into the IETF because of the long debates (which I likely contributed to). Big
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Hi, Sorry for replying to this advise to secretariat thread and not to the ietf-announce thread--I'm not subscribed to ietf-announce. I have three comments, and regret that I have not followed all of the discussions regarding this draft before, so please advise if those comments have already been raised and/or resolved. First, I'm glad that the direct preferences of open source implementations over implementations compliant with other business models are mostly gone. Still, there is one reference that worries me, and that is the reference to GPLv3 code as an extreme in section 2.1. Yes, the GPL (and similar copyleft licenses) is an extreme, at least in terms of open source licensing models. However, it is not an extreme of openness or accessibility of the source code for review by WG chair, AD, and community. I would hope that we are all aware that many (most?) commercial software developers, by company policy or common sense, avoid looking at GPL-ed code, out of fear of contamination of their own closed source code. GPL-ed code is, therefore, inaccessible for verification by a large part of the IETF community, and does not serve as a good example for openness, which is how I interpret the spectrum laid out in section 2.1. A better example would be source code that is almost universally accessible. The extreme here would be source code in the public domain. Somewhat less convincing but perhaps a bit more realistically, source code under a BSD-style license like the one the IETF Trust is using. Second, the draft suggest that the existence of an implementation of the specification should serve as a shortcut towards RFC, presumably because such an implementation speak favorably to the implementability of the specification. That, however, is not universally true. Specifically, if implementer and spec writer are the same person (or part of the same team), it is quite likely that the spec takes certain assumptions made by the implementers for granted, and does not document it. That would be a bad spec, accessible implementation or not. The solution to this issue is IMO not, as the draft appears to be to suggest, to put burden on WG chairs and ADs to ensure that the spec and the implementation match. Both WG chairs and ADs have enough to do, and the incentive for rubber-stamping is quite high. A more sensible solution may be to require that the implementer is unaffiliated with the spec author; in other words, the implementation is derived from the spec + IETF discussion context. A third comment would be that, if you interpret the draft strictly, it is highly unlikely that the experiment would ever be exercised, as the implementation needs to match the draft to be advanced, and that would mean that the implementation has to follow in lockstep with the draft development up until the final version. With respect to the core subject matter of a draft, that may be fine. However, many of the final edits in a draft come as input from IETF wide community review; things like security, congestion control, and the like. Those are often trivial to write down, but can have a major implementation impact. To cure this, it would IMO be acceptable if the implementation would be required to match the latest or a reasonably young, i.e. a few months old version of the draft. Please consider this. Thanks, Stephan On 1.11.2013 08:21 , Adrian Farrel adr...@olddog.co.uk wrote: Hi Alexa, Please be aware of this document that has just entered a four-week IETF last call. The document describes a proposed IETF process experiment under the rules of RFC 3933. The proposed experiment calls on the IETF Secretariat to take specific actions under certain circumstances in corner cases of the experiment. Could you please have someone in the Secretariat look at the draft and comment on the practicalities of the actions. Note that, at this stage, no changes to the tools are proposed so any actions would require manual intervention (if the experiment were successful and resulted in permanent changes to IETF process we might make changes to the tools at some future time). Thanks, Adrian -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 11 January 2013 15:15 To: IETF-Announce Subject: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as Experimental 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 ietf@ietf.org mailing lists by 2013-02-08. 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
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Hi SM, I totally agree with your comments and suggestions, the draft SHOULD mention the important clarifications and the answers to SM's questions. This is an important draft and SHUOLD be clear about such important details in sections, why it ignores them without refering to informative procedure items to link things for understanding. How do authors write these drafts are they done with following procedure, AB In Section 1: Additionally, the experiment will only require issues raised during these three stages to be addressed if they meet the IESG's Discuss criteria. Does this mean that a document does not have to represent consensus? In contrast, a -bis RFC that aims for Proposed Standard or Experimental is likely to be a fine candidate. I read what the document proposes as lowering the barrier of entry for first publication. My preference is to say nothing about -bis RFCs (see quoted text). Some of the -bis drafts I have come across (note that this is not related to a draft being discussed currently) are not well-written even though there is running code. The running code might be due to author intervention instead of a blind test of the specification. In Section 2: Implementations developed during the production of an Internet-draft can indicate that a working group has had the opportunity to get early confirmation of its engineering choices. Agreed. In Section 3: Any Working Group Last Call (WGLC) or Area Director (AD) review (which are routinely done, though not part of the formal [BCP9] process) will run in parallel with the two-week IETF Last Call (IETF-LC) period. I am not suggesting changing the two weeks. It can cause logistical problems. I'll take the risk of trying this experiment. Only comments that would be DISCUSS-worthy according to the IESG Discuss Criteria [DCRIT] need be handled during last call. Other comments can be handled or not, at the authors/editors discretion. See my previous comment about this criteria. In Section 4: The fast-track process can be used for bis RFCs and might well be quite suitable for those. I suggest removing this. If the timers (IETF LC or the two-weeks after IETF LC for fixing things) co-incide with a major holiday period or IETF meeting then the responsible AD can add a week or two as appropriate. I suggest not using the Fast-Track if it is less than two weeks before or after an IETF meeting. Some people only do IETF work during that period and that results in a spike. I don't think that it is a good idea for this experiment to encourage work during the meeting phase instead of the mailing list. In Section 5: An AD who wishes to do her review in parallel with Last Call is always free to make that choice. his or a gender neutral term. This memo itself has no impact on appeal processes. However, in considering an appeal that relates to a document that has been fast-track processed, the relevant judge (WG chair, AD, IESG or IAB as appropriate) should consider the requirements posited here. The WG Chair is not a judge in such cases as it would be his/her decision being appealed. Some people are discouraged from bringing work into the IETF because of the long debates (which I likely contributed to). Big companies have an incentive to do work within the IETF. There is a perception in open source circles than there isn't much to gain in having a specification published as a RFC. The young, free and wild will not listen to the fogies. The better approach, in my opinion, is not to act as a gatekeeper or encourage a wall-garden attitude. Regards, -sm
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Hi Stephen, At 12:36 11-01-2013, Stephen Farrell wrote: You mean rough consensus of the IETF I guess? Good question. No, I mean consensus as that's also part what is gauged during a Last Call. First, WG rough consensus is formally unaffected. As is IESG review. And if IETF LC comments are received that do meet the IESG discuss criteria then those should be handled as now. I am not concerned about the WG rough consensus angle (for the experiment) as it is a subset of a Last Call. So I guess we're left with cases where there's a lack of rough consensus during IETF LC but where the meat of the disagreement is something that doesn't qualify for an IESG discuss ballot. Hmm, you mentioned rough consensus on an IETF Last Call. The IETF Last Call is about consensus. I may have misunderstood the experiment as I did not read it as rough consensus and running code. To say it differently, there isn't any change to the IETF Last Call; this is more about fast-tracking the WGLC and the IETF Last Call. I'd say that'd be quite likely to allow the responsible AD to say that there had been so much debate during IETF LC that this experiment ought not be used. Ok. So, I don't think this experiment has any major effect there really but maybe has a subtle one. I'll be interested in seeing if this happens if we do the experiment. Let's see how the experiment works out. I don't get what you mean. Can you explain? (I get that you don't want to mention -bis cases, but I don't get why.) What the experiment can do is make it easier to move from unpublished specification to RFC. The -bis draft is from a previous RFC. If you try to cover it the experiment can turn into a significant process change. I prefer to leave that unspecified and see how the experiment works out instead of telling people to use it for -bis drafts. In a -bis document is in good shape it should not be a significant problem to get it through the process. Not a bad idea. Something like fast-track must be started at least one month (longer?) before an IETF meeting starts ? The fast-track process cannot be initiated within two weeks of an IETF meeting. You lose five weeks, two before, one for the meeting, and two after. I guess the only problem I'd have with that is that for an experiment that'd run for one year, that takes out about 4 months (3 meetings and the year-end holidays) which is a lot. Ok, make it one week then (see my previous comment). If we extended the experiment to 18 months duration I'd have no problem with something like that though. Or with leaving it as-is. It can be left out as an implementation detail if it is easier to keep the experiment to 12 months. Can be. If a WG participant says the decision you made on that draft is broken: I appeal then they first send that to the WG chair. Ok. I don't see any text change being suggested there. Correct me if I'm wrong. You're not wrong. Regards, -sm
Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as Experimental 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 2013-02-08. 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 This memo describes an optional, fast-track way to progress a working group document to IESG review. It is provided as a process experiment as defined in RFC 3933 for use when working group chairs believe that there is running code that implements a working group Internet-Draft. The motivation is to have the IETF process explicitly consider running code, consistent with the IETF's overall philosophy of running code and rough consensus. In this process all of working group last call, IETF last call, and Area Director review are carried out in the same two week period. Only comments that meet IESG Discuss criteria need to be addressed during this stage, and authors are required to make any changes within two weeks. This experiment will run for one year. The file can be obtained via http://datatracker.ietf.org/doc/draft-farrell-ft/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-farrell-ft/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-eman-rfc4133bis-05.txt (Entity MIB (Version 4)) to Proposed Standard
The IESG has received a request from the Energy Management WG (eman) to consider the following document: - 'Entity MIB (Version 4)' draft-ietf-eman-rfc4133bis-05.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 2013-01-25. 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 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version of the Entity MIB, which obsoletes version 3 [RFC4133]. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/ballot/ No IPR declarations have been submitted directly on this I-D.
UPDATED Last Call: draft-ietf-radext-radius-extensions-08.txt (Remote Authentication Dial In User Service (RADIUS) Protocol Extensions) to Proposed Standard
The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions' draft-ietf-radext-radius-extensions-08.txt as Proposed Standard Note that this document is Standards Track and has normative references to two Informational documents, RFCs 2866 and 5176. See http://www.ietf.org/mail-archive/web/radext/current/msg07979.html for some history on those two RFCs. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-01-25. 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 Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-opsawg-oam-overview-08.txt (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms' draft-ietf-opsawg-oam-overview-08.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 2013-01-25. 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 Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-eman-requirements-10.txt (Requirements for Energy Management) to Informational RFC
The IESG has received a request from the Energy Management WG (eman) to consider the following document: - 'Requirements for Energy Management' draft-ietf-eman-requirements-10.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 2013-01-25. 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 This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions: Monitoring functions include identification of energy-managed devices and their components, monitoring of their power states, power inlets, power outlets, actual power, power properties, received energy, provided energy, and contained batteries. Control functions serve for controlling power supply and power state of energy-managed devices and their components. This document does not specify the features that must be implemented by compliant implementations but rather features that must be supported by standards for energy management. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/ballot/ No IPR declarations have been submitted directly on this I-D.
