Atompub WG activity (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
The IESG has received a request from the Atom Publishing Format and Protocol WG (atompub) to consider the following document: - 'The Atom Publishing Protocol ' draft-ietf-atompub-protocol-14.txt as a Proposed Standard By my count, draft-ietf-atompub-protocol-14.txt has generated over 250 on-topic comments on the WG list since March 06, when the version was announced. It is clearly not ready for publication. I don't think it is appropriate for the IETF as a whole to review this document. - Rob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Atompub WG activity (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Robert Sayre schrieb: The IESG has received a request from the Atom Publishing Format and Protocol WG (atompub) to consider the following document: - 'The Atom Publishing Protocol ' draft-ietf-atompub-protocol-14.txt as a Proposed Standard By my count, draft-ietf-atompub-protocol-14.txt has generated over 250 on-topic comments on the WG list since March 06, when the version was announced. It is clearly not ready for publication. I don't think it is appropriate for the IETF as a whole to review this document. + 0,5. The document got lots of constructive feedback in the previous weeks (mainly due to fresh eyes), and I think it would be worthwhile to resolve most of the issues that were raised before doing the Last Call. This will save lots of time spent by new reviewers raising new issues. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-martin-ibcs (Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems) to Informational RFC
I'd feel uncomfortable approving this draft until the authors indicate that any IPR disclosures required by our process have been filed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Mon, 12 Mar 2007, The IESG wrote: A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt ... Working Group Summary This document set was not produced by an IETF working group, but by an individual. IETF Last Call produced no comments, and solicited reviewers were basically positive. This writeup was not updated or comments were not duly processed. I see 14 Last Call comments (retaining the subject line) on [EMAIL PROTECTED], as well as 12 comments under the 'Protest: Complexity running rampant' thread. Agreed... I was about to send a similar note when I saw this one. I would add that few of the 14 comments were really positive about this specification. In addition, several of the comments on both threads asked for specific clarification of the need to introduce the complexities inherent in an additional syntax for accomplishing the underlying functionality. The document has not been modified to reflect those concerns. If the IESG is going to claim a silent majority in favor of approving this document, so be it. But to claim that there were no Last Call comments and that those that were solicited were positive is deeply problematic.It even leads one to wonder whether the IESG has ignored critical comments in other cases, but I trust that has not occurred. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
I saw almost no technical comments on the documents. Most of the last call comments I saw were on a side track about copyright issues. The one somewhat technical comment that I logged, from Tom Yu, didn't result in any changes but was certainly influential on me in agreeing to the documents being reclassified from standards track to Experimental. This could have been acknowledged in the writeup, I guess. Brian On 2007-03-13 14:04, John C Klensin wrote: --On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Mon, 12 Mar 2007, The IESG wrote: A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt ... Working Group Summary This document set was not produced by an IETF working group, but by an individual. IETF Last Call produced no comments, and solicited reviewers were basically positive. This writeup was not updated or comments were not duly processed. I see 14 Last Call comments (retaining the subject line) on [EMAIL PROTECTED], as well as 12 comments under the 'Protest: Complexity running rampant' thread. Agreed... I was about to send a similar note when I saw this one. I would add that few of the 14 comments were really positive about this specification. In addition, several of the comments on both threads asked for specific clarification of the need to introduce the complexities inherent in an additional syntax for accomplishing the underlying functionality. The document has not been modified to reflect those concerns. If the IESG is going to claim a silent majority in favor of approving this document, so be it. But to claim that there were no Last Call comments and that those that were solicited were positive is deeply problematic.It even leads one to wonder whether the IESG has ignored critical comments in other cases, but I trust that has not occurred. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-ltans-ers (Evidence Record Syntax (ERS)) to Proposed Standard - comment from Tim and answer
Comment to the draft received from Tim Polk during review: I thought I might follow up on the first unaddressed comment: I notice that the phrase the Initial Archive Timestamp frequently appears in the text with a capitalized 'I' in word initial. This seems to indicate that there *is* something special about this timestamp, and I would expect to find a definition in the terminology section. Perhaps a lowercase 'i' would more clearly indicate that it is simply a subtype with the same structure? That is, if the phrase was the initial Archive Timestamp, I would only expect to find Archive Timestamp in the terminology section. (Actually, the phrase appears with a lowercase 'i' twice - once in section 1.2 and again in 5.2. I assume there is no difference?) Thanks, Tim Polk Answer from I-D author: Hi Tim, I agree with you, and follow your comment and will make sure in the final revision of the draft that the word initial of the initial Archive Timestamp only starts with a capital letter at the beginning of a sentence. Thanks, Tobias ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs (IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks) to Proposed Standard
Hello, A slightly revised version of the I-D is now available at: http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt This revision incorporates changes based on some of the comments made by the directorate. It will be submitted to the ID repository as soon as the gates are opened. -Basavaraj On 3/12/07 9:57 AM, ext The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the IP over IEEE 802.16 Networks WG (16ng) to consider the following document: - 'IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks ' draft-ietf-16ng-ipv6-over-ipv6cs-08.txt as a 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 ietf@ietf.org mailing lists by 2007-03-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15298; rfc_flag=0 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-openpgp-rfc2440bis (OpenPGP Message Format) to Proposed Standard
Hi! I started a review by going through the reference section. There seems to be some editing left to do... There are reference to old documents, including: RFC 2279 - RFC 3629 RFC 1750 - RFC 4086 There are normative reference to non-standards track RFCs, including: RFC 1641 RFC 1951 RFC 1991 (which documents is intended to obsolete?) RFC 2144 The following reference are never cited in the text as far as I can tell. Most of them should likely be removed, but citing [BLEICHENBACHER] at some appropriate point may be useful. [RFC1423]Balenson, D., Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, RFC 1423, October 1993. [RFC1641]Goldsmith, D. and M. Davis, Using Unicode with MIME, RFC 1641, July 1994. [BLEICHENBACHER] Bleichenbacher, Daniel, Generating Elgamal signatures without knowing the secret key, Eurocrypt 96. Note that the version in the proceedings has an error. A revised version is available at the time of writing from ftp://ftp.inf.ethz.ch/pub/publications/papers/ti /isc/ElGamal.ps [DONNERHACKE]Donnerhacke, L., et. al, PGP263in - an improved international version of PGP, ftp://ftp.iks- jena.de/mitarb/lutz/crypt/software/pgp/ [MAURER] Ueli Maurer, Modelling a Public-Key Infrastructure, Proc. 1996 European Symposium on Research in Computer Security (ESORICS' 96), Lecture Notes in Computer Science, Springer-Verlag, vol. 1146, pp. 325-350, Sep 1996. [RFC1983]Malkin, G., Internet Users' Glossary, FYI 18, RFC 1983, August 1996. /Simon The IESG [EMAIL PROTECTED] writes: The IESG has received a request from the An Open Specification for Pretty Good Privacy WG (openpgp) to consider the following document: - 'OpenPGP Message Format ' draft-ietf-openpgp-rfc2440bis-19.txt as a 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 ietf@ietf.org mailing lists by 2007-03-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-19.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=4936rfc_flag=0 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-martin-ibcs (Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems) to Informational RFC
See https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=751 At 08:43 AM 3/13/2007, Sam Hartman wrote: I'd feel uncomfortable approving this draft until the authors indicate that any IPR disclosures required by our process have been filed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Atompub WG activity (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
While it is definitely true that there has been a lot of good feedback, it would still be good to at least start broadening the net and get feedback from the larger IETF community. - James Julian Reschke wrote: [snip] + 0,5. The document got lots of constructive feedback in the previous weeks (mainly due to fresh eyes), and I think it would be worthwhile to resolve most of the issues that were raised before doing the Last Call. This will save lots of time spent by new reviewers raising new issues. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
Pekka Savola [EMAIL PROTECTED] writes: On Mon, 12 Mar 2007, The IESG wrote: A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt ... Working Group Summary This document set was not produced by an IETF working group, but by an individual. IETF Last Call produced no comments, and solicited reviewers were basically positive. This writeup was not updated or comments were not duly processed. I see 14 Last Call comments (retaining the subject line) on [EMAIL PROTECTED], as well as 12 comments under the 'Protest: Complexity running rampant' thread. Thanks for pointing this out. I believe the protocol is not possible to implement due to the copyright issue, because the ASN.1 schema specifically says that the IETF copying conditions apply to it: -- Copyright (C) The IETF Trust (2006). This version of -- this ASN.1 module is part of RFC ; see the RFC itself -- for full legal notices. I registered this as last call comment in http://article.gmane.org/gmane.ietf.general/23684 where I also suggested a way to solve this problem. I believe the IETF should not specify protocols that require that you violate a copyright notice to implement. Further, the copyright notice in the document appears to be both incorrect and to violate the IETF process. Typically copyrights on document text are not transferred to the IETF Trust, and I see no signs that this happened here. The notice violates the requirements set forth by RFC 3978 section 5.4 (as updated by RFC 4748) which says: 5.4. Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) Copyright (C) The IETF Trust (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Additional copyright notices are not permitted in IETF Documents ... The notice in the document doesn't match the required notice, and is thus not permitted under RFC 3978. Or am I missing something? I suppose an appeal is one way to bring this up formally, although if this can be resolved in a better way that would be preferable. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
I agree that there were no technical comments but the summary states 'no comments'. Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat. If an argument can always be used what is the discrimination power? -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 10:11 AM To: John C Klensin Cc: ietf@ietf.org; Pekka Savola; iesg@ietf.org Subject: Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC I saw almost no technical comments on the documents. Most of the last call comments I saw were on a side track about copyright issues. The one somewhat technical comment that I logged, from Tom Yu, didn't result in any changes but was certainly influential on me in agreeing to the documents being reclassified from standards track to Experimental. This could have been acknowledged in the writeup, I guess. Brian On 2007-03-13 14:04, John C Klensin wrote: --On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Mon, 12 Mar 2007, The IESG wrote: A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt ... Working Group Summary This document set was not produced by an IETF working group, but by an individual. IETF Last Call produced no comments, and solicited reviewers were basically positive. This writeup was not updated or comments were not duly processed. I see 14 Last Call comments (retaining the subject line) on [EMAIL PROTECTED], as well as 12 comments under the 'Protest: Complexity running rampant' thread. Agreed... I was about to send a similar note when I saw this one. I would add that few of the 14 comments were really positive about this specification. In addition, several of the comments on both threads asked for specific clarification of the need to introduce the complexities inherent in an additional syntax for accomplishing the underlying functionality. The document has not been modified to reflect those concerns. If the IESG is going to claim a silent majority in favor of approving this document, so be it. But to claim that there were no Last Call comments and that those that were solicited were positive is deeply problematic.It even leads one to wonder whether the IESG has ignored critical comments in other cases, but I trust that has not occurred. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
On Tue, Mar 13, 2007 at 08:09:35AM -0700, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote a message of 76 lines which said: Everything we do is complex. There are degrees in complexity. Compare RFC 3912 with 3981, both written by your co-workers :-) So, I do not think that the complexity argument should be dismissed. Sometimes, standards are too complicated and one of the things I like about IETF protocols, is that they are typically simpler than standards produced by most other organisations. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
At 7:47 AM +0200 3/13/07, Pekka Savola wrote: On Mon, 12 Mar 2007, The IESG wrote: A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt ... Working Group Summary This document set was not produced by an IETF working group, but by an individual. IETF Last Call produced no comments, and solicited reviewers were basically positive. This writeup was not updated or comments were not duly processed. I see 14 Last Call comments (retaining the subject line) on [EMAIL PROTECTED], as well as 12 comments under the 'Protest: Complexity running rampant' thread. You are correct; sorry about that. The Last call commentscame in quite late, and I simply forgot to update the write-up after the discussion took place. The result of those was the updated status, to experimental (rather than standards track), so they were heard; I just didn't track them correctly into the write-up. Again, my apologies, regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat. If an argument can always be used what is the discrimination power? How about using answers to the question Is this complexity needed? as a discriminator? Sometimes, there is no better solution than one with certain complexity. That isn't inherently bad. I'm not sure the need for this particular complex solution was demonstrated. I don't recall anyone defending it. The experimental track thus seems appropriate, if it should be published at all. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-martin-ibcs (Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems) to Informational RFC
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ See Russ https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=751 Russ At 08:43 AM 3/13/2007, Sam Hartman wrote: *Sigh* I searched on the draft before sending the last call comment and when the search tool is used no documents show up. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
Absolutely there are degrees in complexity. But there are no objective measures. PKIX is certainly not a simple specification. It got that way for one simple reason - people used it enough to care about it. So over fifteen years it has grown. My point here is that if you look at an architecture with five layers it will appear to be more complex than one with two layers. But that does not say anything useful about the complexity of the overall system. Is the complexity in the design or in the requirements? If PKIX had originally been designed to anticipate a wider range of functions it could have been made much simpler. We could for example have used the same structure for CRLs and OCSP if both needs had been anticipated up front. Encoding ASN.1 in XML allows implementations to reduce the number of parser/encoder modules that they need to deal with. That represents a reduction in complexity as far as an embedded single purpose device is concerned. If you are writing an all purpose development tool your work has increased. Every change we make has complexity implications, very rarely does the complexity go down. A valid complexity argument in my view would be 'I can meet that set of needs in this way which is empirically less complex by virtue of these considerations (number of states required, number of different syntaxes, administrative burden)'. Simply stating 'that is more complex' does not tell me anything useful. Is the complexity unreasonable considering the objective. In this case the idea of being able to eventually eliminate the need for dual stack implementations of ASN.1 based protocols in the XML/SOAP world is very attractive to me. Having a single standard mapping from the ASN.1 world to the XML one is equally so. -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 11:23 AM To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC On Tue, Mar 13, 2007 at 08:09:35AM -0700, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote a message of 76 lines which said: Everything we do is complex. There are degrees in complexity. Compare RFC 3912 with 3981, both written by your co-workers :-) So, I do not think that the complexity argument should be dismissed. Sometimes, standards are too complicated and one of the things I like about IETF protocols, is that they are typically simpler than standards produced by most other organisations. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
From: Simon Josefsson [mailto:[EMAIL PROTECTED] Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat. If an argument can always be used what is the discrimination power? How about using answers to the question Is this complexity needed? as a discriminator? Sometimes, there is no better solution than one with certain complexity. That isn't inherently bad. I'm not sure the need for this particular complex solution was demonstrated. I don't recall anyone defending it. The experimental track thus seems appropriate, if it should be published at all. Define 'need'. Define 'complexity'. From my point of view a device that has two parser stacks on it is more complex than a device that can do it all with a single stack. Thus translating SNMP into XML makes excellent sense and reduces complexity overall. I don't think it makes sense to translate every ASN.1 protocol into XML, particularly if there is an XML infrastructure for the purpose. But I would certainly prefer to be able to support SNMP on an XML centric device without having to provide an ASN.1 stack. Further I would like there to be consistency in the way that SNMP/XML and LDAP/XML to map to the traditional ASN.1 versions. It's a legitimate architectural approach and the IETF should not take sides against it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
From the draft: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818]. See [RFC4346] for more information on TLS. I've discovered a small but potentially critical mistake in the references here. RFC2818 is an informative reference, so the text must read as specified by [RFC4346]. - Rob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Robert == Robert Sayre [EMAIL PROTECTED] writes: Robert From the draft: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818]. See [RFC4346] for more information on TLS. Robert I've discovered a small but potentially critical mistake Robert in the references here. RFC2818 is an informative Robert reference, so the text must read as specified by Robert [RFC4346]. My preference is to resolve this by making 2818 normative; I believe we've already 3967'd 2818 so we don't need an additional last call on this one. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Sam Hartman wrote: My preference is to resolve this by making 2818 normative; I believe we've already 3967'd 2818 so we don't need an additional last call on this one. Is RFC 2818 sufficient to ensure interoperability? It would be quite easy for two implementations to claim to implement TLS and fail to interoperate. RFC 4346 contains mandatory cipher suites. Without those, conformant implementations could fail during authentication setup, right? The same danger would exist if the draft claimed HTTP Authentication must be supported without specifying a scheme. - Rob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Robert == Robert Sayre [EMAIL PROTECTED] writes: Robert Sam Hartman wrote: My preference is to resolve this by making 2818 normative; I believe we've already 3967'd 2818 so we don't need an additional last call on this one. Robert Is RFC 2818 sufficient to ensure interoperability? It Robert would be quite easy for two implementations to claim to Robert implement TLS and fail to interoperate. RFC 4346 Robert contains mandatory cipher suites. Without those, Robert conformant implementations could fail during Robert authentication setup, right? The same danger would exist I think both 2818 and 4346 contain important details and need to be normative. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
pbaker == Hallam-Baker, Phillip [EMAIL PROTECTED] writes: pbaker I agree that there were no technical comments but the summary pbaker states 'no comments'. Arguments on complexity are too easy to pbaker make. Every time a proposal is made I hear the complexity pbaker argument used against it. Everything we do is pbaker complex. Computers are complex. Committee process usually pbaker increases complexity somewhat. pbaker If an argument can always be used what is the discrimination power? I find that it's not useful to consider complexity as an abstract concept in this context. The world is complex. What is important is how we manage that complexity. I think that it is much more useful to evaluate complexity from a functional perspective. More later. ---Tom ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Sam Hartman wrote: I think both 2818 and 4346 contain important details and need to be normative. That makes sense to me. However, I initially thought the references had been mistakenly switched around. From the draft: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818]. See [RFC4346] for more information on TLS. This text is actively misleading, because it suggests RFC 4346 is included for informational purposes. The text should read: At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818] and [RFC4346]. - Rob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson [EMAIL PROTECTED] wrote: Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat. If an argument can always be used what is the discrimination power? How about using answers to the question Is this complexity needed? as a discriminator? Sometimes, there is no better solution than one with certain complexity. That isn't inherently bad. I'm not sure the need for this particular complex solution was demonstrated. I don't recall anyone defending it. The experimental track thus seems appropriate, if it should be published at all. But that was precisely where the other thread, if I recall, came out. It wasn't an argument against complexity. It was an argument about introducing another optional way of doing things because we _know_ that many options lead to worse interoperability. And it was a suggestion/ request that, before this document was published in _any_ form, that it at least acquire a clear discussion as to when one would select this form over the well-established ASN.1 form for which there is existing deployment, existing tools, etc. Put differently, we all know that this _can_ be done but, if there is another solution already out there, widely deployed, and in active use, a clear explanation about _why_ it should be done and under what circumstances it is expected to useful is in order. That suggestion about an explanation was a specific request about the document, not idle theorizing about the character of ASN.1 or the nature of complexity. And, again, pretending that the discussion didn't occur impresses me as a little strange. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
John C Klensin wrote: --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson [EMAIL PROTECTED] wrote: Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat. If an argument can always be used what is the discrimination power? How about using answers to the question Is this complexity needed? as a discriminator? Sometimes, there is no better solution than one with certain complexity. That isn't inherently bad. I'm not sure the need for this particular complex solution was demonstrated. I don't recall anyone defending it. The experimental track thus seems appropriate, if it should be published at all. But that was precisely where the other thread, if I recall, came out. It wasn't an argument against complexity. It was an argument about introducing another optional way of doing things because we _know_ that many options lead to worse interoperability. And it was a suggestion/ request that, before this document was published in _any_ form, that it at least acquire a clear discussion as to when one would select this form over the well-established ASN.1 form for which there is existing deployment, existing tools, etc. Put differently, we all know that this _can_ be done but, if there is another solution already out there, widely deployed, and in active use, a clear explanation about _why_ it should be done and under what circumstances it is expected to useful is in order. That suggestion about an explanation was a specific request about the document, not idle theorizing about the character of ASN.1 or the nature of complexity. And, again, pretending that the discussion didn't occur impresses me as a little strange. I was going to raise this issue, but I deleted the mail when I realized this is going to be an Experimental RFC (according to the subject line). I don't think it harms interoperability to introduce an experiment into the mix. If deployment and useful tools follow, then maybe a later revision can move to the standards track. john Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson [EMAIL PROTECTED] wrote: Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat. If an argument can always be used what is the discrimination power? How about using answers to the question Is this complexity needed? as a discriminator? Sometimes, there is no better solution than one with certain complexity. That isn't inherently bad. I'm not sure the need for this particular complex solution was demonstrated. I don't recall anyone defending it. The experimental track thus seems appropriate, if it should be published at all. But that was precisely where the other thread, if I recall, came out. It wasn't an argument against complexity. It was an argument about introducing another optional way of doing things because we _know_ that many options lead to worse interoperability. Yes, and I thought I sent in a note saying I supported this view but I cannot find it. I also strongly opposed standards-track publication and think experimental is a far better choice. And it was a suggestion/ request that, before this document was published in _any_ form, that it at least acquire a clear discussion as to when one would select this form over the well-established ASN.1 form for which there is existing deployment, existing tools, etc. This suggestion was at the very least strongly implicit in the earlier discussion. It also occurs to me that what may be needed here is a BCP on how to best use ASN.1. We have such a BCP on XML. ASN.1 is similarly complex and similarly decorated with features, so it makes sense to me that if we're going to continue to use it why not have a document discussing what features make sense and what ones don't. (For example, some sage advice on when and how to use EXTERNAL could have made several protocols a lot more tractable.) Put differently, we all know that this _can_ be done but, if there is another solution already out there, widely deployed, and in active use, a clear explanation about _why_ it should be done and under what circumstances it is expected to useful is in order. Given how little uptake (AFAIK) there has been of the various encodings for ASN.1 beyond BER and DER (let's see, there's CER and PER and at least two others whose names I cannot recall), I'm not especially worried about XER taking the world by storm. Indeed, I think it would actually help XER's case if there was some explanation of where and why you'd ever want to use it. The fact that pigs can be made to fly with enough dynamite doesn't get you permission to use explosives for purposes of implementing porcine aviation. That suggestion about an explanation was a specific request about the document, not idle theorizing about the character of ASN.1 or the nature of complexity. And, again, pretending that the discussion didn't occur impresses me as a little strange. Agreed. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
Ned == Ned Freed [EMAIL PROTECTED] writes: --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson [EMAIL PROTECTED] wrote: And it was a suggestion/ request that, before this document was published in _any_ form, that it at least acquire a clear discussion as to when one would select this form over the well-established ASN.1 form for which there is existing deployment, existing tools, etc. Ned This suggestion was at the very least strongly implicit in the earlier Ned discussion. I think I made some preliminary conclusions regarding the intent of this effort, which I can write more about later. Ned It also occurs to me that what may be needed here is a BCP on how to best use Ned ASN.1. We have such a BCP on XML. ASN.1 is similarly complex and similarly Ned decorated with features, so it makes sense to me that if we're going to Ned continue to use it why not have a document discussing what features make sense Ned and what ones don't. (For example, some sage advice on when and how to use Ned EXTERNAL could have made several protocols a lot more tractable.) I began such a document a few years ago. Perhaps I should dust it off. Also, I think many people contemplating ASN.1 would do well to read the actual specifications, as well as the reasonably good (and freely downloadable) books by Dubuisson and Larmouth. Put differently, we all know that this _can_ be done but, if there is another solution already out there, widely deployed, and in active use, a clear explanation about _why_ it should be done and under what circumstances it is expected to useful is in order. Ned Given how little uptake (AFAIK) there has been of the various encodings for Ned ASN.1 beyond BER and DER (let's see, there's CER and PER and at least two Ned others whose names I cannot recall), I'm not especially worried about XER Ned taking the world by storm. Indeed, I think it would actually help XER's case if Ned there was some explanation of where and why you'd ever want to use it. Use of alternative encoding rules might best be coupled with presentation layer negotiation, which is a direction the IETF has historically resisted moving towards, I think. (It doesn't help that PER is rather baroque for the sake of conserving bits.) Ned The fact that pigs can be made to fly with enough dynamite doesn't get you Ned permission to use explosives for purposes of implementing porcine aviation. That suggestion about an explanation was a specific request about the document, not idle theorizing about the character of ASN.1 or the nature of complexity. And, again, pretending that the discussion didn't occur impresses me as a little strange. Ned Agreed. I believe the omissions in the writeup have been acknowledged to be mistakes. ---Tom ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
Options are not necessarily complications. The only point to having XER that I can see is if you intend to allow an orderly transition from use of ASN.1 to use of XML. Both standards do their job fine, both are somewhat more complex than they should be. One of these choices is surplus to requirements. If I am writing in any modern development language that supports metadata such as .NET I can perform XML encoding and decoding automatically by simply calling up an encoder/decoder. To create the same capability in ASN.1 requires vastly more effort. If we had hundreds of ASN.1 schemas that people cared about in the IETF I might see an argument for continuing to dual stack ASN.1 and XML indefinitely. Given where we are enabling a phase out of ASN.1 for certain protocols makes a lot of sense. I don't think that this would make a lot of sense for PKIX but certainly for SNMP and LDAP. -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 6:13 PM To: Simon Josefsson; Hallam-Baker, Phillip Cc: Brian E Carpenter; iesg@ietf.org; ietf@ietf.org; Pekka Savola Subject: Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson [EMAIL PROTECTED] wrote: Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat. If an argument can always be used what is the discrimination power? How about using answers to the question Is this complexity needed? as a discriminator? Sometimes, there is no better solution than one with certain complexity. That isn't inherently bad. I'm not sure the need for this particular complex solution was demonstrated. I don't recall anyone defending it. The experimental track thus seems appropriate, if it should be published at all. But that was precisely where the other thread, if I recall, came out. It wasn't an argument against complexity. It was an argument about introducing another optional way of doing things because we _know_ that many options lead to worse interoperability. And it was a suggestion/ request that, before this document was published in _any_ form, that it at least acquire a clear discussion as to when one would select this form over the well-established ASN.1 form for which there is existing deployment, existing tools, etc. Put differently, we all know that this _can_ be done but, if there is another solution already out there, widely deployed, and in active use, a clear explanation about _why_ it should be done and under what circumstances it is expected to useful is in order. That suggestion about an explanation was a specific request about the document, not idle theorizing about the character of ASN.1 or the nature of complexity. And, again, pretending that the discussion didn't occur impresses me as a little strange. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 16:01 -0700 Andy Bierman [EMAIL PROTECTED] wrote: I was going to raise this issue, but I deleted the mail when I realized this is going to be an Experimental RFC (according to the subject line). I don't think it harms interoperability to introduce an experiment into the mix. If deployment and useful tools follow, then maybe a later revision can move to the standards track. Andy, I just found Ted's note explaining that the writeup was just an error. These things happen and my reaction was a little strong (pre-IETF tension, I think). Certainly, making it an experimental document helps with the worst of the problem. I'd be _seriously_ upset if we were advancing it onto the standards track with as little context as we have. But, even for an experimental document, I still think it would be highly desirable to get some serious discussion about why and when into it to justify publication in any form. I think Ned's note summarizes the reasons for that better than I could. I also think that, if the author took Ned's note, Phillip's recent one, contemplated both for a while, and then turned the combination into a rationale and context section (with appropriate acknowledgements, of course), that none of us would have anything significant to complain about. best, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
John, On Tue, Mar 13, 2007 at 09:04:52AM -0400, John C Klensin wrote: If the IESG is going to claim a silent majority in favor of approving this document, so be it. But to claim that there were no Last Call comments and that those that were solicited were positive is deeply problematic.It even leads one to wonder whether the IESG has ignored critical comments in other cases, but I trust that has not occurred. For the record, not everybody in the IESG was convinced that this document should be approved considering the discussion that happened on the IETF list. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 17:30 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Options are not necessarily complications. The only point to having XER that I can see is if you intend to allow an orderly transition from use of ASN.1 to use of XML. Both standards do their job fine, both are somewhat more complex than they should be. One of these choices is surplus to requirements. If I am writing in any modern development language that supports metadata such as .NET I can perform XML encoding and decoding automatically by simply calling up an encoder/decoder. To create the same capability in ASN.1 requires vastly more effort. If we had hundreds of ASN.1 schemas that people cared about in the IETF I might see an argument for continuing to dual stack ASN.1 and XML indefinitely. Given where we are enabling a phase out of ASN.1 for certain protocols makes a lot of sense. I don't think that this would make a lot of sense for PKIX but certainly for SNMP and LDAP. Whether I agree with the above or not (and I think we could debate your last couple of paragraphs at great length), if the document said something like that, I'd be a lot happier. And, perhaps like some others, I'm much less concerned about the document at this point than the claims that there were no comments and/or no actionable comments. I hope this is being discussed within the IESG because it would be a pity to write up an appeal at this point --especially just before the handoff-- if they were willing to just do the right thing. That, to me, would be to pull back the approval and either rewrite the statement or tune the document a bit or both. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
WG Action: Conclusion of WWW Distributed Authoring and Versioning (webdav)
The WWW Distributed Authoring and Versioning (webdav) in the Applications Area has concluded. The IESG contact persons are Ted Hardie and Lisa Dusseault. The work on WebDAV began in the summer of 1996, and the working group was officially chartered on March 20th of 1997. During the 10 years of WebDAV's work, it produced a core specification, RFC 2518, as well as work on work on ordered collections, access control, and related capabilities (RFCs 3648, 3744, 4331, and 4437). The first working group draft of an update to RFC 2518 was published in October of 2001, and new versions have been produced in response to interoperability testing and deployment. With the approval of draft-ietf-webdav-rfc2518bis, the working group will close. The working group mailing list will remain open, for discussion of individual submissions and as a general resource to the community. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
68th IETF - Agenda Changes
The following changes have been made since the agenda was printed. The web version of the agenda is up to date: CANCELLED msec - was scheduled on Tuesday at 1520-1720 SECOND SESSION krb-wg - second session on Tuesday at 1520-1720 Room: Karlin II MOVED mobopts - moved from Tuesday at 0900 to Thursday at 0900-1130 Room: Roma ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-openpgp-rfc2440bis (OpenPGP Message Format) to Proposed Standard
The IESG has received a request from the An Open Specification for Pretty Good Privacy WG (openpgp) to consider the following document: - 'OpenPGP Message Format ' draft-ietf-openpgp-rfc2440bis-19.txt as a 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 ietf@ietf.org mailing lists by 2007-03-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-19.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=4936rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
68th IETF - Transporation from Prague Airport
We have received the following information from the Hilton Prague regarding transporation from the airport to the Hotel. If you are not staying at the Hilton, contact the concierge at your hotel to inquire about their taxi service from the airport to hotel, most hotels offer this service. You can arrange to have a Hilton Hotel taxi pick you up at the airport for a cost of CZK 750 (EUR 27). You will need to make a reservation by either sending an email to [EMAIL PROTECTED] until Friday, March 16 or after that date, send an email to [EMAIL PROTECTED] or call + 00420 224842373. Duration: 30 minutes (depends on the traffic) Also, the SEDOP organized two shuttle busses: A) going to the city centre (to the Marriott hotel) for the rate of CZK 90,-/p. person one way B) going to the one address, which is given by the Clients, but than it is charged per car: 1 - 4 people on board, it costs CZK 480,-/p. car one way 5 - 8 people on board, it costs CZK 960,-/p. car one way The taxi service at the aiport is operated by AAA taxi and they are in front of the arrival hall. This is the exclusive partner of the Prague International Airport. The price chart is as follows: The regular taxi costs around CZK 400,-/p. car (depends on the traffic, because it is measured by the taxameter = at the beginning they charge you CZK 34,- as a starting fee and than CZK 25,- per each kilometer CZK 5,- for waiting (this is used even they are waiting in the traffic jam etc.). PUBLIC TRANSPORTATION bus No. 119 going from the Prague Airport to the bus stop Dejvicka, continue by the subway line A (green one) going to the station Museum and changed the line to the line C (red one) going to the station Florenc. And from this station it is just 200 metres to the Hilton Prague. Duration: 50 minutes Prices: CZK 20,-/p. ticket More info you can find on www.letiste-praha.cz there is also available site in English. Check out the 68 IETF wiki at: http://community.ietf.org/wiki/index.php/Main_Page You can sign up for the 68 attendees mailing list at: https://www1.ietf.org/mailman/listinfo/68attendees ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
