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 wo

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 implementat

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.

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 Trac

RE: draft-santesson-tls-ume Last Call comment

ious 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

RE: draft-santesson-tls-ume Last Call comment

question, such as SASLprep >[SASLPREP]. > >Russ > >At 12:19 PM 3/21/2006, Kurt D. Zeilenga wrote: >>At 11:06 AM 3/21/2006, Stefan Santesson wrote: >>>Kurt, >>> >>>I've spent some time over this topic with Russ Housley and Paul Hoffman >>>h

RE: draft-santesson-tls-ume Last Call comment

der to map the hint to an account. > >There reference will be fixed (or removed). > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > >> -Original Message- >> From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] >> Sent: den 7 mars

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 PROTECT

Re: Protocol Action: 'LDAP: Internationalized String Preparation' to Proposed Standard

At 09:31 AM 1/26/2006, Frank Ellermann wrote: >The IESG wrote: >> 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-Editoria

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

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

At 10:43 PM 6/9/2005, Frank Ellermann wrote: >And if they don't like CRAM-MD5 what they'll get is LOGIN or >PLAIN _without_ TLS, sigh. I disagree with this statement. Today, many email client and server supports TLS, and does so independently of what SASL mechanisms they may or may not support.

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 wit

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 a

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

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

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

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

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 >>su

Re: IESG review of RFC Editor documents

At 04:41 PM 3/26/2004, Keith Moore wrote: >What I have a problem with is individuals demanding the right to have their >half-baked specifications published as RFCs, and for the RFC Editor to publish those >documents as RFCs without public review, or (as has happened in the past) even when >subst

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

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 interestin

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

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 indica

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-i

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 use

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-polic

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

Re: LDAP info

At 08:48 PM 2002-06-13, Frank Ferrante wrote: > >http://www.umich.edu/~dirsvcs/ldap/doc/rfc/rfc1777.txt > Ugh. Suggest you read "LDAPv2 to Historic Status" . This I-D has been submitted for IESG consideration... been through IETF Last Ca

Re: postings to ietf mailing lists

At 05:31 AM 2002-06-12, [EMAIL PROTECTED] wrote: >i have noticed that some ietf working groups don't anymore allow >postings except from addresses that have subscribed to the list. The IESG has made two statements which are applicable here: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy

Re: RFC2119 Keywords

At 11:39 PM 2002-02-14, [EMAIL PROTECTED] wrote: > The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be > interpreted as described in RFC 2119. > > >So I'd say "if you mean the 2119 meaning, use ALL CAPS". I

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 defini

RE: [ga] Fracturing the Internet

At 08:17 PM 4/15/01 -0500, Andy Gardner wrote: >At 10:57 am +1000 4/16/01, Dassa wrote: >>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? > >This whole mess is one gigantic conflict of i

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

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: 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: 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 powe

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 clear

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 o

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 t

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 docum

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 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

Re: An Internet Draft as reference material

I, for one, would like to see the IETF host an public archive of expired I-Ds for technical reasons. Having past works, even those not worthy of RFC publication (on any track), available adds to wealth of knowledge available to future Internet engineering. This will allow future efforts to take

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

Re: Standard Track dependencies on Informational RFCs

So, it looks like MD5 and HMAC are "Other Specifications" for which the IESG has requested to be published as Informational RFCs such that they can be referenced by Standard Track specifications (per RFC 2026 7.1.2). I found references to this affect in the minutes of the IESG (excerpts provided

Standard Track dependencies on Informational RFCs

As part of the LDAPbis BOF effort, I have gone through the RFCs defining LDAPv3 (RFC2251-56,2829-31) to identify normative references. To my surprise, I found a number of clearly normative references to Informational RFCs. Per RFC 2026 maturity requirements for Standard Track specifications, thes

Re: LDAPbis I-D Review Session @ IETF#48

As a number of the I-D authors are not be available to discuss their I-Ds, the session is cancelled. At 09:35 AM 8/3/00 -0400, Kurt D. Zeilenga wrote: >LDAPbis - LDAP (v3) Revision BOF, I-D Review > >Those interested in reviewing suggested changes and other >technical issues re

LDAPbis I-D Review Session @ IETF#48

LDAPbis - LDAP (v3) Revision BOF, I-D Review Those interested in reviewing suggested changes and other technical issues related to the LDAPbis effort are invited to attend "LDAPbis I-D Review Session". When? 1530-1730 Where? South 3 What? RFC 2251-2256,2829,2830 draft-armijo-ldap-contro

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

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

LDAP (v3) Revision BOF (LDAPbis)

This is the final IETF#48 LDAPbis BOF agenda. Those interested are encouraged to attend. Regards, Kurt --- cut here --- NAME: LDAP (v3) Revision BOF ACRONYM: LDAPbis CHAIRS: Kurt Zeilenga <[EMAIL PROTECTED]> RL "Bob" Morgan <[EMAIL PROTECTED]> MAILING LIST: Archives: http://www.openldap

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: ::= | '.' | ::= ::= | '.' In the above BNF, is the syntactic representation of an object descriptor. When encoding values of type objectIde

Re: Should IETF do more to fight computer crime?

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,

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/

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 v

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

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 wh