secdir review of draft-groves-mikey-sakke-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. EDITORIAL COMMENTS In the Abstract, the acronym IDPKC doesn't match the capitalized letters in its expansion. Suggestion: s/Identifier-based Public Key Cryptography/Identifier-Based Public Key Cryptography/ In section 1, paragraph 2, s/legislation/legislations/. Why is the word "identifier" (and variants) persistently capitalized? It doesn't appear to be being used as a proper noun. In the title of section 2, s/Mode;/Mode:/. In section 2.1, paragraph 1, the acronym "TGK" is not expanded on first use. There is no IANA Considerations section, FULL STOP. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
I believe this proposal to be dangerous and undesirable. The fact is that the three stage process has never worked. As in not ever. If you take a look at the current Internet standards over half of the total are grandfathered from before the IETF was started. You cannot return to a state that never existed. The raising of the bar for proposed standard has a very simple reason: it is now almost impossible to change specifications once deployed. There is no point in conducting a security review after the RFC has issued, it is too late. Similarly there is no point in checking to see if the Gen Art criteria are met. Another factor here is that many specifications coming to IETF have already had significant work done. On Sat, Jan 29, 2011 at 5:39 PM, Scott O. Bradner wrote: > > I've previously expressed my opinion that proposals to muck with the > number of steps in teh IETF standards process will no do anything > useful (i.e., will not be effective) - JOhn and I have just posted > what, to us, would be a prerequisite for amy process mucking proposal > to succeed > > Scott > > - > From: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > Subject: I-D Action:draft-bradner-restore-proposed-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >Title : Restoring Proposed Standard to Its Intended Use >Author(s) : J. Klensin, S. Bradner >Filename: draft-bradner-restore-proposed-00.txt >Pages : 6 >Date: 2011-01-29 > > Restore the very low bar for Proposed Standard described in RFC 2026 > (BCP 9) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote: > The raising of the bar for proposed standard has a very simple reason: it is > now almost impossible to change specifications once deployed. That's an argument for _no_ maturity levels, then, not for two. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
On 1/29/11 9:34 PM, Joe Touch wrote: On 1/29/2011 8:54 PM, Cullen Jennings wrote: On Jan 27, 2011, at 17:10 , Joe Touch wrote: ... AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. As per my other note: RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments. The term "Expert Review" is defined in RFC 2434. Neither document binds IANA to use the advice of a reviewer. Further, there is no single reviewer - we have a team, consulting each other on occasion, and all decisions are seen by multiple reviewers. However, none of that is worth codifying. If IANA or the IESG doesn't like how we serve them, they can replace us - at any time, for any reason, and there is an appeals process for decisions of the expert team: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Now that this has been made clear to me, I am *much* more worried about the wording in the current draft. The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. As Cullen and others have pointed out, there are sometimes very good technical reasons for a particular protocol to need to have two ports. The document should be amended to say that protocols with IETF consensus should get as many ports as it needs, regardless of what IANA or the expert reviewer thinks. This makes it the responsibility of the IETF consensus process to follow the guidelines in this document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Jan 30, 2011, at 9:58 AM, Andrew Sullivan wrote: > On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote: > >> The raising of the bar for proposed standard has a very simple reason: it is >> now almost impossible to change specifications once deployed. > > That's an argument for _no_ maturity levels, then, not for two. Is there an implicit assumption here that more standards (presumably of poorer quality) is a good thing? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Sun, Jan 30, 2011 at 10:15:01AM -0500, Keith Moore wrote: > > > > That's an argument for _no_ maturity levels, then, not for two. > > Is there an implicit assumption here that more standards (presumably of > poorer quality) is a good thing? Not on my part. I'm merely observing that, if the claim is that you can't alter deployed protocols, then there's no reason to say that we need two maturity levels, because in fact nothing will advance past the first stage anyway. Phillip's description of the state of affairs is consistent with what we actually see today in a three-maturity-level system: nothing moves past the first level. But if the problem is that you can't alter a deployed spec, then no matter how many levels we pare off past the first, nothing will move to those higher levels, because it's only the first level that counts. I'm not happy about this, note. I'm just making an observation about what is entailed by Phillip's description. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Jan 30, 2011, at 10:35 AM, Andrew Sullivan wrote: > On Sun, Jan 30, 2011 at 10:15:01AM -0500, Keith Moore wrote: >>> >>> That's an argument for _no_ maturity levels, then, not for two. >> >> Is there an implicit assumption here that more standards (presumably of >> poorer quality) is a good thing? > > Not on my part. Sorry, I didn't mean to imply that it was your assumption. I do wonder if it's an assumption held by many in the discussion. > I'm merely observing that, if the claim is that you > can't alter deployed protocols, then there's no reason to say that we > need two maturity levels, because in fact nothing will advance past > the first stage anyway. As far as I can tell, the principal reason any specifications move beyond Proposed is that they are widely deployed and their limitations become apparent. So I think you can alter deployed protocols, but only if the protocols or their implementations are seen to be sufficiently broken. (Which could lead one to conclude, from a perverse point-of-view, that some flaws should be left in at Proposed Standards so that they'll have to be fixed later, so that we can get more Draft and Full Standards published.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On 1/30/2011 7:35 AM, Andrew Sullivan wrote: Is there an implicit assumption here that more standards (presumably of poorer quality) is a good thing? Not on my part. I'm merely observing that, if the claim is that you can't alter deployed protocols, then there's no reason to say that we need two maturity levels, because in fact nothing will advance past the first stage anyway. The current proposal specifies a second maturity level that does not permit changing the technical specification. But if the problem is that you can't alter a deployed spec, then no matter how many levels we pare off past the first, nothing will move to those higher levels, because it's only the first level that counts. The rationale for the second level concerns assessment of success, not changes to the protocol. So the basis upon which the second level will succeed or fail has nothing to do with the criterion you are citing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Sun, Jan 30, 2011 at 07:49:44AM -0800, Dave CROCKER wrote: >> Not on my part. I'm merely observing that, if the claim is that you can't >> alter deployed protocols, then there's no reason to say that we need two >> maturity levels, because in fact nothing will advance past the first stage >> anyway. > > The current proposal specifies a second maturity level that does not > permit changing the technical specification. Yes, I know. I fail completely to see why anyone would ever do the work for such movement of maturity level. The proposal seems to me to be something along the lines of giving gold stars to protocols with people who are willing to do the busywork. I don't have any special objection to the proposal, and I don't really have strong feelings about whether it goes anywhere. But I don't believe it will change things very much, and it feels to me more like a bureaucratic improvement than something that helps IETF participants and consumers of IETF protocols. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Sun, Jan 30, 2011 at 9:58 AM, Andrew Sullivan wrote: > On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote: > > > The raising of the bar for proposed standard has a very simple reason: it > is > > now almost impossible to change specifications once deployed. > > That's an argument for _no_ maturity levels, then, not for two. > Not at all, many protocols are never successfully deployed. In the case that a protocol is successfully deployed, the final protocol has frequently required major modification. Documenting those changes has value. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Paul (et al.), See below. Note that IANA can't just make its own decisions either and ignore IETF process *AND* expert review. I wasn't trying to imply that, but it appears to have been inferred from my claim that "neither document binds IANA to the advice of a reviewer". IANA is bound by the "OR" of basic IETF process and Expert Review. The former can override the latter (or vice versa), but there is an appeal process - through the IETF - as well. If you have issue with these processes, then RFC 2434 and RFC 2780 are your targets, not this doc. Joe On 1/30/2011 7:12 AM, Paul Hoffman wrote: On 1/29/11 9:34 PM, Joe Touch wrote: ... As per my other note: RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments. The term "Expert Review" is defined in RFC 2434. Neither document binds IANA to use the advice of a reviewer. Further, there is no single reviewer - we have a team, consulting each other on occasion, and all decisions are seen by multiple reviewers. However, none of that is worth codifying. If IANA or the IESG doesn't like how we serve them, they can replace us - at any time, for any reason, and there is an appeals process for decisions of the expert team: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Now that this has been made clear to me, I am *much* more worried about the wording in the current draft. The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. Repeating myself: a) this document is NOT proscribing IANA processes for expert review of port requests b) RFC 2790 describes MANY ways IANA decides how to allocate ports: Values in this namespace are assigned following a Specification Required, Expert Review, IESG Approval, IETF Consensus, or Standards Action. Note the word *OR* above. Expert review doesn't override IETF process here. The document should be amended to say that protocols with IETF consensus should get as many ports as it needs, regardless of what IANA or the expert reviewer thinks. The above section already allows for that. This makes it the responsibility of the IETF consensus process to follow the guidelines in this document. This document says, quite clearly, at the front of Section 7.2: This section summarizes the current principles by which IANA handles the Service Name and Transport Protocol Port Number Registry and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA has flexibility beyond these principles when handling assignment requests; other factors may come into play, and exceptions may be made to best serve the needs of the Internet. It never says that this is a process that the IESG or IETF is required to follow. The language of the section has wiggle words throughout, and does not use RFC 2119 language. Thus nobody anywhere is bound by it. c) RFC 2434 notes how expert reviewers are selected: Designated experts are appointed by the relevant Area Director of the IESG. They are typically named at the time a document that creates a new numbering space is published as an RFC, but as experts originally appointed may later become unavailable, the relevant Area Director will appoint replacements if necessary. d) there is already a process to appeal decisions that are based on Expert Review: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG. -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for Review - draft-yevstifeyev-genarea-historic-01
Mykyta Yevstifeyev wrote: >> I'd like to see some kind of guideline that the RFC should not be considered >> obsolete solely because of security or performance concerns in some >> particular, specific context. For example, the fact that vanilla FTP is not >> sufficiently secure for use in some applications where high security is >> paramount is not a rationale for deprecating FTP in all applications. > > In the case I mentioned as c the key words are 'is not possible or is not > advised to be used in the Internet' but not what you mentioned. The document says “is not advised to be used in the Internet because of its security issues, impact on its performance or any other reason.” (Do you agree that the document says that?) My point is that, because security or performance issues in one context do not necessarily imply security or performance issues in all contexts, they should not by themselves (or together with the 7-year criterion) be sufficient to trigger deprecation. > The phrase 'or any other reason' is put because there is no possibility to > put the exhaustive list of such purposes. Anyway, what would you like to > propose here? I don’t have exact replacement wording. “Any other reason” could permit me to propose deprecation or “historicization” of a protocol because I don’t like the guy who created it, or because my company is promoting a rival protocol. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: >> AFAICT, the experts team reports to IANA. We make recommendations to >> them. They are the ones who have the conversation with the applicant. >> They can take our advice or not - that's their decision. > > I think you are pretty misrepresenting the situation. My impression of the > reality of the situation is that if the IANA did not like the advice of the > expert reviewer, they might ask the AD to override but short of that they > pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, "David Conrad" wrote: > Cullen, > > On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: >>> AFAICT, the experts team reports to IANA. We make recommendations to >>> them. They are the ones who have the conversation with the applicant. >>> They can take our advice or not - that's their decision. >> >> I think you are pretty misrepresenting the situation. My impression of the >> reality of the situation is that if the IANA did not like the advice of the >> expert reviewer, they might ask the AD to override but short of that they >> pretty much do whatever the expert says. > > > Joe is closer. > > In general, IANA staff are not technical experts in any of the wide variety of > areas for which they are asked to provide registry services. As such, they > rely on technical experts to provide input/advice/recommendations. In the > past, there were some very rare cases in which the advice provided by the > technical experts was deemed insufficient and IANA staff looked to the ADs or > the IESG for additional input. However, at least historically, IANA staff > viewed the maintenance of the registries as their responsibility (at the > direction of the IESG), not the technical experts' responsibility. I would be > surprised if this had changed. > > Regards, > -drc > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for Review - draft-yevstifeyev-genarea-historic-01
Doug, all, 30.01.2011 20:51, Doug Ewell wrote: Mykyta Yevstifeyev wrote: >> I'd like to see some kind of guideline that the RFC should not be considered obsolete solely because of security or performance concerns in some particular, specific context. For example, the fact that vanilla FTP is not sufficiently secure for use in some applications where high security is paramount is not a rationale for deprecating FTP in all applications. > > In the case I mentioned as c the key words are 'is not possible or is not advised to be used in the Internet' but not what you mentioned. The document says “is not advised to be used in the Internet because of its security issues, impact on its performance or any other reason.” (Do you agree that the document says that?) My point is that, because security or performance issues in one context do not necessarily imply security or performance issues in all contexts, they should not by themselves (or together with the 7-year criterion) be sufficient to trigger deprecation. I've recently thought on how to formulate this criterion. My most current thoughts are the following: c. The RFC describes the technology that is not possible to be used in the current Internet because of its technical characteristics or possible problems with its implementation. However this is not a final variant - any other proposals are welcome. > The phrase 'or any other reason' is put because there is no possibility to put the exhaustive list of such purposes. Anyway, what would you like to propose here? I don’t have exact replacement wording. “Any other reason” could permit me to propose deprecation or “historicization” of a protocol because I don’t like the guy who created it, or because my company is promoting a rival protocol. Agreed here. See what I think below. - And now a few questions for discussion: 1) Should historicizing Informational RFCs be allowed? My proposal is to allow this only if they describe the protocol (see Section 4.2.2 of RFC 2026) with the authors' approval REQUIRED. 2) Definition of obsolete RFCs are still unclear. The most recent what I have is: The RFC SHALL be considered to be obsolete if it meets the following criteria: a. It has been publicly available for at least 7 years; b. During this period of time the technology, described in this RFC has not been seen used in the Internet; or c. The RFC describes the technology that is not possible to be used in the current Internet because of its technical characteristics or possible problems with its implementation. Any proposals on this? 3) Procedures on Experimental RFCs to Historic. What I have in my working version is different from what is in -01 version. See below: 3.2.3. Experimental RFCs Procedures for historicizing Experimental RFCs depend on their origin and the way it is being historicized with. 3.2.3.1. Separate Historicizing Document The procedures described in this section apply to the case, mentioned as 'b' at the beginning of Section 3.2 (separate historicizing document). If the Experimental RFCs has been processed on IETF stream [RFC4844], 'IETF Consensus' [RFC5226] is REQUIRED to historicize it. If the Experimental RFCs has been processed on IAB stream [RFC4844], 'IETF Consensus' [RFC5226] and IAB Chair approval is REQUIRED to historicize it. If the Experimental RFCs has been processed on IRTF stream [RFC4844], 'IETF Consensus' [RFC5226] and IRTF Chair approval is REQUIRED to historicize it. If the Experimental RFCs has been processed on Independent Submissions stream [RFC4844], 'IETF Consensus' [RFC5226] and authors' approval is REQUIRED to historicize it. In essential cases the approval of the director of the area the historicized document is considered to be related to MAY be used instead the authors' one. In the cases described above IESG is responsible for recording their approval. 3.2.3.2. Superseding Document Historicizes the Superseded One The procedures described in this section apply to the case, mentioned as 'a' at the beginning of Section 3.2 (superseding document historicizes the superseded one). The superseding document that is being processed on the same stream [RFC4844] as the superseded one MAY move it to Historic without any special procedures; a simple mention of such action is therefore REQUIRED in superseding document. If the superseding document is being processed on the stream, different from that of superseded one, the approval of corresponding party is REQUIRED. Section 3.2.3.1 describes some cases that apply this one as well (for IAB-, IETF-, and Independent Submissions streams [RFC4844]). Historicizing IETF-stream documents by non-IETF- stream ones SHALL be made following usual procedures for RFCs of such stream with IETF Chair approval REQUIRED. 4) Are there
