RFC 2195 (Was: what happened to newtrk?)
At 01:36 PM 9/7/2006, John C Klensin wrote: Actually, that topic opens up one of the fundamental issues with our standards process ... one where better definition and clear community consensus is, IMO, needed. Measured by our documented criteria, 2195 exists in multiple independent implementations, has been widely deployed, and is considered useful by many of those who are using it. In addition to security concerns, it must be stated that implementations of RFC 2195 suffer from interoperability problems due to its failure to specify a character set/encoding and normalization/preparation algorithm for the password string. The WG decided it was better to document current implementations of CRAM-MD5 than to rework CRAM-MD5 to address these and other issues, and to do so on the Informational track. If you have something new to add to the discussion of revision approach taken within the SASL WG, you (and others) are welcomed to comment on the SASL WG list. The document will be in WG Last Call soon. -- Kurt, SASL WG co-chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
At 04:07 PM 9/7/2006, John C Klensin wrote: I think we have a small misunderstanding here. Let me say more clearly and briefly My message was intended to clarify why the SASL WG is pursuing an Informational recommendation for its RFC2195bis work and to redirect any comments specific to this work to the WG's list. As it was not my intent to participate in the general discussion of fundamental issues with our standards process you raise (which is why I changed the subject), and your follow-up is in the same vein, I won't comment further. -- Kurt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: No jabber rooms for BOFs?
At 05:43 PM 7/10/2006, Melinda Shore wrote: No Jabber rooms for BOFs! You can borrow a room from an old WG/BOF (e.g., ldup) in a pinch. - Kurt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call Comments: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
At 03:32 AM 6/12/2006, Brian E Carpenter wrote: ... I believe the RFC 3978 practice and the RFC 2026 variance process provides adequate means publishing documents with such references. Kurt, what's the relevance of RFC 3978? It's a typo. I mean 3967. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call Comments: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
I do not support approval of this experiment. I opine that most of the publication delay is due to WG/author choice, not the downref rule. I also offer an alternative cure which keeps in place the downref rule in published RFCs. If a WG or individual is pursuing publication of a Standard Track RFC, they should consider the impact of normatively referencing documents of lessor maturity in the Standard Track on their document's progression. Consider the case where authors are revising an existing Standard Track protocol and their document normatively references a specification currently at Proposed. Today, authors have three choices: 1) Submit their document for Propose - no ref wait, 2) Submit their document for Draft - wait on the downref to reach Draft 3) Submit their document at Draft with a request for variance from the downref rule - no ref wait. Authors can avoid the downref wait simply by requesting publication at a lower maturity (option 1). When the reference is promoted, the authors can request a promotion of their document. Now, what might be interesting is to establish a (experimental) practice that an I-D (the target) is approved at Draft Standard that normatively references existing Proposed Standards can initially be published as a Proposed Standard. When the referenced RFCs are approved and announced at Draft, the target will be automatically announced at Draft. That is, no need to seek a separate IESG action. (Likewise for Internet Standard approved documents referencing Proposed and/or Draft Standards (published at the lessor maturity of the normative references).) I do not support allowing RFCs (on or off the standard track) to normatively reference Internet-Drafts and/or works in progress. As the proposal excludes all but approved I-Ds from the experiment, I will limit my comments to approved I-Ds (or 'RFC-to-be's). I believe the RFC-to-be (the target) wait on another RFC-to-be is not so great as to risk that a change to a referenced RFC-to-be negatively impacts implementor of the target RFC-to-be. There is, I believe (based on my experience in making last minute changes to RFC-to-bes), significant risk. I also believe the wait is minimal. It appears the practice of the RFC Editor to schedule work on referenced RFC-to-be based upon the queue position of the target RFC-to-be. For instance, the revised LDAP TS (over a dozen documents submitted over many months (years?)) was processed soon after the last normative reference was approved. But more important, if we would have published the early RFC-to-be as soon as the later RFC-to-be had been approved, we would have many bad section cites in these documents. This would have lead to significant reader confusion. The wait is not without purpose. I also do not support an experiment allowing Standard Track RFCs to normatively reference non-Standard Track RFCs (or other non-standard documents). I believe the RFC 3978 practice and the RFC 2026 variance process provides adequate means publishing documents with such references. I believe the RFC-to-be (the target) wait on another RFC-to-be is not so great as to risk that a change to a referenced RFC-to-be negatively impacts implementor of the target RFC-to-be. There is, I believe (based on my experience in making last minute changes to RFC-to-bes), significant risk. I also believe the wait is minimal. It appears the practice of the RFC Editor to schedule work on referenced RFC-to-be based upon the queue position of the target RFC-to-be. For instance, the revised LDAP TS (over a dozen documents submitted over many months (years?)) was processed soon after the last normative reference was approved. But more important, if we would have published the early RFC-to-be as soon as the later RFC-to-be had been approved, we would have many bad section cites in these documents. This would have lead to significant reader confusion. The wait is not without purpose. I also do not support an experiment allowing Standard Track RFCs to normatively reference non-Standard Track RFCs (or other non-standard documents). I believe the RFC 3978 practice and the RFC 2026 variance process provides adequate means publishing documents with such references. Regards, Kurt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
First, I think much of my concern is a due to having no clue what a user principal name is in the context of this draft. It seems to be some identifier used in some directory service. The only clue given in the document is that it is a name form defined by Microsoft. It is odd that there is no reference, not even an informative one, to this definition. As I am lacking clue, I doubt I can offer appropriate text provding the (necessary) clue that independent developers will need to produce an interoperable implementation. But I will, nevertheless, try in hopes it help you and other better understand my concerns. It will likely need to be reworked by the I-D authors based upon their understanding of what a UPN is. At 08:47 AM 3/22/2006, Russ Housley wrote: Kurt: Okay. I think I get your point. I'll try one more time, but if that does not satisfy you, then you will have to respond with proposed text. I'm trying to address Pasi's comment too. Based on updates from a previous comment, the document will say: The domain_name parameter, when specified, SHALL contain a domain name in the preferred name syntax, as specified by RFC 1123. I would suggest instead: The domain_name parameter, when specified, provides a DNS [RFC1034][RFC2181] host name [RFC1123] represented as an ASCII [ASCII] character string conforming to the domain production provided in Section 2.1 of [draft-zeilenga-ldap-cosine]. It is also noted that applications supporting Internationalized Domain Names SHALL use the ToASCII method [RFC3490] to produce label components of this domain production. I think that this resolves your concern about the encoding of domain_name. I propose the following text to handle the same concern for user_principal_name: The user_principal_name parameter, when specified, SHALL contain an Unicode UPN, encoded as a UTF-8 string. Now, for the rest: This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate. For instance, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that the server processes the user_principal_name with a stringprep profile [STRINGPREP] appropriate for the identity in question, such as Nameprep [NAMEPREP] for the portion domain portion of UPN and SASLprep [SASLPREP] for the user portion of the UPN. I note that SASLprep is case-insensitive and hence may not be appropriate for the user portion of a UPN. I note that Nameprep has to be applied component wise. I also think it odd to allow both toUnicode and toASCII domain component forms on the wire. The specification should choice one or the other (I recommend the latter). However, based in part with off line discussions with Stefan, I suggest. This document does not detail the syntax or semantics of a User Principal Name beyond that it is a string of UTF-8 encoded Unicode characters (with no required normalization) where at least of these characters is the COMMERCIAL AT (@ U+0040) character. The syntax and semantics of User Principal are application specific. It is expected that applications calling for the use of this extension detail these syntax and semantics. I note that I believe independent developers have near-zero chance of producing an interoperable implementation of this I-D (as is, or as modified by the various suggestions). The developer, it seems, has to depend on knowledge gained outside of this I-D. Regards, Kurt Russ At 10:04 AM 3/22/2006, Kurt D. Zeilenga wrote: At 12:03 AM 3/22/2006, Russ Housley wrote: Kurt: Would text like the following (which is largely stolen from draft-ietf-tls-psk) solve your concern: No. While the language does address part of the question: how/where canonical of the user_principal_name string is performed? it neither addresses this question: how/where canonical of the domain_name string is performed? nor address the question: what character set/encoding is used on the wire in transferring these character strings? I also suspect that the selection of SASLprep here, which is intended to be used for simple usernames and passwords, is appropriate for all of the user_principal_name string. My understanding is that the user_principal_name is composed of both a simple username part and a domain part. Components of the latter likely should instead be prepared by nameprep (if allowed to carry IDNA components). Also, as the user part of the user_principal_name is, it appears from casual examination of various MS documents, to be case insensitive, SASLprep should not be used. Kurt This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate. For instance, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that the server processes the user_principal_name
draft-santesson-tls-ume Last Call comment
I note the IETF last call was issued for rev. 2. That revision no longer exists, hence I reviewed rev. 3. This document specification of a User Principal Name, I believe, is inadequate. The I-D indicates that a user_principal_name is a sequence of 0 to 65535 bytes in the form of [EMAIL PROTECTED] However, such a form implies the value is a character string, but there is no mention of what character set/encoding is used here. I would think interoperability requires both client and server to have a common understand of what character set/encoding is to be used. Additionally, there is no discussion of UPN matching. Are byte sequences that differ only due to use of different Unicode normalizations to be consider the same or differ? Are values case sensitive or not? etc.. The domain_name field suffers not only from the above problem, but is flawed due to use of the outdated preferred name syntax of RFC 1034. This syntax doesn't allow domains such as 123.example. The text should likely reference the RFC 1123 which updates the preferred name syntax for naming hosts. Additionally, no mention of how International domain names (IDNs) are to be handled. I recommend ABNF be used to detail the syntax of each of these fields and that the I-D detail how values of these fields are to be compared. Additionally, the I-D should discuss how IDNs are to be handled. -- Kurt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protocol Action: 'LDAP: Internationalized String Preparation' to Proposed Standard
At 09:31 AM 1/26/2006, Frank Ellermann wrote: The IESG wrote: draft-ietf-ldapbis-strprep-07.txt as a Proposed Standard Mostly editorial nits: I will work with the RFC-Editor to address the editorial issues during AUTH48. As far as any non-Editorial issue, I suggest you bring it up with the responsible AD as any non-Editorial change at this stage would normally require his approval to make. Kurt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Vancouver schedule
At 10:27 AM 11/10/2005, RL 'Bob' Morgan wrote: As further support for doing lunch later, let me note that this week at least, most of the morning sessions I attended did not fill up their 2.5 hour allotment (of course there must have been others that did). So mornings with 2hour + 1hour or 2 1.5 hour sessions might be more generally useful More folks might get to lunch early if it was 1+2 rather than 2+1. Kurt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
My personal view (e.g., SASL chair hat off) is that CRAM-MD5 use on the Internet should be limited. It fails to provide any form of data security itself. The lack of integrity protection means sessions are subject to hijacking. While this inadequacy can be addressed by protecting the session with TLS, if TLS is used then it becomes a real toss-up between CRAM-MD5 and PLAIN. While CRAM-MD5 might be viewed by some as better, I note that PLAIN provides for better interoperability in systems involving external password stores (especially in face of string preparation requirements to be added in revisions of PLAIN and CRAM-MD5 specifications), and provides support for proxy authorization (identity assumption). It is my recommendation that the mandatory-to-implement strong authentication mechanism for this protocol be either: DIGEST-MD5 (with a mandate that implementations support its data security layers) TLS+PLAIN (with a recommendation that PLAIN not be used when TLS is not in use). I have slight preference for the latter. Kurt At 03:52 PM 6/8/2005, Sam Hartman wrote: Hi. I'm not in a good position to write a long response now; let me know if you do end up wanting a longer response and you'll get it in a week or so. I don't think cram-md5 is a reasonable best current practice. I think it is accurate to describe it as a common practice. It's my recollection that cram-md5 is vulnerable to man-in-the-middle attacks but digest-md5 is not. It's also my recollection that digest-md5 will do a much better job of supporting servers that do not want to store plaintext equivalents than cram-md5. The server will store a secret that is sufficient to log into that server but may not be sufficient to log into other servers. Digest-md5 also supports an integrity and confidentiality layer. I think all of the above are significant advantages over cram-md5. If you are concerned that digest-md5 is not sufficiently widely implemented then let's recommend plain+tls and digest-md5. I think those are two low-infrastructure protocols in wide use. ___ 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
An Organized Activity of the ISOC [resent]
Below is a (slightly augmented) version of my poll response. I note that I have not attempted to review the proposals in detail (I rather stay out of these weeds), but believe I understand the general gist of the scenarios. I view Scenario C as overly complex and risky. For instance, one cannot assume the newly formed corporation will achieve non-profit status in a timely manner (if at all). I view Scenario O as an natural evolution of our existing operation model. We are today an organized activity of the ISOC and would remain so. Scenario O appears to shifts certain activities from a service provider (CNRI/Foretec) to the ISOC and facilitates use of other service providers if and when that is deemed appropriate. I am far more willing to trust ISOC (based upon operational experience) than some new entity (which we have no operational experience with). For these reasons and more, I strongly prefer Scenario O over C. -- Kurt ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Naming crap (Re: IESG review of RFC Editor documents)
At 09:36 AM 3/27/2004, Harald Tveit Alvestrand wrote: That, I think, would be counter productive. I think it fairly apparent that there is a fair amount of crap (by mine, your, or anyone's opinion) published as RFCs. I content that much of that crap was produced by the IETF. permit me to disagree. not with your core statement, but with the statement that citing examples would be counterproductive. I was attempting to make a few points: 1) the series is not intended to be crap free 2) what is crap is quite subjective 3) we need to continue to allow others to publish what we might consider to be crap. which may have been missed by some. What I personally view as crap has no bearing in regards to these points, excepting that where I feel strong enough to produce an I-D detailing why I think something is crap I should be allowed (if I can met general editorial and technical standards) to publish that opinion as an RFC even though consensus of the IETF (or Keith's review board or the RFC Editor) might be that my opinion is crap. (That opinion could be expressed in the form of an alternative protocol specification.) The statement that a fair amount of crap is published as RFCs has been repeated for so long that it's almost become a mantra. Yes. But normally its uttered as an argument to increase publishing requirements. I am arguing that we should not increase publishing requirements here. However, in my opinion, for *every single one* of those RFCs, there's a reason why it was published. If we are to change the process that produces this stuff, we HAVE to understand what the reasons are that reasonable, competent people produce things that are sub-par, broken or crap. And IMHO, we can't do that without saying what these unacceptable results of the process are. Yes. I argue that we should not change the process (as described in RFC 2026) that produces this stuff as that process is producing acceptable results (e.g., the current level of crap is acceptable). Moving from the generic to the specific might actually be an useful catharsis for the community - and just might change the community opinion from a lot of our 3000 RFCs are crap to there are 30 bad RFCs, 300 that could have been better and 3000 reasonably OK ones, or even to the quality control system does not work well enough, there are too many borderline cases. It would be interesting to see how many of documents folks consider to be crap would have been blocked under a different process. If I look at the documents that stand out to me as crap, I note that Keith's new review process would have no impact... as most of the documents I consider to be crap were produced by the IETF or underwent some IETF review. But I'm not of the opinion that the documents I consider to be crap should have been blocked (though I might argue that some of them shouldn't be on the Standard Track). I don't think anonymous, class-based criticism will get us much further. We need to be specific about what our problems are. The problem I see with being specific here is that what's crap to me is not necessarily the same as to you, and we'll just end up arguing over wether something is crap or not, and that will overshadow the key aspect of my argument that we should each be allowed to own opinions as to what is crap and be able to act on those opinions, including publication of what others might consider to be crap. Kurt
Re: Naming crap (Re: IESG review of RFC Editor documents)
At 03:49 PM 3/27/2004, James Seng wrote: Sound nice but isn't this go against the rough consensus principle? The rough consensus principle applies to IETF documents, not to RFCs in general. You are free to doc your opinion (even if it is not rough consensus) in the mailing list. -James Seng What I personally view as crap has no bearing in regards to these points, excepting that where I feel strong enough to produce an I-D detailing why I think something is crap I should be allowed (if I can met general editorial and technical standards) to publish that opinion as an RFC even though consensus of the IETF (or Keith's review board or the RFC Editor) might be that my opinion is crap. (That opinion could be expressed in the form of an alternative protocol specification.)
Re: Naming crap (Re: IESG review of RFC Editor documents)
At 05:32 PM 3/27/2004, grenville armitage wrote: Kurt D. Zeilenga wrote: The problem I see with being specific here is that what's crap to me is not necessarily the same as to you, and we'll just end up arguing over wether something is crap or not, and that will overshadow the key aspect of my argument that we should each be allowed to own opinions as to what is crap and be able to act on those opinions, including publication of what others might consider to be crap. You do have avenues for publishing 'crap' outside the RFC series. Put your content up on a website. Send it to a mailing list. Shout it from the treetops. Yes, other avenues are available publishing independent works. However, it has been a long standard tradition of the RFC series to provide an avenue for publication of independent works (subject to minimal review). There is merit to the Internet technical community in this tradition as it combines opposing opinions into a single series of documents. I strongly believe that hindering the publication of individual submissions, as Keith suggests, will have long term negative impact upon the overall technical merit of the series. That is, you'll get want you seem to wish, individuals will go elsewhere. And I don't mean just in terms of publication avenues, but in terms of where and how Internet engineering is done. Your argument against improved expectations of standards in the RFC publication process seems unconvincing. Arguments that we should reenforce the false expectations of the quality and/or community acceptance of documents in the RFC series are unconvincing to me. We'll always have documents of different quality (including crap) and community acceptance (including none) in the series, we should focus more on how to distinguish the levels of quality and community acceptance. Attempting to restrict the series to those documents believed to be of high quality and broad community acceptance is simply infeasible (if not impossible). I see Vanity Press written all over it. Minimal review undertaken by the RFC Editor appears to be sufficient to address such concerns. Kurt
Comments regarding draft-iesg-rfced-documents-00.txt
I have read draft-iesg-rfced-documents-00.txt and generally support this change in the current practices. In review of background BCPs, in particular RFC 2026, I find this change can, and in my opinion, should be returning to the procedures outlined in RFC 2026. However, I do have some concerns (see below) and some editorial suggestions (which I will send separately to the I-D's authors). General support: It is my opinion that RFC 2026 did not intend for the IESG, nor the RFC Editor for that matter, to undertake a full scale technical review of the individual submission. RFC 2026 described the IESG review propose [t]o ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Internet Standards Process. RFC 2026 described the RFC Editor's review purpose as ensuring editorial suitability and subject to editorial considerations. While I support the RFC Editor continued right to refuse to publish a document which, in the expert opinion of the RFC Editor, is unrelated to Internet activity or falls below the technical and/or editorial standard for RFCs, we should continue the long standing tradition of allowing publication of alternative ideas, alternative protocols, and April Fool's RFCs. Concerns: I am concerned is the document by this Section 3 paragraph: Note that judging the technical merits of submissions, including considerations of possible harm to the Internet, will become solely the responsbility of the RFC Editor. The IESG assumes that the RFC Editor will create its own mechanisms for additional technical review. I argue that the RFC Editor should not refuse publication of a work because, in the opinion of the RFC Editor, that work would be harmful to the Internet. While I can see that cases where a document fails to met the technical standards of RFCs, a document that causes harm to the Internet does not necessarily below those technical standards. Determining whether a document would cause harm requires more detailed review than simply determining whether the document fails to met the technical standards of RFCs. Certainly the technical standard of RFCs (including those produced by the IETF) is, at times, quite low. Hence, I recommend the phrase including considerations of possible harm to the Internet be dropped or, better yet, this paragraph be replaced with language more consistent with that used in RFC 2026. Also, as the kind of harm discussed in section 5 is about confusion with standardization efforts, not about harm caused by technical flaws in the technical specification itself (as discussed in Section 3), the meaning of 'harmful' is confused in this document. Deleting the phrase as suggested above would remove that confusion and focus the issue on proper standards coordination and not in-depth technical review of the document. Kurt
Re: IESG review of RFC Editor documents
At 05:35 PM 3/26/2004, Eliot Lear wrote: Personally, I'm more concerned by WGs demanding their right to have their half-baked specifications published as RFCs, and the for IESG to approve them without any IETF review or other community review, or (as has happened in the past) even when substantial oversights or design flaws in those specifications were pointed out by individuals. Please cite an example. That, I think, would be counter productive. I think it fairly apparent that there is a fair amount of crap (by mine, your, or anyone's opinion) published as RFCs. I content that much of that crap was produced by the IETF. But my point, in regards to this proposal, is that the bar for Informational/Experimental is not half-baked nor won't cause harm nor crap, but whether it provides information is of reasonable use to the Internet technical community and meets the (low) editorial/technical standards for RFCs. Keith is trying to raise the bar. I prefer to keep the bar low. I, frankly, don't see a problem with there being more crap published as RFCs, whether produced by WGs or produced by individuals. In what case was there not a last call? WG documents submitted for Informational and Experimental publication are not necessarily subject to IETF Last Call. Also note that IESG review of such document is minimal (per RFC 2418). Kurt
Re: IESG review of RFC Editor documents
At 07:06 PM 3/26/2004, Keith Moore wrote: But my point, in regards to this proposal, is that the bar for Informational/Experimental is not half-baked nor won't cause harm nor crap, but whether it provides information is of reasonable use to the Internet technical community and meets the (low) editorial/technical standards for RFCs. For information to be of reasonable use it needs to be reasonably accurate. I disagree. A document which has significant technical errors and omissions can still be reasonable useful to the technical community. The document need only be meet general editorial and technical standards, it need not nor should be subjected to anything more than a minimal review (beyond that provided by its producers). Opinions can also be useful, if nothing else to students of history, if the opinions are clearly labeled as such, and if they help illustrate a historically important debate. I have no objection to labels (e.g., Experimental) and standardized disclaimers in such memos. These days, for a protocol specification to be of reasonable use on a wide scale it needs to avoid causing harm. Experimental and Informational memos need not be engineered for wide scale use. They might just detail an small scale experiment or detail an existing limited-use protocol. The standardized disclaimer should caution readers that the document may not be suitable for implementation/use on the Internet. There have been too many exploits of security holes and privacy holes in poorly-designed protocols. While it might be useful to publish an informational specification of a widely-deployed protocol on the theory that publishing it will make the public more aware of its limitations and help them migrate to better protocols, publishing a specification of a hazardous protocol that is not widely deployed can encourage wider deployment and increase the risk of harm. I consider this part of the Informational/Experimental v Standard Track trade-off. In having a series with minimal review, we accept risk that such documents will have not adequately address various considerations. Keith is trying to raise the bar. I prefer to keep the bar low. I, frankly, don't see a problem with there being more crap published as RFCs, whether produced by WGs or produced by individuals. Publishing crap dilutes the value of the RFC series, and makes it more difficult for the public to recognize the good work that IETF does. I agree that it hard to distinguish IETF-produced RFCs from individually-produced RFCs (this seems to be somewhat by design) and, I think, a separate issue from crap on the RFC series. The only distinction I see is that the IETF can produce (by WG or individual submission to it) crap on any track and Individuals can only produce crap on Informational/Experimental. While detailed review focused on the latter might reduce the latter, I don't see it nearly as problematic as the former. A certain amount of crap RFCs is to be expected and reasonable especially on Informational and Experimental tracks (regardless of producer). Minimal review has been, IMO, sufficient to keep the amount of crap to acceptable amount. It also costs money which could be better put to other uses. Personally, I believe the money spent doing minimal review is money well spent. However, I would be supportive of use of volunteer minimal reviewers to cut review costs. Kurt
UA893 divert images
A number of IETF'ers have asked me for copies of photos I took of our diversion to Seattle... http://www.openldap.org/ietf/59/divert1.jpg http://www.openldap.org/ietf/59/divert2.jpg These are ~1.5mb each (I'm too lazy to trim them down). Kurt
Re: IETF57 Wien WLAN readiness?
BTW, there is free wireless access in the Museum Quarter. Good beer, good food, and good bits. Kurt At 10:23 AM 7/11/2003, Pekka Savola wrote: Hi, As a lot of folks are coming to IETF57 early, it would be interesting to know when: - the WLAN network is estimated to be operational - when/whether it is possible to come to the conf. center (i.e. as it isn't in a hotel, is it open for IETF'ers e.g. on Saturday already) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Reminder: Deadline for input on sub-ip discussion
Option 2 grows the IESG by 1 to 2 ADs. I concur with sediments that this will likely make the IESG less effective, hence I oppose option 2. And as Option 3 has a high chance of becoming option 1 (become temporary things have a tendency to become permanent), I dislike it as well. I favor option 1. Kurt At 01:21 PM 12/9/2002, Harald Tveit Alvestrand wrote: All, On Wed Dec 4th, we asked for input to help us decide on the future of the SUB-IP Area. See our posting at http://www.ietf.org/mail-archive/ietf/Current/msg18370.html We had a large majority of people at the SUBIP Area meeting in Atlanta expressing that they want the area to be long(er) lived. This will be part of our input. But we need/want to hear from the IETF community. So please express your opionion (and the reasoning behind it) asap on [EMAIL PROTECTED], but certainly before Thursday Dec 12th 10am US Eastern time. As expressed in the above posting (with data points and discussion included), the 3 choices for the SUB-IP Area seem to be: 1/ move WGs (back) to permanent areas: migrate the SUB-IP working groups to other IETF areas sometime soon, likely before next summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs. 2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc effort, much as it has been, with the IESG selecting two sitting ADs to continue the effort that Bert Scott have been doing. But maybe give more responsibility to the working group's technical advisors, normally the AD from the area where the working group might otherwise live. The opinions expressed so far seem to show clearly that the community is divided on the issue, with perhaps some preference for the status quo (alternative 3). If you have a strong preference for one (or two) of these, and have not yet said so, please indicate your opinion (and your reasons) by mail to [EMAIL PROTECTED] before Thursday. Thank you! Harald Alvestrand, for the IESG (please repost this message where appropriate)
Re: namedroppers mismanagement, continued
At 04:26 AM 2002-11-26, Eliot Lear wrote: Were you one of those kids who had trouble following directions? Randy has given you a pretty plain solution that even my mother could follow (and my mother barely knows how to find the on button of a computer). Join the list already. How hard is that for a so-called mail guru? No. The list admin should add the unsubscribed address to the list of known email addresses. See item 5 in: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt Kurt
Re: namedroppers mismanagement, continued
At 11:10 AM 2002-11-26, Fred Baker wrote: At 07:39 AM 11/26/2002 -0800, Kurt D. Zeilenga wrote: The list admin should add the unsubscribed address to the list of known email addresses. See item 5 in: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt that's one of the list admin's options. But it turns out that many list admins consider adding a name to a list unbidden is impolite, and choose to not do this either, because they consider it error-prone and potentially insecure. I think it could be easily argued that manual approval process is far more error-prone than automated approval process and comes with the most of the same security and use issues you discuss. Anyways, if the admin really considers it impolite (I don't), then maybe that admin should send the user an opt-in (or opt-out) notice before (or after) adding the user to the pre-approved list of posters. (Note: for the subscribers list, the policy should be opt-in). This is easily automated (most list management software supports such). Is it so hard to do? echo '[EMAIL PROTECTED]' namedroppers.allowed-posters is not hard at all. Kurt
Re: namedroppers mismanagement, continued
At 01:43 PM 2002-11-26, Fred Baker wrote: At 11:57 AM 11/26/2002 -0800, Kurt D. Zeilenga wrote: Anyways, if the admin really considers it impolite (I don't), then maybe that admin should send the user an opt-in (or opt-out) notice before (or after) adding the user to the pre-approved list of posters. How does that differ from what was requested? Pre-approved lists continues to allow IETF'ers to post to IETF lists without having to be subscribed or suffer through the error-prone, distribution delay inducing, and list admin's time consuming processes some list admins have forced upon us. Kurt
Re: namedroppers mismanagement, continued
At 03:42 PM 2002-11-26, Randy Bush wrote: so my personal method is to let the user act on their own behalf and to respond to explicit written requests. Assuming this provides a means for the user can make an explicit request to opt-in to a list of known email addresses, great (DJB should opt-in). If not, why have you chosen not to implement guideline 5 in http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt? It seems to me that following this guideline would significant reduce the number of administrative errors and hopefully allow the community to re-focus on technical issues. Kurt
Re: namedroppers mismanagement, continued
At 04:48 PM 2002-11-26, Randy Bush wrote: Assuming this provides a means for the user can make an explicit request to opt-in to a list of known email addresses, great (DJB should opt-in). i think about 472 people have said that already. I took recent statements on this list as indicating that namedroppers used the senders address to determine what might be spam but didn't have a separate list of known email addresses which mail from is assumed to be non-spam. Thanks for clarifying that such a separate list does exist for namedroppers and that the user simply needs to explicitly request addition to it for his messages to be considered non-spam. Kurt
Re: LDAP info
At 08:48 PM 2002-06-13, Frank Ferrante wrote: http://www.umich.edu/~dirsvcs/ldap/doc/rfc/rfc1777.txthttp://www.umich.edu/~dirsvcs/ldap/doc/rfc/rfc1777.txt Ugh. Suggest you read LDAPv2 to Historic Status draft-zeilenga-ldapv2-02.txt. This I-D has been submitted for IESG consideration... been through IETF Last Call... and, hopefully, will be approved by the IESG soon. If you want to use LDAP, use LDAPv3 (RFC 2251-2256, 2829-2830). I recommend those interested in learning about LDAP start off by reading LDAP: Use as Directed by Tim Howes (co-creator of LDAP): http://www.networkmagazine.com/article/DCM2502S0039 For more general user information, I suggest you go to your favorite web search engine/catalog and enter LDAP. Frank - Original Message - From: mailto:[EMAIL PROTECTED]Maneesh_Sharma To: mailto:[EMAIL PROTECTED][EMAIL PROTECTED] Sent: Thursday, June 13, 2002 11:14 PM Subject: LDAP info Hi, does anybody have any document or can tell me a site where I can get the complete information regarding LDAP. I want to know the basics of LDAP. Any info in this regard will be very useful for me. Regards Maneesh Sharma Engineer Networking -- Networking And System Integration Group Satyam Computer Services Ltd. Chennai ( - (+91)-44-4314500 Extn: - 7632 * mailto:[EMAIL PROTECTED][EMAIL PROTECTED] Reach us at http://www.satyam.com/www.satyam.com -- ** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. **
Re: The IETF has no members ?
At 10:38 AM 2001-10-16, [EMAIL PROTECTED] wrote: Reread what Robert said -- there's a big difference between not having a well defined is a member of test and not having any members. If subscribed to a WG or other mailing list of the IETF, then is member of the IETF. (Yes, by this definition, lurkers are members. Most organizations have many members who are lurkers.) Any contributor to the IETF is effectively a member of it. Only a subset of the membership contribute to the IETF.
Re: Exception to MUST NOT
MUST NOT != NOT REQUIRED See RFC 2119, but basically: MUST NOT implies an absolute prohibition, not an optional requirement. Kurt At 11:56 PM 2001-09-19, Jiwoong Lee wrote: All, This is about the requirement level in the Internet specification. If a statement has the requirement level of 'MUST NOT' while it has an exceptional case, and while the exceptional case does not elucidate its requirement level, what is the appropriate requirement level of this exceptional case ? I guess the answer is 'MAY'. Are you agreeable to this ? I think ICMPv6 specification has the similar statements in it, regarding to the requirement level of the generation of ICMPv6 packet in response to a multicast packet or to a link local multicast packet. Jiwoong
RE: [ga] Fracturing the Internet
Seems NativeNames is confusing the MINC (http://www.minc.org/) for the IETF. "NativeNames' COO is chairing the Arabic Working Group under the IETF." (http://www.nativenames.net/english/corporate/affiliations.asp) NativeNames COO Jarallah Aljarallah is listed as the "interim chair" of the "Arabic Languages WG" of the MINC (http://www.minc.org/WG/arabic/charter.htm) Kurt At 10:57 AM 4/16/01 +1000, Dassa wrote: | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of | Patrick Corliss | Sent: Monday, April 16, 2001 10:21 AM | To: [GA] | Subject: [ga] Fracturing the Internet | | | Multilingual Top Level Domains | Available top level domains (TLD) in Arabic: | http://www.nativenames.net/english/whois/topleveldomains.asp | | Here's an example of an approach that may fracture the internet. From :http://www.nativenames.net/english/domains/policies/standards-warning .asp QUOTE NativeNames is among the first pioneers to enter the arena of multilingual domain names, and is among the first pioneers to support languages of the Middle East, including Arabic, Farsi, and Urdu. As with any pioneering efforts, there are dangers associated with being first. The most important one which you, the domain name registrant, need to be concerned about, is the evolution of standards regarding domain names. Until the standards get hammered out and are ratified, there is a chance of the same domain name being sold by different companies. Should that happen with a domain that you purchase through an affiliated registrar of NativeNames, NativeNames and that registrar will make every good faith effort - God willing - to return any prorated fees owed to you from the time of reporting to us of a problem for the remaining part of your registration term. Note that NativeNames, unlike many other registries, is virtually unique in warning potential buyers. We are deeply concerned about assuring you the best possible quality and service, and we appreciate your business. Please also note that we are actively pursuing avenues to minimize any potential problems. We are the first, and currently the only, registry that is focusing on Mideastern languages. We also hold a prominent role in the IETF's working group on Arabic domain names (in fact, our COO is the chair of that group). We will do our best to make sure that whoever you buy your domain name from, that domain name is yours God willing. End QUOTE Wouldn't the above in the last paragraph indicate a conflict of interest for being involved in this Registry and holding a chair in the IETF working group? Darryl (Dassa) Lynch.
Re: Deja Vu
At 03:25 PM 3/28/01 -0500, John Stracke wrote: Actually, I see what John means; for many Americans, London is pretty much an ideal foreign vacation. My wife thinks so... but she is really looking forward to Japan. But she has no plans on becoming being an IETF "tourist". :-) Kurt
Re: Deja Vu
At 10:26 PM 3/28/01 +0400, Baree Sunnyasi wrote: Could we have an idea of how much did a participant spend in Minneapolis ? Less the $1000 (excluding transportation and registration). 2/3 of that is hotel (6 nights).
Re: IETF logistics
At 03:15 PM 12/19/00 -0600, Timothy J. Salo wrote: What happened to the proven and time-honored technique of getting to a meeting early if you want a seat? Don't you mean a seat AND electrical power? :-) BTW, much thanks to Steve and his crew for providing a generous amount of electrical power outlets. As far as finding a seat for someone who has read all the materials for the session, that's what the front two rows are for. These rows should be open to others only after those who have read everything have had a chance to sit down. Note that the chance comes prior to start time of the meeting. Kurt
RE: Last Call: Tags for the Identification of Languages to BCP
At 03:52 PM 10/22/00 +0200, Harald Alvestrand wrote: What turned out in practice was that the most important part of RFC 1766 was the registration procedure, including the references to authoritative sources of tags (ISO 3166 and ISO 646). I agree that this is an important part. This clearly belongs in the BCP category, as do the registration procedures for charsets and MIME types; there is no meaningful way there can be more than one such document. I concur that the registration procedure belongs in the BCP category. The rest of the technical content, namely the syntax of tags (note that the Content-Language: header itself is moved to another draft, which WILL be standards-track) COULD have been moved to a THIRD document, standards-track, but this did not seem like the Right Thing to do; also, if published at Proposed, it would have required progression up the standards track before any referring document could progress. Did not seem right either. If the technical specification has significantly changed, yes, the issuing at Proposed is quite appropriate. Issuing at BCP allows for the technical specification to bypass the 3 step maturity process. Yes, this is a small technical specification, but what concerns me is the precedence set or extended by allowing BCPs to contain technical specifications used in standard track protocols. Kurt
RE: Last Call: Tags for the Identification of Languages to BCP
At 09:29 AM 10/21/00 +0200, Patrik Fältström wrote: At 15.44 -0700 00-10-20, Kurt D. Zeilenga wrote: At 03:12 PM 10/20/00 -0700, Dan Kohn wrote: This is the normal way standards progress through maturity, as otherwise issuing any new RFC would require dozens or hundreds of other RFCs to be simultaneously reissued. It would be normal if the RFC 1766 was being replaced by a standard track document. However, the proposal is to replace RFC 1766 with a BCP. This implies that RFC 1766 and all standard track documents with normative references to RFC 1766 will be moved to Historic status. No, it is perfectly ok for a document on standards track to reference a BCP, and therefore a document which is Proposed to be replaced by a BCP. Yes, I realize this (after all, 2119 is a BCP). I didn't voice my concern or the issue well. My concern here is that RFC 1766 provides a Standard Track Technical Specification and the proposal replaces it with BCP. These classifications are not equivalent. The real question is whether the Language Tags are appropriate classified as a practice or a Technical Specification. I believe the latter is more appropriate. Kurt
Re: Last Call: Tags for the Identification of Languages to BCP
At 10:23 AM 10/20/00 -0400, The IESG wrote: The IESG has received a request to consider Tags for the Identification of Languages draft-alvestrand-lang-tag-v2-05.txt as a BCP. This has been reviewed in the IETF but is not the product of an IETF Working Group. This document will obsolete RFC1766, currently a Proposed Standard. If RFC 1766 is obsoleted, wouldn't any Proposed Standard which has a normative reference to RFC 1766 also be obsolete? This would include RFC 2596 (Use of Language Codes in LDAP) and likely others. Has anyone a complete list of Standard Track RFC which have normative references to 1766? I believe that such is needed to judge the impact of the proposal. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by November 20, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-alvestrand-lang-tag-v2-05.txt
RE: Last Call: Tags for the Identification of Languages to BCP
At 03:12 PM 10/20/00 -0700, Dan Kohn wrote: This is the normal way standards progress through maturity, as otherwise issuing any new RFC would require dozens or hundreds of other RFCs to be simultaneously reissued. It would be normal if the RFC 1766 was being replaced by a standard track document. However, the proposal is to replace RFC 1766 with a BCP. This implies that RFC 1766 and all standard track documents with normative references to RFC 1766 will be moved to Historic status. Kurt
RE: Last Call: Tags for the Identification of Languages to BCP
I think the real issue here is whether or not the I-D describes a practice or is a technical specification. In my option, it is a technical specification of syntax and semantics of tags used to indicate language information in protocols (HTTP, LDAP, others), documents, and elsewhere. I believe technical specifications should be published either on the Standard Track, Informational, or Experimental. I'd prefer this I-D be considered for publication on the Standard Track. Kurt
Re: Standard Track dependencies on Informational RFCs
At 08:43 PM 8/31/00 -0400, Scott Bradner wrote: People seem to be focusing on the specifics of the case at hand Right, let's look at another case. RFC 1778 (Draft) "The String Representation of Standard (LDAPv2) Attribute Syntaxes" and RFC 2252 (Proposed) "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions" reference RFC 1278 (Informational) "A string encoding of Presentation Address". This Informational RFC is the normative specification of the Presentation Address which these Standard Track LDAP specifications reference. RFC 1278, though initially targeted for the Standard Track, the RFC was eventually approved as Informational. I believe the minutes of IESG/IAB indicate that RFC 2026, 7.1 was not meant to apply to RFC 1278. I do not believe it was appropriate for RFC 1778 nor 2252 to have referenced RFC 1278. Large portions of these LDAP syntax specifications should have published as Informational for the same reasons RFC 1278 was. Only those attribute syntaxes which the underlying protocol (RFC 1777, RFC 2251) require should have been defined on the Standard Track. I hope that LDAPbis can fix during our (proposed) LDAPv3 revision effort. Kurt --- relevant IESG/IAB meeting minutes (excerpts) --- IESG 91-08-29, 3.5.4 ``A string encoding of Presentation Address'' This document provides a string encoding of OSI presentation addresses, which is appropriate for use in human interactions, for humans to write on paper, and for human to machine interfacing. It is important to recognize that the encoding specified here is not intended for internal storage inside the directory system. Ross Callon and the author Steve Hardcastle-Kille agreed that this should be a standards track document. A long discussion ensued about the appropriateness of standardizing user interfaces and presentation formats. The IESG was generally of the belief that a human exchange format like RFC 822 addresses was needed, but it was not clear whether they should be explicit standards or just common practice. The specification of a single "common" format gained significant support, but no consensus was reached. Other groups are beginning to standardize presentation formats, including the Operational statistics group, which is working on standard maps and standards reports. No resolution was reached on the status of this document. ACTION: Vaudreuil -- Schedule a discussion on the appropriateness of standardizing presentation formats. IESG 91-09-19, 2.11) String Encoding of Presentation Addresses This recommendation was approved pending the insertion of text supplied by Phill Gross. This text describes the IESG position on the standardization of user interfaces. Further discussion is documented later in these minutes. Action: Vaudreuil -- Edit the recommendation to publish the String Encoding of Presentation Addresses document as a proposed standard and send to the IAB. Phill Gross's text on the standardization of user interfaces was a general purpose statement of IESG understanding. As such the IESG encouraged Phill to expand on the text with the intention of publication of this as an RFC. ACTION: Gross -- Elaborate on the User Interface Policy statement with the intention of publishing it as a RFC. IESG 91-10-17, 2) IAB Meeting Report (excerpt) Steve Hardcastle-Kille joined the IAB in discussing several of the X.500 documents. All were approved per the IESG recommendation except the "String Encoding of Presentation Address" which with the concurrence of Steve Hardcastle-Kille was suggested as an informational document. IAB, 911010, 5.2 Presentation Address Encoding The IAB was concerned that this appeared to be standardizing a user interface, and there were some strong feelings that as a general policy, standardizing user interfaces is a bad idea. Hardcastle-Kille agreed that this memo will have most of the desired effect as an Informational RFC, so it was agreed to publish it in this manner.
I-D no action period
I would like to propose the introduction of a "no action" period for Internet Drafts. Upon (re)publication of an I-D, no action (except removal) would be allowed upon the I-D for a short period of time (two weeks?). No LAST CALLs, no submission to AD, IESG, RFC-Editor, etc. This would allow the community a brief opportunity to point out any flaws in the revisions to responsible parties desiring to take action upon the I-D. I know of a number of cases where immediate action was taken upon I-Ds with significant flaws which were pointed out within days of the publication. A "no action" period would allow a small window of last minute community review. Kurt
Re: I-D no action period
At 12:12 PM 7/29/00 -0400, Bill Sommerfeld wrote: I would like to propose the introduction of a "no action" period for Internet Drafts. Upon (re)publication of an I-D, no action (except removal) would be allowed upon the I-D for a short period of time (two weeks?). No LAST CALLs, no submission to AD, IESG, RFC-Editor, etc. [trimmed...] A "no action" period would allow a small window of last minute community review. Isn't that what a last call is? A two-week window for last minute community review? The current process does not provide any mechanism for review by the community of any changes made based upon LAST CALL comments. That is, an individual makes comments which prompts changes. The community, let alone this individual, often are not given any opportunity to review the changes made.
Re: Where is the OID dot convention spelled out?
See RFC 1778, 2.15: Values of type objectIdentifierSyntax are encoded according to the following BNF: oid ::= descr | descr '.' numericoid | numericoid descr ::= keystring numericoid ::= numericstring | numericstring '.' numericoid In the above BNF, descr is the syntactic representation of an object descriptor. When encoding values of type objectIdentifierSyntax, the first encoding option should be used in preference to the second, which should be used in preference to the third wherever possible. That is, in encoding object identifiers, object descriptors (where assigned and known by the implementation) should be used in preference to numeric oids to the greatest extent possible. For example, in encoding the object identifier representing an organizationName, the descriptor "organizationName" is preferable to "ds.4.10", which is in turn preferable to the string "2.5.4.10". This was refined in RFC 2252, 4.1. In particular, it eliminates the "ds.4.10" form.
Re: Should IETF do more to fight computer crime?
rant We must be careful not to classify our efforts as preventing crime. Crime is matter of law and law is jurisdictional. As the Internet is crosses jurisdictional boundaries, there is not one clear definition of law and hence no clear definition of crime. And crime is not always bad. Some crime, such as civil disobedience to promote basic human rights, is good. I believe it appropriate to discuss such issues in the general context of security. We should continue to enumerate, discuss, and resolve security considerations. Though we might be driven by our own needs (hopefully well intended), protocols we develop can and will be used for both legal and illegal activities (regardless of our intent). The IETF should focus on providing technology to implement secure solutions irregardless of whether the solutions are used for legal or illegal activities. /rant Kurt
Re: [off-topic] ASN.1 links
You might also checkout these resources: http://www-sop.inria.fr/rodeo/personnel/hoschka/asn1.html http://asn1.elibel.tm.fr/ http://www.cs.columbia.edu/~hgs/internet/asn.1.html Also, "A Layman's Guide to ASN.1, BER, and DER" is available from RSA Security. ftp://ftp.rsasecurity.com/pub/pkcs/ascii/layman.asc (ASCII) ftp://ftp.rsasecurity.com/pub/pkcs/ps/layman.ps (PostScript) Peter Gutmann's X.509 Style Guide: "There seems to be a lot of confusion about how to implement and work with X.509 certificates, either because of ASN.1 encoding issues, or because vagueness in the relevant standards means people end up taking guesses at what some of the fields are supposed to look like. For this reason I've put together these guidelines to help in creating software to work with X.509 certificates, PKCS #10 certification requests, CRL's, and other ASN.1-encoded data types." http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt At 08:31 PM 5/19/00 +0100, Bruno Salgueiro wrote: Dear all, First of all sorry for this post but I'd like to know where are any good links around about ASN.1. This is of course important so that the ASN.1 structures used in the RFCs and drafts can be well understood and implemented. I could always download the specification from ITU but I'd like a more practical approach. Best regards and have a nice weekend. -- === Bruno Salgueiro (mailto:[EMAIL PROTECTED]) SIBS - Sociedade Interbancária de Serviços Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal Tel: + 351 21 791 88 33 Fax: + 351 21 794 24 40 http://www.sibs.pt Esta mensagem foi assinada com certificado MULTIcert. Para obter o certificado da Autoridade de Certificação PILOTO MULTIcert dirija-se ao site http://www.sibs.multicert.com "Computers are useless. They can only give you answers." --Pablo Picasso === Attachment Converted: "c:\home\kurt\data files\eudora\attach\smime.p7s"
product tags, vendor information in Internet protocols
A number of protocols/services expose product tags describing the vendor implementation for a variety purposes. These tags generally include the "vendor" and some "version" information and are often used by protocol peers to alter behavior. In some cases, like HTTP (RFC 2616), they may include vendor/version information of subsystems. I am looking for references to technical specifications, considerations, and discussions concerning the use of product tags in Internet protocols. I would also be interested in any published materials describing operational experience using (or abusing) such information. Please note that this message is not intended to start a discussion or debate concerning the use ( or abuse) of product tags, we've likely "been there, done that". So, please, just references to existing works. Regards, Kurt
Intended category of I-Ds
I believe the I-D guidelines should be revised to recommend authors include a statement indicating which RFC category the I-D is intended to be published in. This allows the reviewer to apply determine a level of scrutity based upon the intended category. I've come a cross a number of WG I-Ds which did not indicate their intended category AND the WG I-D didn't provide appropriate clarification. (Yes, I've brought this to the attention of the WG chairs and I-D authors). Comments?
RE: Intended category of I-Ds
At 11:41 AM 2/9/00 -0800, Cameron Young wrote: I've come a cross a number of WG I-Ds which did not indicate their intended category AND the WG I-D didn't provide appropriate clarification. (Yes, I've brought this to the attention of the WG chairs and I-D authors). I meant: I've come a cross a number of WG I-Ds which did not indicate their intended category AND the WG CHARTER didn't provide appropriate clarification.
