Re: tools everywhere

John C Klensin wrote: > To me, the obvious simple solution to this is to keep one link > -- either as a bookmark or in my head -- that points to a list > of tools. My solution is a collection of my favourite tools on a public page . That turned out to be a go

Re: Experimental track

Brian E Carpenter wrote: > pretty clearly a cut-and-paste error. I agree that we > can't expect non-participants to correct that error. +1 For a definition of "non-participant" somewhere between "did not yet read RFC 4677" and "did not yet read all RFCs listed in ion-procdoc" (including 3669

Experimental track (was: Non-participants)

Dan Riley wrote: > there is some evidence that people presumably well versed in > IETF process and RFC2026 terminology can be sloppy in its > application--from > http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg04120.html [...] >| The IESG solicits final comments on whether the I

Re: About referenced documents...

Randy Presuhn wrote: [Tom Yu wrote] >> My understanding is that the Open Group / SUS standards are supposed >> to be technically and textually identical to the IEEE 1003.x >> standards, or at least, a strict superset thereof. If someone has >> evidence to the contrary, I would like to know abou

Re: 2026, draft, full, etc.

Brian E Carpenter wrote: > Comments on draft-carpenter-rfc2026-changes-01.txt are welcome. | Formally abolishing the now pointless "STD 1" RFCs. NAK - I hope we get a new STD 1 soon, ideally after 4234bis got its STD number. | The IETF will not normally modify protocols developed elsewhere,

Re: Non-participants

Ned Freed wrote: > the FSF site basically said "write in and voice your opposition to > the publication of tls-authz" and did not mention actually reviewing > the specification, it seems reasonable to be skeptical. Yes. That's of course not the same as dismissing all contributions in this thread

Re: DOS

Hallam-Baker, Phillip wrote: > You are reminded of MARID? Yes. And also of the http://noooxml.org/ petition where I violated my own "never sign any online petition if you don't get a backlink" rule. > That was the last time RMS had one of these write in campaigns. > That then led to a count

Re: Megatron

Harald Alvestrand wrote: > I do think that one reason why letter-writing campaigns against the > IETF have been rare is that it's hard to argue that people who care > *shouldn't* subscribe to the relevant mailing lists at least for the > duration of the discussion - which means that they get copie

DOS (was: Experimental makes sense for tls-authz)

Brian E Carpenter wrote: > The DOS attack on this list seems to be from people who haven't > read RFC 2026 and use meaningless phrases like "experimental > standard." What was it, 30 messages collected by Megatron over eight days ? FYI 36 offers a def

Megatron (was: TLS-authz)

Apparently Megatron put a bunch of messages on hold for eight days, compare : | Original-Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) | by megatron.ietf.org with esmtp (Exim 4.43) | id 1IlT12-0002lZ-Jq; Fri, 26 Oct 2007 13:3

Re: A priori IPR choices

Theodore Tso wrote: [BOCU-1] > Can someone give an example of someone who has requested > a license but not received one, please? Apparently somebody tried and got no answer, compare > http://www-03.ibm.com/linux/opensource/ispinfo.

FYI 28 (was: A priori IPR choices)

Philippe Verdy wrote: > We do have lots of informational RFCs which are still needed and > actively used, sometimes even required (notably those in the BCP > series, like the "Netiquette" which has become a requirement for > almost all ISP customers, as part of their contract, despite they > are o

Re: A priori IPR choices

Simon Josefsson wrote: > I would even consider a requirement that in order to move beyond > Proposed Standard, a protocol needs to have a free implementation > available. Tricky, e.g. my BOCU-1 implementation is "free" in a certain sense, but I'm also sure that I don't have a license. Thanks f

Re: A priori IPR choices

Sam Hartman wrote on the general list: > I'd like to write in general support of re-evaluating several aspects > of our patent policy. I'm not quite writing in support of rechartering > IPR at this time. First, I think they have critical copyright work to > finish. +1 > Second, I think that we

Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP

Stephane Bortzmeyer wrote: > A typical example is RFC 4646 for its registry. (4646bis, under > work, will no longer need it.) s/will/might/ until the Chairs dare claim "rough consensus"... > So, no need for lengthy flames :-) ...I kept it short ;-) For another example see the EAI DSN draft. >

Re: TMDA backscatter

Douglas Otis wrote: >> In theory IANA could publish one _spf.arpa "v=spf1 mx a -all" >> record, and everybody could use it with "v=spf1 redirect=_spf.arpa". >> That one SPF record can (kind of) reference an unlimited number of >> MX records doesn't depend on SPF's local-part macro. > This

Re: TMDA backscatter

Douglas Otis wrote: > By using the local-part in a spam campaign, one cached SPF record > is able to reference an unlimited sequence of MX records. In theory IANA could publish one _spf.arpa "v=spf1 mx a -all" record, and everybody could use it with "v=spf1 redirect=_spf.arpa". That one SPF

Re: TMDA backscatter

Douglas Otis wrote: > Macro expansion and text strings can be combined with any SPF record > mechanism and CIDR mask. Any email-address differing in just the > local-part must then be iteratively processed across the SPF record > set (up to 10 follow-on SPF records or mechanisms). Yes, an attack

Re: TMDA backscatter

Douglas Otis wrote: > Due to the macro nature of SPF, full processing is required for > each name evaluated. If what you call "full processing" is the procedure to fetch the policy record of the domain in question, and match the connecting IP against this policy for a PASS / FAIL / "DUNNO" verdi

Re: TMDA backscatter

Douglas Otis wrote: > There is a real risk SPF might be used as basis for acceptance You can combine white lists with SPF PASS as with DKIM "PASS", the risk is very similar. > Much of the danger of auto responses has to do with DDoS > concerns. It depends on the definition of "DDoS". From

Re: Spammers answering TMDA Queries

SM wrote: > Spam can pass SPF, Sender-ID and are even DK and DKIM signed > nowadays. One can't blame spammers for not being early adopters. :-) > TMDA may cause backscatter. After an SPF PASS the "backscatter" by definition can't hit an innocent bystander. By the same definition any "backscat

Re: Last Call: draft-saintandre-jabberid (The Jabber-ID Header Field) to Proposed Standard

Peter Saint-Andre wrote: > Eric Allman wrote: >> I don't see any reason why a new proposed standard should allow >> obsolete syntax (specifically, obs-FWS in section 2). > Another reviewer pointed that out as well. As a result, in my > working copy I have changed that to: > "Jabber-ID:" [FWS]

Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0

John C Klensin wrote: > Ned Freed wrote: [...] >> To the extent RFC 1345 is problematic, it is because its domain >> of applicability is quite limited. But within that narrow >> domain it actually can perform a useful function. > Agreed. And perhaps that suggests a way forward if people are > w

Re: Use of LWSP in ABNF -- consensus call

John C Klensin wrote: > LWSP AtLeastOneRequiredThing CRLF > or > [ LWSP optional-stuff ] CRLF > I don't see either of the latter as problematic. Depends on the protocol. Your constructs match SP CRLF SP CRLF SP AtLeastOneRequiredThing CRLF SP CRLF SP CRLF SP optional-stuff C

Re: Last Call: draft-ietf-radext-rfc4590bis (RADIUS Extension for Digest Authentication) to Proposed Standard

The IESG wrote: > The IESG has received a request from the RADIUS EXTensions WG (radext) > to consider the following document: > - 'RADIUS Extension for Digest Authentication ' > as a Proposed Standard Hi, this draft might be also interesting for the 2831bis (SASL) and 2617bis (HTTP-AUTH) fo

Re: Use of LWSP in ABNF -- consensus call

John C Klensin wrote: > I would have no problems adding a comment to any construction > (including built-in productions) in ABNF that has proven > dangerous warning people that they should understand it and > its consequences before they use it. That's the intention of the proposed "security cons

Re: Design of metalanguages

John C Klensin wrote: > From my point of view, the IETF made its decision around ten > years ago and it is questionable whether the decision then > could sensibly have departed significantly from the definition > is RFC 822. While I didn't like the decision then and don't > like it now (perhaps t

Re: Use of LWSP in ABNF -- consensus call

Lisa Dusseault wrote: > The issue was initially raised by Frank Hi, a short explanation, initially I hoped that 4234 can be promoted to STD "as is". I missed the (now listed) errata in the "pending errata mbox". Some months later 4234bis-00 was posted, and if 4234 can't be promoted as is, then

Re: IAOC Communications Plan: Review Requested

Simon Josefsson wrote: > I'm not sure it automatically imply that there are any indexes, > a log of who made what changes when, or a search function, etc. Some wikis offer a revision history and a search function, e.g. most openspf.org pages are based on a Wiki, which is a fork of "Usemod". That

Re: IAOC Communications Plan: Review Requested

Ray Pelletier wrote: > The Plan can be found at > http://www1.tools.ietf.org/group/iaoc/wiki/CommsPlan This results in an emtpy page with my browser. Trying to fix it locally I've removed all lines from 221 to 430 right before , , , , , and elements at the end, see http://validator.w3.org for t

Re: I-D ACTION:draft-crocker-rfc4234bis-00.txt

[EMAIL PROTECTED] wrote: > http://www.ietf.org/internet-drafts/draft-crocker-rfc4234bis-00.txt The security considerations say: | Security is truly believed to be irrelevant to this document. I propose to add the following paragraph: Authors intending to use the LWSP (linear white space) con

Re: message for ietf-announce: search engine for IETF and IRTF mailing list archives

Lars Eggert wrote: > it indexes all currently-active WG and RG mailing list archives I think it's a proper or favoured subset (selected by you) of what's anyway in Google's index, specified in the form of "URL patterns" for inclusion or exclusion. In the most simple form you'd say ietf.org resul

Re: ADs speaking for "their" WGs

Brian E Carpenter wrote: > It seems fairly clear in RFC 2418 section 6.1: >|"The Chair has the responsibility and the authority to make decisions, >| on behalf of the working group, regarding all matters of working >| group process and staffing, in conformance with the rules of the >| IETF. The A

ADs speaking for "their" WGs (was: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68)

Spencer Dawkins wrote: > - what we tell the WG chairs is that ADs have the power to make a decision > for the working group, in order to break a deadlock. Jeff Schiller (one of > the ADs who did the WG chair training for several years) was very clear > that an AD can say, "if you guys don't make a

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

Sam Hartman wrote: > I propose to conduct a last call to confirm that we don't > have consensus to publish as a proposed standard. Does > this seem like the right approach to folks? Did that ever happen before ? A Last Call trying to get consensus that there's no consensus. If "silence means

Re: Last Call Comments on draft-housley-tls-authz-07

EKR wrote: [RAND] > Reasonable And Non-Discriminatory. Thanks also to Dan and Clint, apparently I confused it with "RANDZ". The rule to expand acronyms on first usage in RFCs is really good for me... :-) Frank ___ Ietf mailing list Ietf@ietf.org h

Re: Last Call Comments on draft-housley-tls-authz-07

Eric Rescorla wrote: > The listed terms are RAND but not necessarily royalty-free. Doesn't RAND mean "Royalty-free And Non-Discriminatory" ? I tried "define:RAND" at Google, but didn't get that one. Frank ___ Ietf mailing list Ietf@ietf.org https://

Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP

Jeffrey Hutzelman wrote: > while I don't think the document necessarily needs to be changed to > REQUIRE this, I think it would be good if last call announcements > continued to call out normative downrefs, for two reasons: > (1) To make it easier to catch potentially problematic downrefs > (2)

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

Brian E Carpenter wrote: >> "send publication request to secretariat" is more attractive >> than spamming ADs. > You probably need to understand what happens when someone > does that. Yes, I haven't tested it yet. > The Secretariat simply forwards the note to the IESG. Don't they also set the

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

Jari Arkko wrote: > And as Brian noted, if this someone misuses their power for > personal reasons or some other reason, we have an appeals > process. I'm not sure there's fundamentally any other way > to handle this. Nor me. Forcing them to either vote "Yes" for a document they don't really lik

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

Jari Arkko wrote: > I would be happy to sponsor a ternary bit draft, but only on > April 1 :-) "IETF replaces 'bits' by 'tits', [EMAIL PROTECTED]", it could be a case where April 1st is no good excuse. What I don't like in your draft is the (apparent) personal veto right for the AD. Authors (ho

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

Jari Arkko wrote: > please complain! That was the complaint, the draft is from an IESG POV, and it explains how to deal with confused authors claiming that a single bit is enough to count to three or similar cases. But it doesn't address the POV of authors who want to get an evaluation of their

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

John C Klensin wrote: > If the IESG intends this document to merely represent the > particular procedures they intend to follow within the range of > alternatives over which they believe they have discretion, then > it should probably be published as an ION Not publishing it at all is an alternat

Re: ietf-moms

Paul Hoffman wrote: > there was little contribution in San Diego, but this sounds like > a good opportunity to see if folks can find and edit the wiki. I found it but couldn't edit it, so that question is IMO answered. Frank ___ Ietf mailing list Ie

Re: ion-procdocs open for public comment

Brian E Carpenter wrote: >> I liked the I-D better, the xml2rfc HTML output is hard to read. > Really? I find the links in the HTML version invaluable. Me too, but I prefer the "rfcmarkup" HTML version of the I-D, for starters it uses a monospaced font, it doesn't spice the output with characte

Re: ion-procdocs open for public comment

Brian Carpenter wrote: > http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html I liked the I-D better, the xml2rfc HTML output is hard to read. For an ION you could probably remove the dummy chapters 3 and 4. Frank ___ Ietf mailing list Iet

Re: FW: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP

C. M. Heard wrote: > The draft is intended to do the same thing for RFC 4181 > that RFC 4748 did for RFC 3978. Comments, if any, should > be directed to . Now that you ask, your patches are straight forward, so why not simply apply them and publish a complete new 4181bis ? Patchwork RFCs are IM

Re: Last Call: draft-siemborski-rfc2554bis (SMTP Service Extension for Authentication) to Proposed Standard

Lisa Dusseault wrote: > are we looking at the same version of this doc? No, the last called is -07, it doesn't REQUIRE [DIGEST-MD5] anymore: | Note that many existing client and server implementations implement | CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to insure interoperability | with depl

Re: Last Call: draft-ietf-lemonade-deployments (Deployment Considerations for lemonade-compliant Mobile Email) to BCP

Jeffrey Hutzelman wrote: > handled by the RFC-Editor Yes, while I was at it I simply noted all observations. ['exist a number of' vs. 'exists a number of'] > the original text is correct Now that you say it, I read this recently: http://www.askoxford.com/asktheexperts/faq/aboutgrammar/numbero

Re: Last Call: draft-ietf-lemonade-deployments (Deployment Considerations for lemonade-compliant Mobile Email) to BCP

The IESG wrote: > as a BCP s/marjup/markup/ How about s/HTTP/HTTP or better HTTPS/ somewhere in 4 ? s/exist a large number/exists a large number/ in 8 (?) Please expand the first use of DMZ - I didn't know the abbreviation - but of course Google found it for me ;-) FWIW, I like that I-D

Re: Identifying mailing list for discussion

Harald Alvestrand wrote: > I think all I-Ds should have this - both the first ones and the last ones. Ideally the announcement would be also sent to this list, if it's a "known" IETF list (including the "other lists"), and the submitter identified a list for this purpose. Just mentioning a list

Re: addressing Last Call comments

John C Klensin wrote: > The IESG may well have made the right decision here s/may well have/certainly has/ I think it's a bug that I-D.iab-publication-00.txt offers no list for public Last Call comments. IMO the rare Last Calls for I-Ds published by the IAB could also use this list here for pub

Re: Tracking resolution of DISCUSSes

Henrik Levkowetz wrote: >> Hi, do you mean s/Chair/AD/ here ? > No. The way I see it, Shepherd 'write' rights would be a subset of the > Chair rights, which will be a subset of the AD rights. Why should WG Chairs - if they're not proto-shepherds - have write access on the I-D tracker at all ?

Re: Tracking resolution of DISCUSSes

Henrik Levkowetz wrote: > It is possible that the simplest resolution in cases where the shepherd > is not a chair is to give the shepherd the same access rights as a chair. Hi, do you mean s/Chair/AD/ here ? Frank ___ Ietf mailing list Ietf@ietf.

Re: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC

Markus Hofmann wrote: > The intend of publishing this document before dissolving the WG is to > have the discussion on how the IAB considerations apply to OPES/SMTP > written down, in case individual contributors might pick-up the > OPES/SMTP work later on (although we don't have indication this m

Re: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC

Ted Hardie wrote: > I don't think adding explicit interactions with DKIM is appropriate > for this document, If OPES sees the complete message (header + body) it could be used as signer (conceptually somewhere between MSA and mailout) or verifier (between MX and MDA, if it has DNS access). That'

Re: Tracking resolution of DISCUSSes

Adrian Farrel wrote: > 3. Are notes to the RFC Editor inserted in the I-D tracker? >I certainly haven't seen them there in the past. It's at the end of the "IESG evaluation record". There you'll find a draft of the approval announcement, and that contains Note to RFC editor + IESG note + IAN

Re: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC

The IESG wrote: > as an Informational RFC The "bypass" construct apparently includes what's also known as "challenge response scheme". If that's the case it's net abuse, unless the challenge is guaranteed to be sent to the originator. The only relevant case where that's guaranteed I'm aware o

Re: ion-ion-format open for public comment

Julian Reschke wrote: > Such as with > ? I can't tell, is there an online XSLT engine somewhere to test it ? When I'm able to use IE 6 I'm normally too busy for experiments :-( Frank _

Re: draft status links on the wg pages?

Dave Crocker wrote: > minor enhancement: Put a link to that page on the working group's > main IETF page. There's a link to the Charter, isn't that the old main page ? > A working group's main page really is its home page and, therefore, > ought to bring together references to all relevant inf

Re: ion-ion-format open for public comment

Julian Reschke wrote: > IMHO it would be a good idea in the sense of "own dogfood" not to > serve XHTML content with media type text/html. Matter of taste, from my POV XHTML 1.0 transitional is the best way to create backwards compatible (HTML 3.2) content "visible with any browser". Or as the

Re: ion-ion-format open for public comment

Brian Carpenter wrote: > Please see > http://www.ietf.org/IESG/content/ions/drafts/ion-ion-format.txt It says "text or html", but ion-ion-store is perfectly valid XHTML. Is that a problem ? The HTML output of xml2rfc is rather ugly with my browser, and its nice unpaginated output doesn't offer

Re: Something better than DNS?

John L wrote: > There are both technical issues and non-technical issues. [...] BTW, I liked your "travel-sitefinder" statement on behalf of ALAC. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: SRV records considered dubious

Hallam-Baker, Phillip wrote: > The draft is in the repository, it was posted to the DNSEXT list in June. > http://www.ietf.org/internet-drafts/draft-hallambaker-dkimpolicy-00.txt Oops, I still had that as I-D.hallambaker-pcon-00.txt in my "repository", the drafts are otherwise identical: http:/

Re: *.ppt slides

Rebecca Bunch wrote: > All PowerPoint slides are converted to HTML Thanks. > For the impatient yet theologically pure No theologoy on my part, just an old box with very limited HD space and an old OS/2. As soon as the HTML version is availble I like ppt better than similar but monstrous PDFs.

Re: *.ppt slides

Brian E Carpenter wrote: > after the staff get home and take a well-deserved rest. Thanks, I wasn't sure if that was done before or after the meeting the last time when I looked at HTML slide shows - and in one of the "usual" places I found only files up to March 2006, and worried if that service

*.ppt slides

Hi, will the *.ppt slides be converted again to *.html ? Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: How confidential is the information we share with the Nomcom?

Lakshminath Dondeti wrote: > The way I see it though is that the process and the mechanisms > were not discussed within the community. Conventional wisdom > says that security protocols/mechanisms designed without proper > peer review tend to be broken. A few people I have spoken to > seem to th

Re: How confidential is the information we share with the Nomcom?

Lakshminath Dondeti wrote: > It might be worthwhile for the community to know the feedback > is known to > * the voting members of the nomcom > * nomcom current and past year's chair > * the 3 liaison members > * the tools team (some of them are IETF contributors) > * whoever maintains the nom

Re: draft-iesg-discuss-criteria

John C Klensin wrote: > I don't think that "at most 2 NO" is, or should be, dependent on > the number of IESG members. Certainly not "is" in the DISCUSS draft, I wondered about "should". Somebody (thanks!) told me off list that I got "(current 9)" wrong, it's not the size of the IESG last year,

Re: draft-iesg-discuss-criteria

Jeffrey Hutzelman wrote: > You are confusing the normal balloting process with the alternative one. s/confusing/comparing/ - assuming that "yes + no objection" end up as "yes", and "discuss + abstain" as "no". Skipping Brian's "R" to get 14 ballots. > there is no reason to assume that someone w

draft-iesg-discuss-criteria (was: [...] DISCUSS: draft-carpenter-rescind-3683)

Sam Hartman wrote: > I'm going to last call the draft again. The "discuss" was about -02, the new "last call" will be about -03, here's a tiny URL for a diff: The iesg-discuss-criteria-02 I-D could be updated, it expired two months ago, and there's apparently a bug

Re: Last Call: 'Extensible Provisioning Protocol (EPP)' toDraftStandard (draft-hollenbeck-epp-rfc3730bis)

Hollenbeck, Scott wrote: [3339] > There's more to it than "just promote it". An implementation and interoperability report about it could be hila^Wlaborious... > I don't really need two normative references that specify the > same thing ...okay, maybe you have just lost year "AD", good ri

Re: draft-kolkman-appeal-support

Sam Hartman wrote: > I think the SPF and Sender ID appeals clearly had merit. One decision said "we have found merit", and the other said "we thank"... > I'm not sure whether we rejected them though. ...the latter was in essence accepted, and the former also had some effect, together resulting

Re: Last Call: 'Extensible Provisioning Protocol (EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis)

Hollenbeck, Scott wrote: > RFC 3339 (Date and Time on the Internet: Timestamps) > Referenced by: draft-hollenbeck-epp-rfc3730bis-03, > draft-hollenbeck-epp-rfc3731bis-04, draft-hollenbeck-epp-rfc3732bis-03, > draft-hollenbeck-epp-rfc3733bis-04 > This reference is sited to capture a format that is

Re: draft-kolkman-appeal-support

Harald Alvestrand wrote: > - "No problem, here's the pointer to my CV, here's 5 people who know > both of us personally, if you need a copy of my driver's license just > send me the fax number to send it to, what else can I do to help?" That "no problem" is a problem. If I manage to create a JPG

Re: draft-kolkman-appeal-support

Harald Alvestrand wrote: > 9/10 of all drafts are trashed by the quite effective mechanism > of waiting 6 months... no need for dramatic action. Depends, that 3710-thingy was quite spicy, and all I know about "cancels" in the tools.ietf.org archive is that it's possible. > - supporters are d

Re: draft-kolkman-appeal-support

David W. Hankins wrote: > The definitions in Olafur's draft for qualified supporters > shouldn't be considered exclusionary. That's precisely how I understand them, and it's not hard to guess which cases this tries to address. It's also not hard to guess which _unrelated_ 3.5 appeals I have in m

Re: DNS pollution

Olaf M. Kolkman wrote: > I think it may be a good idea to also create an IAB document that > documents all these DNS issues that have to do with namespace tricks. > The IAB comment on Sitefinder [1] could act as the core of that > document. I'd be happy to work with a few volunteers to make that f

Re: DNS pollution

Keith Moore wrote: > this is fraud and unfair trade practice in addition to being a security > threat (as people give their passwords when trying to connect to the > wrong site) and harmful to applications (either because they do connect > to a protocol engine on the wrong server, or they try to c

Re: Proceeding CDs

IETF Administrative Director wrote: > Is there strong rationale for maintaining production of the CDs? No opinion - but on a related issue: Some slide shows are very interesting, and the HTML output of Powerpoint is *_MUCH_* better than huge PDFs. Frank _

Re: Suggestion for IETF Critical Infrastructrei WG.

todd glassey wrote: > Any commentary? For me it sounds like a proposal to reinvent the IAB as WG. Some draft-iab-whatever and resulting RFCs like 4690 are quite interesting, examples: draft-iab-auth-mech-05 draft-iab-dns-choices-03 draft-iab-dos-05 draft-iab-messaging-report-01 That they tolera

Re: As Promised, an attempt at 2026bis

John C Klensin wrote: > Just my opinion. +1 Deprecating RFC 2026 section by section until nothing is left, or the rest is simple, is a good strategy. Brian's "dispute" I-D would eliminate another big part of RFC 2026. Paul's updates of RFC 1738 together with RFCs 3986 and 2396 are an example h

Re: As Promised, an attempt at 2026bis

Eliot Lear wrote: > we will find another list for this purpose. Please consider to pick an existing list like pesci or newtrk or similar, creating new lists for everything is just bad. > 2026 must be revised and not merely updated Your points (4) to (7) sound good, but not (1) to (3). I've n

Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)

Stig Venaas wrote: > In the context of this draft, the term domain suffix is not > meant to be just the TLD. If "domain suffix" generally means, > or is thought of as, just the TLD, then the draft should use > some other term instead. The term is okay if you mention that it's supposed to be one o

Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)

Fred Baker wrote: ["domain suffix"] > It is the new-speak for use when all us ancient geeky types > would prefer "TLD". I thought it's some new kind of DHCP builtin DynDNS service. If it's a TLD I'm perplexed why that would ever change for a given DHCP server. And for clients of different serv

Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)

The IESG wrote: > as a Proposed Standard What's a "domain suffix" ? I don't see or missed it in 3315 and 4361. LDH labels with a TLD maybe ? Are they guaranteed to be "valid" in some ways, could a host "name" send mail as "name.suffix" ? Could it use "@name.suffix" in Message-IDs ? Does the

Re: Comments on draft-dusseault-caldav-15 and draft-newman-i18n-comparator-14

Lisa Dusseault wrote: > one could define a Very Liberal Comparator (VLC) for general > use. It would be handy to have one which matched e with E, > é, è É... and matched o with O, ø, ô, and so on. Good idea. I'm thinking of something in that direction for my mail filters: At the moment any ty

Re: Newtrk and ISDs

Fred Baker wrote: > For your amusement: Thanks, I like that "munging agent" in RFC 886: > 16 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1980s.txt Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: RFC/Protocol Quantification

Sreevathsa wrote: > something like, 93% of TCP implementation on this server is > in agreement with RFC 793 and 7% of it is not! Ticky, who cares about 80% if it works, or 99% if it doesn't ? > components that I was thinking about are: > 1. Packet structure > 2. Query format > 3. State transit

Re: Facts, please, not handwaving

Jefsey_Morfin wrote: > The Internet has dramatically increased this to the point we > have accepted it as a virtual and a global world, i.e. a > conceptual and geographical equivalent coverage to reality. > The IETF is therefore in the core of this But not alone, googlebot, wikipedia, and some ot

Re: Specifying a state machine: ASCII-based languages

Stewart Bryant wrote: > invent our own from scratch? Stephane's draft has 22 pages, including two non-trivial examples. SDL has abstract data types and other features. For something that's better than ASCII art or some ad-hoc table formats squeezed into RFCs his format is okay. It should be fa

Constant flux (was: Why cant the IETF embrace an open Election Process [...])

todd glassey wrote: > was this existence of the IPR or IETF WG disclosed to anyone There is no "IETF WG", this is the general list of the general area. And yes, somebody told me where to post IPR WG related issues when I tried it here. > is there anything on the Website that talks about the > G

Re: what happened to newtrk?

John C Klensin wrote: [skipping many good points] > I am very much in favor of high specification quality. [...] > we should aspire to specifications that are absolutely clear > about their strengths and weaknesses _especially_ where > security and basic network operations (e.g., scalability) are

Re: RFC 2195 (Was: what happened to newtrk?)

Christian Huitema wrote: > yes, DIGEST-MD5 has essentially the same issue. If the SASL folks want their very own "decruft" experiment they'd have to update RFCs 2244, 2645, 3013 (a BCP), check ESMTPA in 3848, do something about 2617, and probably some more RFCs. DIGEST-MD5 and OTP are regist

Re: RFC 2195 (Was: what happened to newtrk?)

Christian Huitema wrote: > http://www.huitema.net/talks/ietf63-security.ppt Thanks, with that hint I finally found the HTML version: http://www3.ietf.org/proceedings/05aug/slides/apparea-4/ and http://www3.ietf.org/proceedings/05aug/slides/plenaryt-1.pdf >> With a somewhat unusual password I wou

Re: RFC 2195 (Was: what happened to newtrk?)

Jeffrey Hutzelman wrote: > A thinly veiled description of an actual situation is not a > hypothetical. Okay, pick a better adjective, I tried to make the point that there is a pattern in these real examples: A technology where only experts know how it works, while users get the choice OK or CANC

Re: RFC 2195 (Was: what happened to newtrk?)

Christian Huitema wrote: > both Steve Bellovin and I presented the issues with such > techniques. Is that presentation online available somewhere ? I find the way to http://www3.ietf.org/proceedings/05aug/index.html but then I'm lost. > Basic challenge response mechanisms like CRAM-MD5 are simp

Re: RFC 2195 (Was: what happened to newtrk?)

Jeffrey Hutzelman wrote: > Multiple interoperable implementations is not the [only] > criteria for advancement; it is necessary but not > sufficient 2026 says "mature, useful, well-understood, stable." A downref to SASLprep for a 2195bis DS would be odd, in that case better publish 2195bis as PS

Re: RFC 2195

Kurt D. Zeilenga wrote: > implementations of RFC 2195 suffer from interoperability > problems due to its failure to specify a character > set/encoding The challenge has the syntactical form of an RFC 822 msg-id. The concepts of userid and password are the business of the application. All CRAM-D

<    1   2   3   4   5   6   >