Re: Unsure of WLAN diagnosis (Re: Please make sure that you do not run your WLAN in ad hoc mode)

really going on, and if we don't do something official, well, there are some people out there who were pretty peeved in Vancouver... and when we're in *Texas*, there's no telling what they might do. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.r

Re: Vancouver schedule

sessions often end early anyway, so the extra session time is often wasted. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf

Re: WG Review: Domain Keys Identified Mail (dkim)

hey stay within the scope of the WG and do not get out of hand. I don't think that anything we say in the charter changes this; it is meant to provide a guide for resolving the ratholes and distractions. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.res

Re: WG Review: Domain Keys Identified Mail (dkim)

e to the first-quoted paragraph above, from the proposed charter, that keeps the sense that the specifications we're agreeing to use as a starting point be strong conflict-resolution guides, and that they be used to steer the discussion... without making it seem, incorrectly, that the WG is not

Re: WG Review: Domain Keys Identified Mail (dkim)

th. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

y you're fighting it. I think it will be better to fight it later, if necessary. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing

Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)

;d be entirely reasonable to recharter and attack these issues immediately after completing the first round of chartered work, if there are enough people who want to work on that. Or we can see how a while of deployment goes, and form another WG in a year or so to do it. Barry -- Barry L

Re: Alternative formats for IDs

a greater value of "just right"? Or am I missing something basic in the formatting changes you're looking at, at that stage? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _

Re: Alternative formats for IDs

27;ve reviewed it, I presume you're making stylistic changes that the RFC editor cares about that "we" didn't (if we did, we'd have already made those changes). I'm wonder what sorts of things those are, and whether they're really worth all the ext

Re: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt

nduly restrictive, without trying to limit things to utopian -- and non-existent -- lands of complete freedom. -- Barry Leiba ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: Blue Sheet Change Proposal

Olaf, with a cast on his right hand, says... > There may be reasons to contact participants after a meeting, being able to > tie > the name to an e-mail might be of value. I don't know what blue sheets *you* have looked at, but on the ones I've seen I'd say that most of the scrawling looks like

Re: IETF Chair tasks

> I'm not completely convinced that beer is the appropriate choice > in Montreal La Fin du Monde... or anything else by Unibroue. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.i

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

is. And I certainly don't see what this document should do about it. Barry -- Barry Leiba, STSM, Internet Messaging Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

secdir review of draft-garcia-simple-presence-dictionary-06

'>' signs, such as in ''." That should be "surrounded by". Throughout, all instances of "is comprised of" should be either "comprises" or "is composed of". The word "comprises" means "is composed of", and

SAVI BOF notes

Problem statement: IP source addresses can be spoofed. Packet delivery is based only on destination addresses, to the spoofed traffic arrives, and hurts (attacks/threatens) the destination. It'd be nice to stop the spoofing, and existing solutions aren't sufficient. There are product solutio

Re: SAVI BOF notes

Sorry; that got garbled by funny characters that came from copy/paste. Here it is again: Problem statement: IP source addresses can be spoofed. Packet delivery is based only on destination addresses, to the spoofed traffic arrives, and hurts (attacks/threatens) the destination. It'd be nice

Re: [RFC 3777 Update for Vacancies]

> > The draft that proposes changes to the RFC3777/BCP10 to deal with > vacancies is now available. > > http://tools.ietf.org/html/draft-ietf-genarea-bcp10upd-00 > > Two comments: 1 (nit): For vacancies due to death or resignation, no further action is required, to declare the seat vacant.

Re: [RFC 3777 Update for Vacancies]

> > > Where is "Extended Last Call" defined? There should be a citation > thither, or a definition here. > > RFC 2026 section 9.1 > >The proposed variance must detail the problem perceived, explain the >precise provision of this document which is causing the need for a >variance, and t

Re: [RFC 3777 Update for Vacancies]

> > a) To my reading RFC 3777 only deals with IAB and IESG membership RFC 4071 (BCP 101) specifies use of the 3777 recall process for the IAOC. > b) Neither this draft nor 3777 defines 'IETF body' Simply making Section 3.1 say 'the IAB, IESG, or IAOC ("an IETF body")' will take care of that.

Re: don't overthink, was Just so I'm clear

> > We're all agreed that the IETF in plenary mode (i.e. all of us) can change > any/all policy/procedures, right? ... > So if people all hum to OK all that, it has _just as much legitimacy_ as > _any other policy/procedure set into place by the IETF in plenary mode_. > Alas, that's not how we d

Re: [RFC 3777 Update for Vacancies]

Bob, Russ... repeating here what I said in the other thread, I suggest that... - the authors of draft-ietf-genarea-bcp10upd post an -01 version TODAY, incorporating comments received so far, - Russ, as Gen AD, immediately issue a formal (4 week) last call on that version, and - the document be

Re: Selection of a replacement IAOC member

> > it would appreciated if NomCom could determine: > > (a) Whether the appointed member is unable to serve the full two-year term > This is decidedly NOT something that any process empowers the NomCom chair to do. Matt could certainly give his opinion as an individual, but I can't see under wh

"IETF work is done on the mailing lists"

On Tue, Nov 27, 2012 at 12:25 PM, Dale R. Worley wrote: > >> That attendance showed me that most of the IETF meeting was a >> waste of time, that it was e-mail that was the main vehicle for work, >> and I think that the IETF web site has it about right when it says > > This is all true. Any decis

Re: When to adopt a draft as a WG doc (was RE: "IETF work is done on the mailing lists")

> we do not have adequate guidance for either WG chairs or participants on > when it is generally appropriate to adopt a draft as a WG document. ... > It seems to me that these variants are dependent on the people in the WG, > the workload of the group, the chairs, past precedent, AD preferences, e

Re: Barely literate minutes

On Wed, Nov 28, 2012 at 5:56 PM, Pete Resnick wrote: ... > chair needs to (with the help of minutes takers and other participants) post > detailed notes of the discussion to the list and ask for objections. That > serves two functions: (a) It makes a record of work that was done; and (b) > it give

Re: When to adopt a draft as a WG doc (was RE: "IETF work is done on the mailing lists")

> If we actively *don't* > want an IETF-wide procedure here, we can even document that the process > for WG adoption of drafts is WG-specific and could document those specifics > in a WG policies wiki document maintained by the chairs. I believe that one is the case, though others can weigh in wit

Re: When to adopt a draft as a WG doc (was RE: "IETF work is done on the mailing lists")

>> There is no formal process that involves "adopting" anything. > > If you mean that we haven't documented a/the formal process, you are > correct. If you mean that the IETF has not moved towards rather formal > steps for explicitly adopting working group drafts, I disagree. ... > Today, there is

Re: Idea for a process experiment to reward running code...

> [1] http://tools.ietf.org/id/draft-farrell-ft I have a serious problem with the premise of the proposal. The short version is that if the process we're talking about is useful, we should not shortcut it as a "reward" for anything. And if it's not useful, we should not be doing it, regardless o

Re: Idea for a process experiment to reward running code...

>> I have a serious problem with the premise of the proposal. >> >> The short version is that if the process we're talking about is >> useful, we should not shortcut it as a "reward" for anything. > > I disagree. The process is neither useful nor just a PITA. Its both, > depending on what document

Re: Idea for a process experiment to reward running code...

>> I, and I believe lots of us, do want to encourage running code >> more than now. This is one attempt to help with that. Why not >> try it and see? > > Because as a "reward" for claiming to have running code, I think it's > a terrible idea. As a way of handling the process for documents where >

Re: Idea for a process experiment to reward running code...

> But this doesn't do that for IETF LC at all! Everyone > not involved in the WG gets just the same notice as now. This is true. > What I hope is different is that drafts taking this optional > approach are higher quality, being based on running code. This is a stretch, and that *unprovable* ass

Re: Idea for a process experiment to reward running code...

>> Running code, when it's an organic part of the document development, >> is undoubtedly a good thing -- it doesn't make everything right, but, >> yes, it does do *some* spec validation and probably does help spec >> quality. > > Fully agree. And this kind of experiment may encourage that > good t

Re: Idea for a process experiment to reward running code...

Elwyn says... > However, I don't think that a short last call cycle need necessarily > compromise cross-area review. There has always been the possibility for > authors or wg chairs to request a early gen-art review with a view to > checking out whether something is in good shape cross-area and fo

Re: Idea for a process experiment to reward running code...

>> Do you really think it's likely that a chair who's trying to >> fast-track a document will likely go out asking for early GenART, >> SecDir, AppDir, and OpsDir reviews? >> > A few do already. But seriously, if the wg chair(s) actually have an > interest in the technology and feel there is a val

Re: Idea for a process experiment to reward running code...

> i think we're ratholing here. the point i get is that, if there is open > source code that suppliments the drafts sufficiently to lend confidence > in the implementability and implementation, then progress might be > accelerated. But the point of "running code" in our nice, catchy slogan, is th

Re: Last Call: (JSON Patch) to Proposed Standard

> Abstract >JSON Patch defines the media type "application/json-patch", a JSON >document structure for expressing a sequence of operations to apply >to a JSON document, suitable for use with the HTTP PATCH method. ... > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/ I'v

Re: Last Call: (JSON Patch) to Proposed Standard

> "add" has the semantics of "make the value *this*". Yeh, I guess the problem I have with that is that that's not the semantics most of us attach to the concept of "add a thing to a set". And it bothers me that "add to an object" and "add to an array" have different semantics. That difference is

Re: Last Call: (JSON Patch) to Proposed Standard

> So, do you have a suggestion? I do, and it's buried in there: >> Case 1 just seems wrong. The "add" in 1a should be an error, and then >> life would make sense. Turning that into a text suggestion, it would be this (which represents a change to the protocol, so the working group would have to

Re: Last Call: (JSON Patch) to Proposed Standard

> Personally -- to me, it seems like you're getting hung up on the word "add." ... > "add" means what the format definition says it means, because otherwise > we have to rationalise all of the different systems people might use it with > to make sense. OK, I'll buy that. Then let's take a differe

Re: Last Call: (JSON Patch) to Proposed Standard

Anyone have any comments on what I suggested below? Barry On Tue, Dec 11, 2012 at 11:25 PM, Barry Leiba wrote: >> Personally -- to me, it seems like you're getting hung up on the word "add." > ... >> "add" means what the format definition says i

Re: draft-ietf-appsawg-json-pointer-07 - array index for end ofarray

>> This was discussed in the Working Group, but it wasn't felt that the added >> complexity was worth it; there's a strong feeling that this spec should be as >> simple as possible. > > Might I suggest, however, using -1 instead of "-" to refer to the last item > in an > array, as this provides tw

Re: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC

I want to address one point that SM made: > "Additionally, the experiment will only require issues raised >during these three stages to be addressed if they meet the >IESG's Discuss criteria." > > Does this mean that a document does not have to represent consensus? This bothered me too:

Re: 3933 experiments (was: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC)

> IETF participants are unwilling or unable to > consider 3933 experiments. My second reaction was: what if draft-farrell-ft > was an IESG statement? Would the same outcome be reached? When Stephen proposed his draft to the IESG, I counter-proposed an IESG Statement that would essentially say th

Re: When is a 3933 experiment necessary? [Was: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC]

> We are a diverse community. Absent very, very strong consensus that a > problem is serious enough to warrant a change, the community is not likely > to line up automatically behind a proposal. We will always have some people > who prefer no change and some who offer their different, favori

Re: Last Call: (MPLS-TP Security Framework) to Informational RFC

> The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'MPLS-TP Security Framework' >as Informational RFC Some Last Call comments in advance of IESG Evaluation: -- Abstract -- This document is built on RFC5920 "MPLS and

Re: Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC

> The IESG has received a request from the Protocol to Access WS database > WG (paws) to consider the following document: > - 'Protocol to Access White Space (PAWS) Database: Use Cases and >Requirements' >as Informational > RFC Some Last Call comments, in advance of IESG Evaluation: -- Ge

Re: Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC

>> The IESG has received a request from the Protocol to Access WS database >> WG (paws) to consider the following document: >> - 'Protocol to Access White Space (PAWS) Database: Use Cases and >>Requirements' >>as Informational >> RFC > > Some Last Call comments, in advance of IESG Evaluatio

Re: Comments on draft-shafranovich-mime-sql-03

> The question is what happens when the SQL file itself carries no > charset information, such as when using "mysql-dump" with the > "--skip-set-charset" option. According to MYSQL, UTF-8 would be used > in v5.1+ and ASCII in versions prior to that. Perhaps, we should leave > "charset" as an option

Re: [mpls] Last Call: (MPLS-TP Security Framework) to Informational RFC

> Thank you very much for your review and detailed comments/suggestions, and > thanks for your discussion. > I uploaded the new version that addressed all your comments, as well as > Dan's Gen-ART review comments, and acknowledged your help. Thanks for the reply, Luyuan. I'm happy with all the re

Re: The RFC Acknowledgement

A couple of points here: >> In practice, that depends on the judgment the document author; does >> the document author feel that you have made a "significant" >> contribution to the document? > > I agree that it is responsibility of owners or authors. In IETF the > I-D may be a WG I-D so the group

Re: The RFC Acknowledgement

> SM, > (it is generally appreciated in the IETF to use real first and last name). Hi, Ulrich. This is actually a very cultural issue. I'll point out that in U.S. culture it's common for people named William to go by "Bill", or for people to regularly use nicknames such as "Bud" or "Woody". Do w

Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC

s, then SM's. I'm not, however, happy with how you spell my name. But I'll get over it. Barry LeiBa

Re: Showing support during IETF LC...

> Agree with what John, Brian, and others have said. FWIW, at times - > particularly > with documents having some controversy - the ADs are left wondering what the > silent majority is thinking. So in some cases the private messages to the AD > in > question or to the IESG are helpful. And while

Re: IETF 86 Admin Plenary Minutes

> http://www.ietf.org/proceedings/86/minutes/minutes-86-iesg-opsplenary > > Please review and comment. - Lorenzo Colitti was wondering what problem we are trying to solve: He looked at the IESG and they all look the same as the people in the audience. Is the

Re: IETF 86 Admin Plenary Minutes

> > Obviously not part of the basic note-taking effort, but I suggest that > IETF management groups explicitly consider the task of augmenting the notes > with published action items they are taking from the sessions. Along that line, I'll note the notes from the App Area chairs meeting, which we

Re: draft-sheffer-running-code-03 published

> we have just published a new revision of this draft, defining a new, > optional Implementation Status section to be included in Internet Drafts: > http://tools.ietf.org/html/draft-sheffer-running-code-03 It does look mostly ready, though I think the primary addition in -03, the recommended boile

Re: draft-sheffer-running-code-03 published

> Yes, we could do what you suggest, but as you found, it requires a kind of > meta-note to the RFC Editor that starts to get messy and confusing. I don't know: I don't think the meta-note is a problem. Perhaps you might pass it by Sandy and see if she thinks it's reasonable and understandable.

Re: Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

This dude's ready to ship. Thanks for addressing my earlier comments. Barry On Friday, April 12, 2013, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Improving Awareness of Running Code: the Implementation Status > Sec

Re: IETF Diversity Question on Berlin Registration?

Mike: > Actually, I don't think this is even a mostly correct statement - > that AD select chairs. Dave: It is a long-standing, simple, objective, unvarying management fact of IETF procedure: ADs hire and fire wg chairs. Mike: >>> The AD's do have the final say. No question.

Re: call for ideas: tail-heavy IETF process

> I would like to suggest that the IESG Review be done in public on the WG > mailing list.I've been a WG co-chair for just over a year now, and > I'm truly astounded by what happens behind the scenes. > > It's not the substance, it's the quantity, and the lack of WG view of > it. I think that

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

>> Putting arbitrary time limits on will hurry things up but it will not >> produce higher quality results. > > Ok, so do you agree, that if who holds the work, at least should tell > us HOW long he is holding or what is the time PLAN. Do you think > working without plan is efficient and gives good

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

Just on the writeup tooling question: > p.s. I've tried reading your shepherd writeup now in three > different browsers. It appears to be formatted for extremely > long (paragraph-length) lines, with no provision for automatic > wrapping to fit the page frame. That means that trying to read > an

Review of: draft-otis-dkim-harmful

> > > The draft continues to make broad, onerous claims like this, but > provides no documentation to indicate that the DKIM signing specification > is flawed in the function it is performing: attaching a validated domain > name to a message. > > DKIM does not, in its current form, attach a valida

Re: Review of: draft-otis-dkim-harmful

> > Of course it is incorrect for a DKIM signature to be valid when a message > has multiple From header fields. DKIM requires AT LEAST the From header > field to be the minimal portion of the message signed. Every other part of > the message is optional. > In retrospect, I think that requiremen

Re: Content-free Last Call comments

Without agreeing with or disagreeing with Pete, I'll point out that Pete was talking about IETF last call. It's perfectly reasonable for a WG participant who has been actively involved to say, "This one is ready. Ship it," and Pete isn't saying otherwise. In that case there is context that helps

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

> > -- Why does this need to be published as an IETF stream RFC? If I > understand correctly, this documents an existing protocol as implemented by > commercial products. I agree with Martin's comment that there is value in > publishing this sort of thing, but I applaud the Adobe and the author fo

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

> you're not the first person to be confused by that construct. i will change > instances of > "MUST ONLY" to "is allowed only if" (or similar) and remove the definition > for "MUST > ONLY" from Section 1.2. I think this is an excellent idea. RFC 6919 aside (ahem), it's rarely a good idea to tr

Re: SHOULD and RECOMMENDED (was: Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07)

> > I believe that it would be wise to discourage > "RECOMMENDED" and "NOT RECOMMENDED" as synonyms for "SHOULD" and > "SHOULD NOT" unless they are clearly necessary to avoid awkward > sentences and the non-A/S intent is completely clear. > A fine suggestion, with which I agree. Barry

Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard

en the IETF has seen a collection or succession of proposals aimed at extending a protocol, it has opted to charter a working group to coordinate those proposals, winnow them, and establish community consensus on which to standardize, and how. It should do that here, as well. Barry Leiba __

Re: Nomcom Enhancements: Improving the IETF leadership selection process

sus of a relatively small but significant and experienced group of people... about a minimal set of changes that we think are important. We're not proposing vast changes and cumbersome new processes. We're going for simplicity, in order to address some of the points of most concern. Barry Leiba ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

BoingBoing: TCP, IP, and TCP/IP headers constructed in LEGOs

This crowd will appreciate this: http://www.boingboing.net/2010/07/21/tcp-ip-and-tcpip-hea.html -- Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Varying meeting venue -- why?

> I think Vancouver would be an excellent city for a recurring North American > meeting.  There is a reasonable convenience factor in terms of nearby > hotels, restuarants and food markets (there's an excellent one just a couple > blocks from the venue).  However, based on the poll, it seemed that

Re: secdir review of draft-saintandre-tls-server-id-check-09

Hi, Peter. Thanks for the response, and I'm very happy with nearly all the changes you've adopted. I'll not quote and comment on it all, except to make the general statement: Great work! >> I'd also like to take the security note from section 4.3 and echo it >> here.  So maybe this?: >> >> << Th

Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09

>> Tangent: I know we want to avoid implementations that do foolish things >> being claimed as compliant, but IMO, the requirement that input come >> from a "human user" is goofy for a technical specification and in >> practice a non-starter.  A web browser that followed a HTTP redirection >> to a

Re: Discussion of draft-hardie-advance-mechanics-00.txt

> A periodic call for comments, say at  2 and 5 years out, with those > judged to be still useful moving up the ladder, > for example? > > I understand that "objection based processing" was not the most polite > way to word this in my draft, > and I'm sufficiently chastened to change it in the next

Re: draft-housley-two-maturity-levels

> I'd like to hear from the community about pushing forward with this > proposal or dropping it. I see disagreement with the proposal, but we'll see disagreement with any proposal. I see enough support to continue pursuing it, in my opinion, and trying to find a balancing point that enough of us

Re: draft-housley-two-maturity-levels

Scott, I'm confused about one thing you say: On Tue, Oct 26, 2010 at 8:41 AM, Scott O. Bradner wrote: > I think the community should only change its processes with careful > deliberation > taking into account the interplay of the different factors ... > I think it is better to not fiddle, even i

Re: Proposed WG and BOF Scheduling Experiment

>> Hmm. How many non-overlapping time slots? It would be extremely >> frustrating if there was a lot of overlap between BOFs. Some of us >> are interested in almost any new topic. My first reaction is to prefer >> the BOFs spread out. I'm not sure that concentrating them will reduce >> the problem

Re: Automatically updated Table of Contents with Nroff

># empty out toc.input >> toc.input ># run once to get a sample ToC, but page numbers will be off >nroff file > /dev/null 2> toc.input ># run again to get proper page numbers into toc.input >nroff file > /dev/null 2> toc.input ># run a 3rd time to get the right output, ignor

Re: Automatically updated Table of Contents with Nroff

>> Clarifying: the reason why I'm researching is that apparently some >> people think it would be good to have a replacement for xml2rfc.tcl that >> *emits* nroff (only - as opposed to plain text/nroff/html as the TCL >> code does today). > > Though I happen to like nroff  (I also like anchovies) p

Re: Last Call: (Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)) to Proposed Standard

I'm sorry not to have posted this during WGLC, but I didn't notice it until now: The document uses the phrase "are advised [to do something]" in two places (the penultimate paragraph in Section 4.3, and the beginning of Appendix D). I suggest that we either switch to 2119 language ("SHOULD [do so

Re: conformance languages (issue 278), was: Last Call: (Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)) to Proposed Stan

> I agree that this needs tuning; but I'd rather not invent a new keyword for > that. Sensible. > The appendix D > () > isn't meant to be normative; thus I believe leaving it the way it is ought > to be ok. O

Re: Request for review of draft-yevstifeyev-genarea-historic-03

> I agree with you that it is really hard and even impossible to determine > what is going on in the Internet regarding some technology, protocol, etc. > If we set the impossible criterion for the Historic documents, this will > really make very few sense.  So, as I have been pointed out, I find re

Re: IAOC: delegating ex-officio responsibility

Good; I've been suggesting this for some time also. >   The IETF chair, the IAB chair, and the ISOC President/CEO may >   delegate their responsibilities to other persons.  The delegations by >   the IETF chair and the IAB chair need to be confirmed by the IESG and >   IAB respectively.  The terms

Re: IAOC: delegating ex-officio responsibility

> I'm very concerned about the IETF Chair getting decoupled > from the IAOC. The IETF Chair's job is a whole lot more than being > IESG Chair, and some degree of personal responsibility for oversight of > the administrative work seems to me to be appropriate. > > So I'm not at all sure this delegat

Re: IAOC: delegating ex-officio responsibility

I agree with Henk's modification -- in fact, my brain read it into it already, which is why I didn't say it too. The delegation should only be allowed to another member of the delegator's body. > I think you mean: > >  The delegation is for an one year term, aligned with the IAB and IESG >  appoi

Re: IAOC: delegating ex-officio responsibility

> I was not assuming that delegation was limited to another member of the same > NomCom-reviewed body. One case was that you might delegate to a > NomCom-reviewed member who then leaves the NomCom-reviewed body. If the > NomCom-reviewed chair and the NomCom-reviewed body were OK with that person >

Re: Last Call: (IANA Procedures for Maintaining the Timezone Database) to BCP

This document is ready to go, modulo some nits. Herein, my list of nits: General Because you define the terms, you should use them consistently. Please check for "Coordinator" (replace with "TZ Coordinator") and "TZ list" (replace with "TZ mailing list"). Sec 1.0 OLD The TZ mailing list wou

Re: draft-housley-two-maturity-levels-06

> This suggests that perhaps we should rename "Proposed Standard" to > "Not a Standard But Might Be One Later," promote the PS published > under the overstrict rules to DS, and we're done. > > I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop cal

Re: draft-housley-two-maturity-levels-06

John said... > Well, you know, the "Not a Standard But Might Be One Later" really are > requesting comments. Yes, well, we all know that "RFC" has lost any real sense of its expansion long ago. It certainly has done so in the eyes of most of the world, for whom "RFC" means "Internet standard". D

Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP

>>> What is "cron?" and how does it interface with the originator defined as >>> the MSA?  is cron an MTA or MUA? ... > It was a rhetorical question.  I don't think its necessary and IMO, > unprecedented. I'd be very surprised to find that mention of "cron" in an RFC is "unprecedented". Maybe I'l

Re: Last Call: (DKIM And Mailing Lists) to BCP

On Thu, May 12, 2011 at 8:38 PM, John Levine wrote: > I'd suggest publishing it as Informational or Experimental rather than > BCP. As DKIM chair, I'd like to reply to this and other messages in this thread that discuss the status of the subject document: There was extensive discussion in the DK

Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP

>> As chair, I can say that consensus was to make this normative, not >> experimental. > > With the best will in the world, I was there, and I saw no such consensus. We discussed it live at IETF 80, and I posted the following minutes to the mailing list on 28 March: 3. Discussion of mailinglists

Re: Proposed text for IESG Handling of Historic Status

>> My understanding is that any RFC can be moved to Historic. But if this >> is not clear from RFC 2026, maybe it is worth clarifying. > > If 2026 doesn't limit what types of RFCs can become Historic, then I presume > any of them can.  I'm not sure we need to make that explicit. I'm sure we don't.

Re: New Non-WG Mailing List: fun -- FUture home Networking (FUN)

>>> Purpose: Mailing list for proposed working group on FUture >>> home Networking (FUN) >> >> And nothing more (same thing on the Web site). Could we ask >> for a little bit more context when a new IETF list is created? > > I think asking is perfectly reasonable.  But I also think we > should trus

Re: [apps-discuss] Last Call: (Terminology Used in Internationalization in the IETF) to BCP

On Thu, Jun 16, 2011 at 11:21 PM, Mykyta Yevstifeyev wrote: > I have an only concern with regard to this document which I expressed > before, during WG discussions, and which I'd like to bring to IESG's > attention now. > > For a number of times I proposed improving the "control character" > defin

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

> More substantively, I fail to understand how this specification > proposes to create a class of "reserved" about: URIs when the about: > scheme seems to be internal information to an application.  I think > the Security Considerations section doesn't address any of that, and > probably ought to,

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

>    Barry> internally, and, therefore, has no interoperability >    Barry> requirements.  As best I can tell, the issue here is to let > > It does.  It's an RFC1918-type use, and for the same reason we had to > document those networks, we have to document this URI. > This document prevents someone

Re: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

To add chair support to Murray's comment: On Wed, Jun 22, 2011 at 13:17, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of >> Douglas Otis >> Sent: Tuesday, June 21, 2011 6:51 PM >

Re: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

> This document obsoletes RFC 4871 for which there is an IPR disclosure ( > http://datatracker.ietf.org/ipr/1547/ ).  As this is a move from Proposed to > Draft, is a new IPR disclosure required? The disclosure you cite *is* the new one, which applies to the 4871bis draft (disclosure 1547 updates

  1   2   3   >