Re: year for highest number of IETF participants
On 10/7/2013 8:03 PM, Aaron Yi DING wrote: Thanks for the pointer from Ray Pelletier. It seems IETF-49 got the highest number - 2810. 2nd is IETF-46, 2379. For those wondering where to see a list of attendees by meeting, see http://www.ietf.org/meeting/past.html Tony Hansen
Re: ORCID - unique identifiers for contributors
On 9/18/2013 8:45 AM, Andy Mabbett wrote: On 17 September 2013 21:10, Tony Hansen t...@att.com wrote: Very few people use the uri element in the author block. (I count zero in the currently extant internet-drafts XML files.) Its intended use really is for the author to put in whatever URI they care to that helps identify them. Its usage is directly parallel to a person's postal, fax and email addresse. So plugging an ORCID into the URI element seems to fit that usage perfectly. What address block? Please refer to the listing of my name in RFC 6350; noting that I am not listed as an author. Hmmm, I just re-read your original message to ietf@ietf.org. What I had originally taken as a complaint about getting a way to have a unique id (in this case, an ORCID) for the authors was instead a complaint about getting a unique id for the people listed in the acknowledgements. I can't say I have a solution for that one. Tony Hansen
Re: ORCID - unique identifiers for contributors
On 9/17/2013 8:07 AM, Melinda Shore wrote: I'm not sure much needs to be done other than talking with Heather Flanagan (the RFC Editor), getting her sign-off, and then getting it into the xml2rfc schema and noting its existence. What would the ORCID reference look like? My understanding is that it would look like this: http://orcid.org/-0003-0437- Very few people use the uri element in the author block. (I count zero in the currently extant internet-drafts XML files.) Its intended use really is for the author to put in whatever URI they care to that helps identify them. Its usage is directly parallel to a person's postal, fax and email addresse. So plugging an ORCID into the URI element seems to fit that usage perfectly. Tony Hansen
AppsDir review of draft-ietf-repute-model-08
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-repute-model-08 Title: A Model for Reputation Reporting Reviewer: Tony Hansen Review Date: 2013-08-29 IESG Telechat Date: 9/12 IETF Last Call Expires: LC for 07 expired on 2013-08-29, but 08 superseded that Summary: The document is ready for publication. Minor notes follow that can be fixed in AUTH48. The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to achieve, 2) the meaning of messages transmitted, and 3) important unobvious features of the protocol. This document accomplishes its goals quite well. ORGANIZATIONAL COMMENT Section 3 High-Level Architecture starts with an extended example of where a reputation service would fit into an existing service. Finally, more than a page later, it starts describing the architecture that is supposed to be the topic of this section. I suggest that the section be split into two, with the beginning given the heading along the lines of Example of a Reputation Service Being Used, and the High-Level Architecture heading moved right before the paragraph that starts This document outlines. Alternatively, add subsection titles. MINOR NITS Changes below are marked with . Section 1, paragraph 5 starting with A full trust I think this sentence would read better as follows, both for readability and to match the style of the surrounding sentences: OLD: Some need only produce a basic rating, while others need to provide OLD: underlying detail. NEW: Some need to only produce a basic rating, while others need to provide NEW: the underlying detail. Section 2, paragraph 1 starting with The basic premise I think this sentence would read better with the introduction some additional punctuation. OLD: Typically client and service operators enter into OLD: some kind of agreement during which some parameters are exchanged OLD: such as the location at which the reputation service can be reached, OLD: the nature of the reputation data being offered, possibly some client OLD: authentication details, and the like. NEW: Typically client and service operators enter into NEW: some kind of agreement during which some parameters are exchanged, NEW: such as: the location at which the reputation service can be reached, NEW: the nature of the reputation data being offered, possibly some client NEW: authentication details, and the like. Section 3, paragraph 5 starting with It provides I think there is a typo in this sentence and the word one should be done. OLD: (Although not typically thought of as a 'transport', the DNS OLD: provides generic capabilities and can be thought of as a mechanism OLD: for transporting queries and responses that have nothing to do with OLD: Internet addresses, such as is one with a DNS BlockList [DNSBL http://tools.ietf.org/html/draft-ietf-repute-model-08#ref-DNSBL].) NEW: (Although not typically thought of as a 'transport', the DNS NEW: provides generic capabilities and can be thought of as a mechanism NEW: for transporting queries and responses that have nothing to do with NEW: Internet addresses, such as is done with a DNS BlockList [DNSBL http://tools.ietf.org/html/draft-ietf-repute-model-08#ref-DNSBL].) Section 4.1, paragraph 2 starting with Response Sets have I think this sentence should be parenthetical: OLD: IANA registries are created in a separate document. NEW: (IANA registries are created in a separate document.) Section 9.3 I think this sentence reads better as follows: OLD: Numerous other topics related to use and management of reputation OLD: systems can be found in [I-D.REPUTE-CONSIDERATIONS]. NEW: Numerous other topics related to the use and management of reputation NEW: systems can be found in [I-D.REPUTE-CONSIDERATIONS].
Re: AppsDir review of draft-ietf-repute-model-08
On 8/30/2013 2:37 PM, Hector Santos wrote: On 8/30/2013 10:46 AM, Tony Hansen wrote: The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to achieve, 2) the meaning of messages transmitted, and 3) important unobvious features of the protocol. This document accomplishes its goals quite well. As a high potential implementator of this DKIM-REPUTE framework and user of any future REPUTE products based on this DKIM-REPUTE framework, I am somewhat disappointed to find not a single integration consideration for the highly adopted SPF technology. Not a single mentioning of the word or the integrated use of this highly adopted mail transport augmented technology. ... Hector, what you're suggesting would be fine for a document that specifically was written about reputation servers for email services. But draft-ietf-repute-model is not the place for it. While draft-ietf-repute-model does contain an example of how a reputation service could be used to help assess a DKIM identifier, that is not the thrust of this document. RFC 4101 (Writing Protocol Models) contains this advice: 3.2 Abstraction is good ... try to abstract away pieces ... 3.3 A few well-chosen details sometimes help ... it's often a good approach to talk about the material in the abstract and then provide a concrete description of one specific piece to bring it into focus. ... The DKIM example is just that, an example of one way the model could be used. It is strictly illustrative and not exclusionary in any way. Tony Hansen
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
On 8/20/2013 3:01 PM, Pete Resnick wrote: On 8/15/13 2:06 PM, SM wrote: At 11:48 14-08-2013, IAB Chair wrote: This is a call for review of List of Internet Official Protocol Standards: Replaced by an Online Database prior to potential approval as an IAB stream RFC. My guess is that draft-rfced-rfcxx00-retired cannot update RFC 2026. Does the IAB have any objection if I do something about that? [...] The document argues that STD 1 is historic as there is an online list now. The IESG and the IAB had an email exchange about these two points. Moving a document from Standard to Historic is really an IETF thing to do. And it would be quite simple for the IETF to say, We are no longer asking for the 'Official Protocol Standards' RFC to be maintained by updating (well, effectively removing) the one paragraph in 2026 that asks for it, and requesting the move from Standard to Historic. So I prepared a *very* short document to do that: http://datatracker.ietf.org/doc/draft-resnick-retire-std1/ I'm asking Jari to Last Call it along with a status change for STD 1 (RFC 5000) to Historic. If the RFC Editor wants to explain more of the history and whatever else they're going to do in a separate document, that's up to the IAB. But declaring Standards to be Historic is something the RFC Editor or IAB shouldn't be doing. The above document solves the problem by making it clear that the IETF isn't interested in the document being updated anymore. pr I support this. But it also raises a couple other questions. What about rfcxx99 series, published along with the rfcxx00 series? Were they ever formally retired? After rfcxx00 is retired, can the RFC editor start using both xx99 and xx00 as normal RFC numbers? I'm not saying that Pete Tony Hansen
Re: stability of iana.org URLs
I sent IANA a list of 45 iana.org URLs found in the RFCs that generate 404 NOT FOUND (along with the number of the RFC(s) where that URL was found). Amanda said she'd pass the list on to the redirector. Tony On 8/1/2013 2:48 PM, Jeffrey Hutzelman wrote: Nonetheless, it's an existing URL in an immutable published RFC. Once such a thing has been published, right or wrong, best practice is to make sure it remains valid.
Re: RFC 6234 code
On 6/28/2013 4:53 AM, Dearlove, Christopher (UK) wrote: I'd actually tried the authors, but no reply yet (only a few days). For me, a thanks to Tony Hansen, who did the extraction for me. (That makes me feel a little guilty, why should he do my work I could have done?) But the point of posting on this list was to say that the code should be available so that each person wanting that code doesn't have to do that again. Hmmm, as one of the authors of RFC6234, I'm not sure how to respond to that, other than to say, You're welcome. :-) (And no, you didn't get the files extracted from the RFC, but instead got the files as used to generate the RFC.) I also tried the RFC Editor thinking they might have e.g. XML from which extraction might have been easier, but also no response yet. And I had found several libraries, but not the RFC code. ... But the broader point is that if it's worth the IETF publishing the code as an RFC, it's worth making the code available straightforwardly. I've suggested on a couple occasions to the RFC Editor that, when an RFC provides source code, they should allow rfc.tar or rfc.tgz to be provided as well. There's only a handful of RFCs that do provide source code, for whatever reason, so this should not be an onerous additional feature. I've CC'd the RFC Interest mailing list, where this would be more properly discussed. Tony Hansen
Re: RSOC Appointments
Thank you, Fred. Tony On 6/25/2013 1:20 AM, Fred Baker (fred) wrote: Congratulations, gentlemen. On Jun 24, 2013, at 5:35 PM, IAB Chair iab-ch...@iab.org wrote: Nevil Brownlee, Tony Hansen, Joe Hildebrandt, Bob Hinden, Alexey Melnikov, Bernard Aboba (an IAB member), and Joel Halpern (an IAB member).
Re: STEAM: BOF proposal for Berlin
I'm thinking the enhanced RFC format proposed below should be dubbed STEAM/PUNC. Tony Hansen On 4/1/2013 6:52 AM, Daniel Raft wrote: STEAM: BOF proposal for Berlin ... 2) Finally, preparing for the global deployment of the Internet-Enabled Smart Grid (IESG), and to further increase diversity, we probably want to enable the use of steam-powered typewriters for IETF work. The STEAM WG will enhance the RFC format and process to allow direct publishing from typewritten sheets and scanned printouts of Word documents.
Re: Mentoring
On 3/14/2013 10:51 AM, Fred Baker (fred) wrote: One thing that I suspect newcomers would also like a pointer to is http://www.ietf.org/wg/chair-photos.html, and clarity on the use of the data tracker to identify internet drafts in a working group. This might come down to a newcomer's page (as opposed to a pointer to the slides from the newcomer's tutorial) off the meeting page. The photos are only good if they're present: fewer than 2/3 of the chairs have their pictures there. Tony
Re: Useful slide tex (was - Re: English spoken here)
On 12/3/2012 9:28 AM, Keith Moore wrote: On 12/03/2012 08:57 AM, George, Wes wrote: You have a very specific opinion of what an effective WG session should be like and what people should and should not be doing to facilitate such. Sounds like you need to work with the EDU team to give a Sunday afternoon training session entitled how not to turn a WG session into a broadcast-only medium possibly with a section for WG chairs and a section for potential speakers. Years ago, my impression was that that Sunday training sessions were pretty much ignored by anyone experienced in the organization. Is this still the case? Yes. However, the pan-galactic plenaries are still sort-of paid-attention-to by those who are present at the meetings, except for those totally distracted by the bad-attitude room. Tony Hansen
Re: Newcomers [Was: Evolutionizing the IETF]
On 11/15/2012 4:45 AM, t.p. wrote: I started, some years ago, with a meeting, because the culture that I was used to was that conferences, be they annual or triannual, were where things really happened and that e-mail filled in the gaps in between (and I think that this remains the case in other, related, fora). 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 People interested in particular technical issues join the mailing list of a WG and occasionally attend one or more of the three IETF meetings held every year. and After participating by email for a while, it may be time to attend your first meeting. which is not exactly sellling the idea of attending meetings:-) But as I say, I think that that is the nature of the IETF. I've always felt that: between the meetings, four months worth of work gets done, and then during the meeting, another four months worth of work gets done. I've found this to be true over and over. Tony Hansen
Re: [IAB] IETF 92 in Dallas!
ah, the memories ... Tony Hansen On 8/16/2012 2:31 PM, John Levine wrote: People also should be aware that Dallas has major transit and highway work underway right now in particular North of the airport. By 2015 (2014 actually), you will be able to take light rail (orange line) from the airport to downtown: http://www.dart.org/about/expansion/orangeline.asp Somehow it just won't be the same if we don't have to wade through waist deep water. R's, John
Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page
Huh? Make tao a directory. Put the document in the directory as index.html. Now www.ietf.org/tao will redirect to www.ietf.org/tao/ will redirect to www.ietf.org/tao/index.html. Tony Hansen On 7/4/2012 1:54 PM, Russ Housley wrote: Julian: No, I was just trying to understand *why* the archive can't be at http://www.ietf.org/tao/archive. I was told that we cannot have http://www.ietf.org/tao directed to the document and also be the directory containing the archive directory. Russ
Re: Last Call: draft-hoffman-tao-as-web-page-02.txt (Publishing the Tao of the IETF as a Web Page) to Informational RFC
I've read this version and think it's an excellent revision. Is there going to be a way of seeing a list of all the versions of the tao? Or links within tao.html to the previous version? Perhaps a www.ietf.org/tao/ should be maintained that has pointers to all the versions as well any proposed update. Tony Hansen t...@att.com On 7/5/2012 5:19 PM, Paul Hoffman wrote: Based on many people's input (most recently, John's), I have updated the draft to more cleanly separate out the history of the Tao from the change that is happening.
Re: Last Call: draft-hoffman-tao-as-web-page-02.txt (Publishing the Tao of the IETF as a Web Page) to Informational RFC
I think my point was missed. Section 2 says: All published versions will be archived using URLs of the form http://www.ietf.org/tao-MMDD.html. My question is: Where is there a list of all of the tao version files? How would one be able to find out the name of the previous version so they could do a diff and see what has changed? How can I see a history of the files? Here is a suggested addition to section 2: Each version of the Tao will also have a link to a history page of all versions. Or something like that. The mechanics what that page looks like can be determined later -- it doesn't really matter right now, nor does it matter right now what the address is. Tony Hansen On 7/5/2012 6:02 PM, Paul Hoffman wrote: On Jul 5, 2012, at 2:45 PM, Tony Hansen wrote: Is there going to be a way of seeing a list of all the versions of the tao? Or links within tao.html to the previous version? Perhaps a www.ietf.org/tao/ should be maintained that has pointers to all the versions as well any proposed update. I think the Tao web page should point to RFC 4677 in a well, how did I get here? section, given that this is not the same as it ever was.
Re: Last Call: draft-hoffman-tao-as-web-page-02.txt (Publishing the Tao of the IETF as a Web Page) to Informational RFC
Authoritative, no. But definitely referenced by many, many people and IMO worthy of a certain amount of care. Tony Hansen On 7/5/2012 11:57 PM, John C Klensin wrote: --On Thursday, July 05, 2012 23:22 -0400 Tony Hansen t...@att.com wrote: I think my point was missed. Section 2 says: All published versions will be archived using URLs of the form http://www.ietf.org/tao-MMDD.html. My question is: Where is there a list of all of the tao version files? How would one be able to find out the name of the previous version so they could do a diff and see what has changed? How can I see a history of the files? ... Tony, Mostly out of curiosity, why do you think it is important. If the Tao were a reference document that was authoritative on IETF procedures or the like, it would be a different matter: I can think of many reasons why it might be important to establish exactly what the rules and procedures were at any given time. But, given that it is a non-authoritative tutorial summary description of how we do things, I have a certain amount of trouble understanding why going to extra effort to maintain a long-term back trace is actually important. What am I missing? john
Re: I-D Action: draft-hoffman-tao-as-web-page-00.txt
I'm wondering if there needs to be a distinction between minor updates and major updates. Minor updates would be the typo variety or a URL change and wouldn't require much review at all. Major updates would require non-trivial review. Tony Hansen On 6/11/2012 11:43 AM, Russ Housley wrote: Paul and Brian: Oh, one thing I now realise is that the draft doesn't state that the editor (in deciding what changes to adopt) and the IESG (in approving an update) will of course do so by a normal IETF consensus process (presumably ad hoc last calls) and subject to appeal like anything else. This is so obvious in the IETF context that I didn't even notice that it wasn't stated. It is not what was intended. - There was no mention to me of ad hoc last calls, so I did not include them in the draft. Well, that was presumably an oversight. The IETF always works by a consensus process, afaik. The IESG thinking on this is in line with Brian's thinking. In the past, the Tao has been published as an informational RFC. The approval process included community comment and IESG evaluation. A parallel approval process ought to be used here. Let's use of a well-known URL for the current approved Tao and a well-known URL for the draft of the Tao that is under consideration. This will facilitate review of updates. - Is there an appeals process for the content of the various web pages created by the IESG? Yes. For many years there has been a presumption that the appeals process in section 6.5 of RFC 2026 can be applied to *any* IESG action. That being so, I suppose it isn't vital to write it down in every document, but it makes things clearer. Indeed. Any decision by the IESG is subject to the existing appeals process. Russ
Re: Add a link to the HTML version in i-d-announce mails ?
It would be acceptable to me, especially since there's a link from there to the tools HTML version. (Look for the html link at the top.) Tony Hansen On 3/6/2012 9:12 AM, Russ Housley wrote: I would be much happier with a link to the datatracker HTML version: https://datatracker.ietf.org/doc/draft-name/ Would this meet your needs? Russ On Mar 6, 2012, at 8:41 AM, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft. I can not believe I'm the only one. Hence, would it be possible to also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? Cheers, Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
non-2119
While 2119 is being discussed, I thought I'd mention a small I-D that Dave Crocker and I wrote on terminology that might be used in places where 2119 ought not apply. It's Non-Normative Synonyms in RFCs http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-01 Thoughts on this draft would be appreciated as well. Tony Hansen t...@att.com On 8/31/2011 9:28 AM, Scott O. Bradner wrote: I've been traveling so have not had a chance to do anything but watch the discussion on a RFC 2119 update. a few thoughts 1/ I am far from convinced that there is a need to update RFC 2119 there is a bug in the boilerplate (as has been mentioned) and some people seem to have a hard time understanding what (to me) seem like clear descriptions of (for example) MUST SHOULD - but the issues do not seem serious enough to warrant replacing what is, basically, a simple dictionary usage constraint 2/ it seems like a very Bad Idea to move 2119 to historic- we move RFCs to historic when no one uses them or when they are a Bad Idea in light of updated technology - I do not think that makes much sense in this case - in addition it makes the status of RFCs that have a normative reference to a historic document a bit funky - if an update is actually needed there is no reason that I can come up with that it could not just be that -- an update 3/ I doubt that I'll ever catch up with Postel as the most referenced RFC author so that is not a consideration (for me) I wrote RFC 2119 (most using text from RFC 1122) because people were using MUST without saying what they meant, an update, if people think that one is actually needed, will serve that purpose as well as 2119 has. When I posted the original ID it was pointed out that I should also address when such terms should be used (i.e. try to limit the use to where it actually made sense protocol-wise) - I tried to do that but that part may not have been as successful as it might have been - any update might try to be clearer in this area that RFC 2119 is. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 8/31/2011 3:14 PM, Keith Moore wrote: On Aug 31, 2011, at 3:07 PM, Hector wrote: RFC2119 is not unclear on this point. Correct again, it is not unclear. It says it very clear. I don't know why you wish to ignore Tony's I-D reinforcing this concept and optional implementation: SHOULD, RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding. Adding additional text and documents inherently increases the burden on readers. context check. The purview of the non2119-nonkeywords doc is to suggest wording to use when *NOT* in the 2119 context. Perhaps the paragraph in the non2119-nonkeywords docs should read: *instead* of SHOULD or RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-yam-rfc4409bis-02.txt (Message Submission for Mail) to Full Standard
I support publication of this RFC. Tony Hansen t...@att.com On 8/11/2011 9:37 AM, The IESG wrote: The IESG has received a request from the Yet Another Mail WG (yam) to consider the following document: - 'Message Submission for Mail' draft-ietf-yam-rfc4409bis-02.txt as a Full Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
On 8/3/2011 12:22 PM, Warren Kumari wrote: Hi all, I seem to remember discussions about this a long time ago, but searching through archives gets no love... How do folk feel about having asking for subject_prefix to be set on the IETF Discussion List (AKA this one!) - this will prefix mail sent to this list with something like [Discussion] or [IETF] or something [0]. -1 cause it breaks signatures This might be mitigated if authentication-results support were added. Tony Hansen PS. I do my sorting based on the To/Cc field as much as anything. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
Do I hear a call for a morning cookie break? Tony hansen On 8/1/2011 5:50 PM, Andrew Allen wrote: +1 with Adam - Original Message - From: Adam Roach [mailto:a...@nostrum.com] Sent: Monday, August 01, 2011 04:38 PM To: Russ Housleyhous...@vigilsec.com Cc: IETFietf@ietf.org Subject: Re: A modest proposal for Friday meeting schedule I'd like to join the sparse voices in speaking out against this plan. By Friday, I'm pretty well on a local meal schedule. Pushing lunch back by 2 hours would pretty well on guarantee that I'd be sugar-crashed and less coherent than normal by the end of Session II. /a On 8/1/11 10:10 AM, Russ Housley wrote: I am discussing the possibility with the Secretariat and the IESG. I will report back to the community as soon as possible. Russ On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote: Something like this: 8:30-11:00 Session I 11:15-12:15 Session II 12:30-13:30 Session III I really like it, as there are a bunch of post-IETF stuff, some of which starts in the afternoon and thus conflicts with the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Revising I-Ds became painful
On 4/20/2011 1:18 PM, Behcet Sarikaya wrote: ... 2. RFC XML has changed. It seem like xml.resource.org has a new xml compiler. I had a lot of trouble in compiling my existing xml files. I am OK with improving RFC XML but why not keep upward compatibility? An optional strict checker was added to the online xml2rfc web page, turned on by default. You then have two choices: 1) Fix your XML. If your XML file fails the strict checker, then it was not valid according to the xml2rfc DTD grammar. The error message will tell you what you did wrong, using a regular expression to describe what is expected (which may be rather cryptic). For example, here are a few of the messages you might see: [Error] INPUT:86:9: The content of element type list is incomplete, it must match (t)+. Your list did not include any t tags. [Error] INPUT:175:11: The content of element type t must match (list|figure|xref|eref|iref|cref|spanx|vspace). Inside a t tag, you may only have one of the tags listed -- any other tag will be an error. [Error] INPUT:193:11: The content of element type section must match ((t|figure|texttable|iref)*,section*). Inside a section tag, you can have zero or more t, figure, texttable or iref tags, followed by zero or more section tags. The numbers indicate the line and column number where the error was noticed, but that number is figured out after include and reference processing has been performed. So it may not match exactly the line numbering in your file, but should be close. 2) Turn off the strict checking. In the web form, on the line that says Checking, instead of picking Strict choose Fast. Note that there is currently an effort to rewrite the xml2rfc processor that does the actual processing behind the scenes. One of the requirements for this effort was that it pay strict attention to the DTD, exactly like the Strict Checking does. Hope this helps. Tony Hansen t...@att.om ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
New version of xml2rfc released
A new version of xml2rfc (v1.36) has been released, as well as updates to the xml2rfc web service running at http://xml.resource.org. Major new web features include: * New options in web form to generate ePub and PDF. * New option in web form to show trace and warning messages along with the output, using frames. This is the default. * New option in web form to do strict DTD checking. * New advanced web form (see bottom of the web page) to: generate HTML using Julian Reschke's XSLT, generate Postscript, and generate RTF. Major new xml2rfc features include: * Generate proper boilerplate for RFC generation (RFC 5741). (Also see the RFC Editor's status-memos page.) * Support for the new rfc consensus= attribute to help support RFC 5741. * Support for the new ?rfc text-list-symbols=o*+-? processing instruction. Modify the list of symbols used for list type=symbols. The default is o*+-, but can be set to any list of characters. For example, specifying abcde will cause a to be used for 1st level, b for the 2nd level, etc, cycling back to the first character a at the 6th level. Specifying o* will cause the characters o and * to be alternated for each successive level. Further information can be found at http://xml.resource.org. Enjoy. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
On 3/21/2011 7:28 AM, John C Klensin wrote: While I believe this is a fine objective, I want to point out one issue: the big advantage of generic markup (XML or otherwise) over finely-controlled formatting markup (nroff or otherwise) is that the former eliminates the need for authors (and others early in the publication process) to worry about formatting and, indeed, keeps them away from it. The more one goes down the path of letting (or, worse, encouraging or requiring) authors fine-tune formatting and layout, the more we reduce the advantages of generic markup. In the extreme case, xml2rfc could deteriorate into what might be described as nroff plus a bunch of macros in an XML-like syntax. I don't think we are there or that we are at immediate risk of going there. But I think we need to exercise caution. In particular, if the idea is for the RFC Production Center to be able to do detailed formatting (like page boundary tweaking) using the general xml2rfc syntax and tools, I suggest that: First, people think about whether there is a way to express the requirements generically. For example, a lot of the page boundary tweaking that the Production Center has to do is because the xml2rfc processing engine isn't good enough at handling widow and orphan text. If changes were made to the engine to, e.g., bind section titles more closely to section body text, and generally to permit the needed relationships to be expressed better in generic markup, the requirement for formatting-tweaking might be greatly reduced. John, we're in total agreement here. And improved widow+orphan control is definitely top of the list in my mind for what would help the RFC Production Center the most -- doing it as a generic change within the formatting engine without requiring additional markup directives is certainly preferable to the other alternatives. Second, if formatting control must be (further) introduced into xml2rfc in order to make page layout control possible, can we do it by inventing a processing directive family separate from ?rfc...? If we had ?rfc... as something I-D authors were expected to use a ?rfcformat... as something used only in final formatting production, possibly even generating a comment from nits checkers if present earlier, we would be, IMO, lots better off --and lots closer to common publications industry practice-- than mixing them together I think this is an excellent idea. Further discussion of specific improvements and how to accomplish them should probably be done on the xml2rfc mailing list, as well as meta-discussions on how to vet ideas for improvement. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
On 3/17/2011 11:36 AM, Martin Rex wrote: Julian Reschke wrote: the context of this was a discussion how to generate a ToC using NROFF. My comment was regarding the claim that NRoffEdit somehow achieves this; it does not. It just does exactly what xml2rfc does: it paginates itself and adjusts the ToC accordingly. Once you feed the nroff output, be it from NRoffEdit or xml2rfc, into a standard nroff process, it'll get incorrect as soon as page breaks change. The page break will NOT change. NRoffEdit produces the exact same page breaks as the standard nroff process. More context: At issue is the use of nroff by the RFC production center, which *does* manipulate the page breaks through hand tweaking. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
On 3/17/2011 12:26 PM, John Levine wrote: If this (running NroffEdit as a postprocessing step) could be established as standard procedure, this would simplify the output target for the xml2rfc SoW. The current xml2rfc already does pagination and generates the TOC for the text version, so the extra work to emit them surrounded by nroff codes should be pretty minimal. If we're going to put more work into xml2rfc, I would much rather figure out what the production people are doing with nroff that xml2rfc doesn't currenty do, and add twiddeles so they can do that in xml2rfc and skip the nroff completely. Yup, this exactly matches conversations I and others have been having with the RFC production center. Conversations along these lines have also been a part of why there's the xml2rfc SoW currently in progress: to generate a better code base from which modifications to xml2rfc can be more easily made. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On 3/14/2011 5:05 PM, Brian E Carpenter wrote: There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. sigh -- +1 2) More substantively, ... I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. I think both suggestions are in order. +1 and +1 Tony Hansen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 1/24/2011 12:37 PM, Russ Housley wrote: draft-housley-two-maturity-levels-03 was just posted. ... Overall I find this spec to be an improvement over the previous version. Here are a few areas where improvements can be made. This phrase in Section 1: In addition, IETF working groups and IESG members providing much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. is not a sentence. Should it be provide? Should it be have been providing? Something else? The sentence in Section 1 One desired outcome is to provide an environment where the IETF community is able to publish Proposed Standards as soon as rough consensus is achieved. and these sentences in Section 2.1: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. No new requirements are introduced; no existing published requirements are relaxed. together lay out what is required for PS. Disregarding the other arguments over the word restore, these sentences are otherwise fine and dandy. But I think there needs to be further guidance provided to the IESG and Working Groups on how they should change their behavior. What is wrong with how the WGs and IESG are currently interpreting the rules of 2026 for PS? What current behaviors differ or have gone beyond what 2026 requires, and hence need to be changed to restore those requirements? Without such guidance, nothing changes. One major section that has been removed from the previous version of this I-D is what to do with documents currently in the Draft Standard status. I know that there was significant disagreement with the automatic reclassification to Internet Standard proposed before, with good reason. I'm going to letter the the rules in section 2.2 as follows. I'm also going to indicate how these sort of map into the old classifications: a) technical maturity (DS = FS) b) belief in significant benefit to Internet community (DS = FS) c) significant number of implementations with successful operational experience (DS = FS) d) no unresolved errata (PS = DS) e) no unused features that increases implementation complexity (PS = DS) Some people have argued that having a significant number of implementations (c) is sufficient to demonstrate both technical maturity (a) and the belief in benefit (b). The (d) and (e) requirements have already been demonstrated by virtue of those RFCs already being at DS status, although additional errata may have been filed against the DS. So I'm going to suggest that the following be applied to documents that are currently in Draft Standard status: Any protocol or service that is currently in Draft Standard status, without significant unresolved errata, may be reclassified as an Internet Standard as soon as it can be demonstrated to have a significant number of implementations with successful operational experience. This reclassification may be accomplished by filing a request with the IESG, detailing the Implementation and Operational Experience. After review, the IESG will hold an IETF-wide Last Call on the reclassification. If there is consensus for the reclassification, the RFC will be reclassified without being reissued. Protocols and services that have significant unresolved errata will need to be re-issued to resolve the errata before the above criteria can be applied. Of course, there is still an open question what it means to have a significant number, which will remain as subjective as it was before with the 2026 rules. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
The magic directive is .tm: .tm string After skipping initial blanks, string (rest of the line) is read in copy mode and written on the standard error. For anything you want in the table of contents, put in this line at the proper place (or include it in a header macro): .tm header level and title . . . . . . \n% Stick in a line that says .so toc.input where you want the table of contents to go. # 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, ignoring stderr this time nroff file 2/dev/null And your output will have a table of contents in the proper place with the proper page numbers. Note: At least on my linux box, this won't work because nroff is a shell script that calls groff internally and redirects stderr to /dev/null. So you have to use groff directly. Tony Hansen On 12/21/2010 11:43 AM, Julian Reschke wrote: On 15.07.2009 11:13, Julian Reschke wrote: Randy Presuhn wrote: ... No need to manually edit. Use the macros or awk / sed to spit the toc into a file which can be inserted into the correct position by the .so nroff directive. This will result in a table of contents in the correct position. There is the possibility that if the number of toc pages has changed from one iteration to the next that the page numbers will be off by one, but that will go away the next time the process runs. For editing a document, particularly a largish one, the availability of .so is for me nroff's biggest advantage over xml2rfc. ... ... Randy, I've been spending some time looking at the feasibility of using NROFF for IDs while retaining features like automatics generation of the TOC in the *right* place. Funny enough, googling for this topic leads me back to this thread (and nowhere else, it seems). So, I do understand how generate the ToC at the end, and I'll probably grok .so, but what is needed to extract the ToC into a separate file? Is there anything in nroff supporting that, or were you just referring to a set of homegrown tools? Also, as far as I can tell, the generated ToC will already be paginated, so do you post-process it again so it can be inserted properly? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wikipedia
On 12/15/2010 12:08 PM, Andrew Sullivan wrote: Yes, but you can only do that if (1) the author uses the particular-version URL or (2) the author includes a visited-on note in the citation. It's lovely, however, that in wiki-based systems you do have this ablity, and I agree that it'd be nice to encourage its use. This indicates to me that the one of the checks the RFC Editor and possibly idnits should do is whether or not such citations have a date accessed notation. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wikipedia
On 12/14/2010 3:27 PM, Marshall Eubanks wrote: The problem I have with this is not the content (presumably the author of the I-D is vouching for any references they use), it's that the content can change at any time. The problem with referencing *any* web page, whether it's Wikipedia or otherwise, is that the content can change at any time. So you not only need spatial coordinates (the URL), but also the temporal coordinates (date and time) for *when* the pertinent data was accessed and found to be on that web page. Interestingly enough, the rules for external references in Wikipedia also require the temporal coordinates to be recorded. And for Wikipedia itself, for any given date and time you can always pull up in the history what the page had on it right then. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text versions of ID and RFCs
Use ftp to retrieve them. Set ASCII mode. Your line ending problems will be solved. Tony On 11/10/2010 10:26 PM, Yaakov Stein wrote: When retrieving IDs or RFC from the tools.ietf.org or datatracker.ietf.org the file has only LFs rather than CR+LF. Yes, it is easy enough to convert this for simple reading on Windows machines, but it is inconvenient to have to do this every time. Could it be possible to change the default here ? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [DRUMS]
If you look at diffs from draft-chandhok-listid-04.txt, you'll find that the reference name got updated in the References section, but the references themselves within the text did not. Tony On 8/23/2010 4:15 AM, t.petch wrote: RFC2919 makes reference to [DRUMS] for some of its ABNF but I see no sign of DRUMS in its references (nor is there a relevant erratum). Would that be what became RFC2822? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
1/1/2 comes closer to 1/1/1.7 than 1/1/1. Tony Hansen t...@att.com On 8/7/2010 8:04 PM, Michael StJohns wrote: Hmm... folding Australia into Asia, Africa into Europe and S America into N America (for discussion purposes only) that's roughly 1/1/1.7 as a ratio. (Asia/Europe/NA). Or 4/4/7. It will be interesting to see what the other runs of the data show. Mike At 07:49 PM 8/7/2010, Donald Eastlake wrote: Assuming the very simple model that attendance consists of a fixed number of constant attendees from each continent plus a continentally local variable number that only show up when the IETF meets on their continent and using the very limited data provided, using a rough least squares fit I get the following: Constant Attendees Africa 6 Asia 236 Europe 254 N.America 409 Australia 14 S.America 8 Continentally Local Attendees Asia 333 Europe 173 N.America 232 Thanks, Donald == Donald E. Eastlake 3rd 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com mailto:d3e...@gmail.com On Fri, Aug 6, 2010 at 4:44 PM, Bob Hinden bob.hin...@gmail.com mailto:bob.hin...@gmail.com wrote: During my IAOC chair plenary talk at IETF78 (slides are in the proceedings) I asked a question about continuing the current meeting policy (3 in North America, 2 in Europe, 1 in Asia in two year period (3-2-1) ) or changing to a 1-1-1 policy based on current meeting attendance. The talk included a graph of attendance by continent for IETF72-IETF78. I was asked to provide this data to the community. It is attached. It includes the raw data and a new graph that shows attendance by percentage. It appears to me that a 1-1-1 meeting policy is justified by current overall IETF meeting attendance. Your comments are appreciated. Bob ___ Ietf mailing list Ietf@ietf.org mailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre-evaluation-05
The IESG members I know are quite familiar with the requirements of 2026 and are expecting a deployment analysis for going to full standard, but not a repeat of the interoperability analysis that was already done years ago. Tony Hansen YAM WG co-chair On 5/18/2010 2:37 AM, Roni Even wrote: Hi, I am not the expert on the requirements and it will be up to the IESG. I think that when you go to full standard you need to take out any commands and tags that are not used by interoperable products. If that was done previously than it is OK but I suggest that you mention it to the IESG. Roni Even -Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Tuesday, May 18, 2010 12:47 AM To: Roni Even Cc: 'General Area Review Team'; draft-ietf-yam-5321bis-smtp-pre- evaluation@tools.ietf.org; ietf@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre- evaluation-05 On 5/17/2010 12:07 PM, Roni Even wrote: In general it looks good, what I did not see is a summary of an analysis that evaluate if all commands and tags are used in interoperable products That's correct. The working group has been diligent in restricting its work to the chartered scope, namely satisfying only requirements for full Internet Standard. I believe your comment is, instead, applicable for Draft. RFC 5321 satisifed that quite a long time ago, since it is already at Draft status. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ok .. I want my IETF app for my iPad ..
For RFCs and I-Ds, I use tools.ietf.org/html/rfc and tools.ietf.org/html/draft-. An unsung feature of that tool is that it both displays AND *prints properly*, using CSS to control pagination. (It's a workaround for what you're complaining about, but it works.) Tony Hansen t...@att.com On 4/8/2010 10:47 AM, Richard Shockey wrote: That was what I had in mind when I started this thread or maybe configuration options for push of new WG drafts. No browser including Safari displays ASCII text well and that has been my ultimate objection. It drives me nuts that I have to print out all new drafts to actually read them ( sorry HP ). If the app could convert the ASCII to something that allow for different fonts and auto repagination display that would be totally wonderful. That function alone has been one of the huge drivers for tablet devices as Amazon's own market analysis has determined. Its very very age skewed to the over 40 crowd. That is why I'm totally sold on the .epub format. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rob Evans Sent: Tuesday, April 06, 2010 12:40 PM To: Ole Jacobsen Cc: ietf@ietf.org Subject: Re: Ok .. I want my IETF app for my iPad .. Display RFCs? Doesn't this new toy of yours already have a browser? I was idly thinking of this a few days ago. An app for the iPad that will sync across RFCs and I-Ds for offline viewing would be quite useful. Rob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Above market hotel room rates
Another factor is that the going IETF room rate may include other items as part of the package. For example, in Hiroshima breakfast was included in the IETF room rate, but not the off the shelf rate. Other amenities will vary. Tony Hansen On 3/24/2010 11:08 AM, joel jaeggli wrote: It's actually pretty straight forward. hotels expect to make a certain amount on a conference of a given size. you can either pay that in meeting room rental, fb or room rate. if the room rate goes down the attendance fee goes up. Also the multivenue hilton contract was negotiated back in the neustar days so it's not clear that ams was even involved. joel On 3/24/2010 7:53 AM, Lou Berger wrote: Phil, I've been booking lower non-ietf rates at most IETFs for quite some time now. I don't remember when I started, but it certainly was after AMS took over. If the problem is really as you suggest, that rates go down from the time of contract signing to when the meeting is actually held, then this can be easily addressed in the contract. If one had checked rates at the time this hotel was announced, you would have found like I did that the adjacent weeks had much lower rates than this week. This was the context for my question to Ray in Hiroshima. Clearly those who are negotiating on our behalf could be doing a better job on pricing. If they can't get obtain better prices, what's the point of having a IETF/group rate? We should all just book individually. I don't think anyone, including myself, need someone to cry to, but I do want an IAD/secretariat that works to the benefit of the IETF. I can't speak for anyone but myself, I come to the IETF to work. I really don't come to the IETF for the nearby attractions or the right brownies. In order to do our work, I think we need a reasonable and safe meeting environment (which includes no construction, a past problem that the secretariat thankfully ensures no longer occurs), a meeting location that is easily accessible, and costs that are contained (because if they're not, my and many others ability to attend will be limited.) Perhaps I'm misinformed or being unreasonable, but I expect that it is the IAD/secretariat's job to deliver these. Lou On 3/23/2010 8:19 PM, pjnes...@gmail.com wrote: Well I am not in the secretariat but I expect it is something along the lines of: The ietf reserves the hotel a year or more in advance and signs a contract for a block or rooms at rate X which is a discount on what the hotel expects room rates to be in the future. Then a year goes by and the economy dictates what the actual room rates are at the time of the conference. Usually its a lot more. Occasionally its not. Anyone making reservations should always ask what rate is available at the time. Of the standard rate is less then book that. People need to be responsible for themselves and not cry to the secretariat to manage their lives for them. I paid for my own way when I went to meetings and you can be sure I asked when making reservations. Phil --Original Message-- From: Lou Berger Sender: ietf-boun...@ietf.org To: Samuel Weiler Cc: ietf@ietf.org Subject: Re: Above market hotel room rates Sent: Mar 23, 2010 7:36 PM I asked Ray about this problem in Hiroshima, his response was something along the lines of conference rates are different and more complicated from regular hotel rates. I have to say, I really think the community deserves a detailed response on this topic from the secretariat... Lou On 3/23/2010 6:44 PM, Samuel Weiler wrote: Once again, we appear to be meeting in a hotel that's offering lower rates to the general public than they're offering to us. As of right now, the Best Available Rate at the Anaheim Hilton for tonight, 23 March 2010, is $119. The senior rate is $113. That's from hilton.com. With a 2 day cancellation policy. The same rate is also available for a three night stay, leaving on Friday. -- Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Sent from my Verizon Wireless BlackBerry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [77all] No Host for IETF 77
+5 Tony Hansen On 3/23/2010 5:17 PM, Spencer Dawkins wrote: Fred, thanks for this news. By the way, I'm told that T-shirts have been ordered. We should have the opportunity to purchase them somewhere around here tomorrow or the next day. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
There are two versions of ID-nits that should be used: 1) one when you're working on getting the words right, and 2) one when you're working on getting the formatting right. #1 should be used when you're at the beginning of the lifecycle. The requirements for it *should* *be* *minimal*. #2 should be used when you're getting close to submitting the document to the IESG for further processing. That's when the majority of those picky things should be highlighted. Perhaps the I-D uploader can ask which type of document this is, and act accordingly. For *-00 and *-01 files, it could even *assume* that it's a #1-style document. Tony Hansen t...@att.com On 3/20/2010 6:55 PM, Bob Braden wrote: +1 Bob Braden (PS: The IESG has chosen to impose the RFC editing rules on all Internet Drafts. That always seemed counter-productive to me. I am not sure I would characterize the problem as serious, but it does seem t o warp common sense for the sake of bureaucratic uniformity.) In my view, we have an actual serious problem in that there is an increasingly high barrier to I-D submission because idnits has a large number of rules, nearly all of which are about formatting. I don't believe that authors of documents or WG-appointed editors ought to have to worry terribly much about that, except maybe near the time when the document is ready for publication. It's absurd, given the tools available, that document authors need to worry as much about line lengths and number of pages (!) in initial submissions as they need to worry about completeness and clarity of their text. A ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
+1 On 3/17/2010 12:18 PM, John R. Levine wrote: If we could agree that the final XML was authoritative, and if necessary let them hire someone to fix xmlrfc so it can produce the text version without hand editing or postprocessing, that would be a big step forward. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
I agree, there did seem to be lots of support for it, including my own. But I don't think anyone really wanted to stand up and act as the WG Chair and declare concensus. After all, this is a basic infrastructure item that spans the entire IETF+IRTF+IAB space. Who is in charge of managing that entire community? It seems like there should be a serious presentation of the topic at one of the upcoming plenaries, with subsequent discussion, with the aim at coming to a concensus. Tony Hansen t...@att.com On 3/16/2010 9:22 AM, Julian Reschke wrote: Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard
The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'ESMTP and LMTP Transmission Types Registration ' RFC 3848 as a Draft Standard +1 Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: publishing some standards immediately at Draft-Standard status?
If we had three stages that were named untested standard interoperable standard widely deployed standard would that make any difference? Those names match what 2026 says PS, DS and FS are supposed to represent. But the hurdle to move a standard from the status of untested (PS) to interoperable (DS) has been rather large. In a discussion with Russ Housley this afternoon, we talked about how eliminating the DOWNREF problem has indeed broken the logjam somewhat, and that there HAVE been standards moving forward to DS recently, and even a FEW moving to FS. I consider this encouraging news. Hopefully we can chip away at a few more of the logjams. More study is needed. -- anon Tony Hansen Donald Eastlake wrote: If you read the definitions and theoretic criterial for Proposed versus Draft, it makes a lot of sense. Proposed is just proposed and non-injurious to the Internet. Draft required interoperability of independent implementations and is the first level where widespread implementation is recommended. This distinction makes a lot of sense. The problem is the constantly escalating hurdles in practice to get to Proposed... Thanks, Donald On Thu, Nov 12, 2009 at 10:55 AM, Eliot Lear l...@cisco.com mailto:l...@cisco.com wrote: I guess the question I have is why bother having any of these levels at all? What legitimate purpose are they ACTUALLY serving? Eliot On 11/12/09 4:28 AM, Tony Hansen wrote: One idea discussed over various beverages last night was based on an observation about the high bar that most Proposed Standards have had to pass over in order to become RFCs: many of them would not have gotten to publication without having already gone through interoperability testing. So the idea is that the shepherding files for such I-Ds could include interoperability reports indicating that they *are* already interoperable and have successful operational experience, and then be published directly at Draft Standard status. Tony Hansen t...@att.com mailto:t...@att.com ___ Ietf mailing list Ietf@ietf.org mailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org mailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
Didn't Harald put up a timer sometimes during open mike? Tony Hansen Russ Housley wrote: I did not take the comment as disrespectful. A timer might be a very good experiment. Russ At 05:53 AM 11/11/2009, Danny McPherson wrote: Russ, Olaf, et al, I was serious in my recommendation to experiment with limiting question (comment) time at the microphone at plenaries. I believe it'll not only help mere mortals pay more attention, but will also encourage those folks that have questions or comments to be more concise, thereby keeping the audience better engaged. I honestly mean no disrespect and appreciate the wealth of institutional knowledge that's on hand and frequently shared, I just believe that it'd be more effective use of such precious time (and encourage more discussions on this list :-). -danny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
publishing some standards immediately at Draft-Standard status?
One idea discussed over various beverages last night was based on an observation about the high bar that most Proposed Standards have had to pass over in order to become RFCs: many of them would not have gotten to publication without having already gone through interoperability testing. So the idea is that the shepherding files for such I-Ds could include interoperability reports indicating that they *are* already interoperable and have successful operational experience, and then be published directly at Draft Standard status. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
Yup, and most of those proposed standards and draft standards should have been declared full standards *long* ago. What we *don't* do well is revising the levels of standards that got published, became fully interoperable and deployed without needing a rev of the document. Why is their status still marked 'proposed' or 'draft'? RFC 2026 does NOT require a rev to the document to move forward if there are no errata. For those specs that everyone has implemented and deployed, but there are a number of errata that everyone agrees are required for the spec to be useful, here's an idea for a revision lite (the diet version of a revision): recycle the spec almost totally *as-is*, with a section added called Verified Errata. Copy in such errata, attach the interoperability and deployment reports, and publish. Tony Hansen t...@att.com Eliot Lear wrote: Not THIS again. Let's look at a few of the standards that are commonly used today: HTTP: DS SNTP: PS SIP: PS IPv6 Addressing Architecture: DS SMTP: DS Full standard MPLS-VPNs: PS BGPv4: DS MIME: DS XMPP: PS (although it seems the real work goes on elsewhere) OSPF: Full standard RIPv2: full standard BFD: not to be found VRRP: DS Radius: DS DNS base: full standard DNS components: varying SNMPv3: full (but long before anyone actually used it) And so you will forgive people who seem confused by our quaint notion that there are flavors of standards. We don't do a good job of describing maturity with our standards levels. Perhaps we do a good job of using the standards levels to make a recommendation. How much SNMPv1 and v2 is out there still? Apparently not many people are listening to that recommendation. Does standard matter at all any more? I think so. A good number of the base protocols that are run on the computer I type this from are actually IETF standards. Yeah (except for software and device management. We blew, and continue to blow that one). So let's get real. John's draft was the right thing to do for NEWTRK. But do we really have the stomach for it? Last time out we did not. Eliot ps: see you all in Orange County, where I'm sure this endless debate will continue. On 11/11/09 5:04 PM, Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: publishing some standards immediately at Draft-Standard status?
Raise the bar more? Not at all -- that's not what I said. I said that the bar has *already been raised* so high that many of our I-Ds have already become fully interoperable before they get an RFC number assigned. What I said, is that if you *have* interoperability and deployment when you get the RFC number assigned, go ahead and get published at DS or FS status. Unless there are errata, changing the status from PS to DS to FS should be an administrative task, not a wait-for-full-revision-taking-X-years chore. And yes, the above statements are *fully* in line with use the current process better. Tony Hansen t...@att.com Carsten Bormann wrote: On Nov 12, 2009, at 12:28, Tony Hansen wrote: published directly at Draft Standard status Raise the bar so they stay at I-D level for even longer? A sizable part of the Internet is run on I-Ds, not on PS. I think the right direction is to publish PS earlier. If done right, it's only six months from there to the DS, you know. (About half of that time the draft is stuck in the RFC finalization process anyway :-). (My suggestion would be to stop talking about changing the rules and instead just find ways to use the current process better.) Gruesse, Carsten PS.: And you could spend some time during I-D time already to upgrade your downrefs to DS :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: publishing some standards immediately at Draft-Standard status?
RFC 2026 section 6.2: 6 months from PS = DS 4 months and 1 meeting for DS = FS. As John notes though, the clock currently begins after RFC publication time. There's no allowance granted for time already spent in jail. Tony Hansen t...@att.com James M. Polk wrote: At 09:44 PM 11/11/2009, Carsten Bormann wrote: I think the right direction is to publish PS earlier. If done right, it's only six months from there to the DS, you know. err... I thought this was minimum of 18 months? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: meta-issues on charter discussions
This was posted to the ietf list. While the charter history pages are nice, they can be made better using a format similar to how tools.ietf.org presents RFCs and I-Ds: a non-printing list of versions at the top with ways to show differences between versions. Sounds like a job for the tools team. :-) Tony Hansen t...@att.com Thomas Narten wrote: Re: old charters and such. While poking around earlier this week, I found: http://www.ietf.org/dyn/wg/charter/history/ (it is hanging of the WG pages, so not that hard to find.) It appears to be a snapshot of charters whenever they change. But, they change often due to events that are probably not the kind of changes we are thinking about, and there is no indication about what has changed, so there are a lot of copies and wading through them to find stuff appears pretty daunting. And the history only goes back 3 years or so... But they might be a basis for some tools to extract stuff. But, if tools are going to do this, it seems like an archival format other than HTML would be desirable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
I also had to copy rfc2629-other.ent, rfc2629-xhtml.ent and rfc2629.dtd into the current directory to get it to work. And Firefox seems to be pickier than IE about the XML it will accept. Otherwise pretty cool. Tony Hansen t...@att.com Julian Reschke wrote: Julian Reschke wrote: Again: it's much easier to test using any recent web browser, and using rfc2629.xslt. Just press F5 (refresh) in the browser window, and there you go. BR, Julian ... OK, I have been told off-list that this needs more explanation... rfc2629.xslt implements the xml2rfc vocabulary in XSLT, which all major browsers nowadays implement. Thus, you can simply open the XML in the browser, and let the browser convert to HTML. To do so: 1) Add the XML Stylesheet Processing Instruction to the top of the source file, such as in: ?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ? (after the XML declaration, when present) 2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides (get it from http://greenbytes.de/tech/webdav/rfc2629xslt.zip). 3) Open the XML file in IE/Firefox/Safari/Opera. More info: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html NOTE: rfc2629.xslt does not support xml2rfc's include processing instruction, thus external references will only work using the XML entity inclusion mechanism (see http://xml.resource.org/, Including Files). BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Releasing xml2rfc 1.34pre3?
+1!! Carsten Bormann wrote: 1.34pre3 is certainly working for people doing drafts these days. 1.33, however, is utterly useless! Ship it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Yet Another Mail (yam)
I just wanted to reinforce what John is saying. Step 1 of the charter for all RFCs being considered by YAM is a review. The output of that review 1) may indicate that it's completely ready for immediate advancement to Full Standard, or 2) it may indicate that it's NOT ready for immediate advancement to Full Standard, possibly for the very reasons you brought up or for various other reasons that indicate that it's not ready for prime time. If #2 is discovered, the YAM WG will make a recommendation as to what needs to be done to the document, and the document would be removed from further consideration by YAM. What happens to the document outside of YAM at that point is not the direct concern of YAM itself. It's even conceivable that someone outside of the YAM framework may choose to work on the document in parallel to YAM. Or when YAM's initial charter is concluded, the YAM WG may recharter to then reconsider those documents it chose not to immediately advance. Tony Hansen t...@att.com John C Klensin wrote: --On Tuesday, May 12, 2009 11:24 -0700 Bill McQuillan mcqui...@pobox.com wrote: If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. This part of the charter worries me. It presumes that no Draft Standard can be ambiguous! On the off chance that a Draft Standard *is* ambiguous in some way that has caused two implementations to be non-interoperable, but arguably conforming, it seems that the WG must drop the Standard from consideration without any chance of some engineering judgement (or even horse-trading) to get the implementations to become interoperable and to resolve the ambiguity. OTOH, maybe that WAS the intent of the charter. As I have understood it, the intent was to move what can be moved without controversy and then to come back, with a recharter, and figure out what, if anything, should be done next. So, if the case you describe is detected, that specification would not be a YAM candidate, at least under the initial charter. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
I support this version of the document. Tony Hansen t...@att.com The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-12.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-05-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a second IETF LC on the document, after the author has addressed most of the issues raised during the first IETF LC. Please see http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl2=http://tools.ietf.org/id/draft-crocker-email-arch-12.txt for the list of changes. In particular note that the Internationalization section has been updated. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11811rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
if `egrep -v 'joins the room|leaves the room' log | wc -l` 0 post log Translation: if, after removing the joins the room and leaves the room messages are removed, you wind up with anything left, post the log. This would eliminate almost all of the logs that have no substantive information. Tony Hansen t...@att.com Spencer Dawkins wrote: IETF meeting jabber sessions often hold some very useful gems. And at their worst, each one isn't all that big. It occurs to me that we should try to fold them into the regular email archive, perhaps simply by sending the wg mailing list a copy afterwards? I would like to see this, and if we expect it to happen, I'd suggest automating it. Should be simple enough (assume IETF Plenary goes to ietf@ietf.org, and there probably are some other corner cases to consider before implementing). My only caveat is that the current jabber logs include entries for days where nothing happened - both zero-byte entries and Dan York entered the room, to mention one entry in recent mediactrl logs. I'd suggest a minimum size for this - not huge, maybe 1000 bytes? - if we get serious about doing it. Ripping out the entered/left entries would be nice, but that's the next level. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form(RBNF) A Syntax Used in Various Protocol Specification toProposed Standard
Going back to RFC 2205, These rules are specified using Backus-Naur Form (BNF) augmented with square brackets surrounding optional sub-sequences. What do you think of BNFO, for Backus-Naur Form with Options? or BNFB, for Backus-Naur Form with Brackets? Tony Hansen t...@att.com John C Klensin wrote: --On Friday, February 06, 2009 13:55 +0100 Tom.Petch sisyp...@dial.pipex.com wrote: ... I think too that there is a third issue, of a better name than RBNF. John clearly showed that this I-D is not reduced. Historic? Deprecated? Limited_applicability? Variant? Simplified? simplified has the same problem as reduced, unless one argues that one simplifies a metalanguage by adding more operators. Variant would work for me, and this actually is much more of a variation on classic BNF (or ISO Extended BNF) than ABNF is. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard
I support this draft on the standards track. We look forward to companies starting to use it and already have implementations for it. Tony Hansen t...@att.com The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Vouch By Reference' draft-hoffman-dac-vbr-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hoffman-dac-vbr-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15717rfc_flag=0 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advice on publishing open standards
One note about the charset name. The registered name would be charset=iswa-2008, *not* charset=x-iswa-2008. The x- prefix should only be used for experimenting until the name is registered. Per RFC 2978, section 3.1, x- prefix can only be used *until* the registration is complete. You should also be looking at that section for other advice. Tony Hansen [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I would like the coded character set to be an official character set of the internet because I plan on writing an extension for Firefox and Thunderbird, where charset=x-iswa-2008. ISO/IEC JTC1/SC2 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
I'm personally very interested in getting the format for querying DNS *white* lists standardized. I want to be able to use DNSWLs as part of *positive reputation* checking: given an *authenticated* domain name (say, with DKIM), can we say something positive about them beyond they send email? The protocol described in this draft covers both cases, both positive and negative checking. While the majority of the examples in the document concentrates on negative examples, the protocol *is* useful for the positive case. Does anyone have issues with the use of this protocol for WHITE lists? Tony Hansen [EMAIL PROTECTED] John C Klensin wrote: Sadly, I have to agree with Keith. While these lists are a fact of life today, and I would favor an informational document or document that simply describes how they work and the issues they raise, standardizing them and formally recommending their use is not desirable at least without some major changes in our email model and standards for what gets addresses onto --and, more important, off of-- those lists. john --On Friday, 07 November, 2008 18:38 -0500 Keith Moore [EMAIL PROTECTED] wrote: DNSBLs work to degrade the interoperability of email, to make its delivery less reliable and system less accountable for failures. They do NOT meet the no known technical omissions criterion required of standards-track documents. The fact that they are widely used is sad, not a justification for standardization. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
I admit it: I'm not a fan of X- headers. Why not just register a header in the header registry and be done with it, rather than encouraging yet-another set of X-headers, all possibly named differently? Why encourage the use of X- headers in a standards track document? For example, consider using Netnews-Gateway-Control in place of X-Gateway, or some other such name, 2. The news-to-mail gateway adds a Netnews-Gateway-Control header field to all messages it generates. and then add this to the IANA Considerations section: Header field name: Netnews-Gateway-Control Applicable protocol: mail, netnews Status: standard Author/Change controller: IETF Specification document(s): RFC (this document) If you'd rather define a *set* of header names, to allow implementations to pick their own names, then use this: 2. The news-to-mail gateway adds a Netnews-Gateway-Control header field (or a header field whose name begins with Netnews-Gateway-Control-) to all messages it generates. and then add this to the IANA Considerations section: Header field name: Netnews-Gateway-Control Applicable protocol: mail, netnews Status: standard Author/Change controller: IETF Specification document(s): RFC (this document) Header field name: Netnews-Gateway-Control-* (all headers whose name begins with Netnews-Gateway-Control-) Applicable protocol: mail, netnews Status: standard Author/Change controller: IETF Specification document(s): RFC (this document) My $0.02. Tony Hansen [EMAIL PROTECTED] SM wrote: I can see your point here, but I'm not sure the lack is particularly important. I'd really rather not see us make further changes to USEFOR; generally an X-* header is used for this and is adequate in practice. Each implementation might use a different header field name. It's might become a problem in future. Well, this is very explicitly an example based on a specific implementation, which happens to use an X-* header. But I can see where this would be less than ideal. However, as above, I'm hesitant to invent a new header for this purpose and add the necessary machinery for registering it when there is no standardized existing practice and it's not clear what issues are involved in picking a header field, standardizing its format, and so forth. Implementors will likely pick X-Gateway as you mentioned that header name in the example. Once people start using specific headers, it's difficult to depreciate them in favor of some standardized format. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 73rd IETF - Registration
IETF Secretariat wrote: Registration is now open for the 73rd IETF Meeting! Kudos on adding these two new questions to the registration form: T-Shirt Size Dietary Restrictions? Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: BCP or RFC references
I think it would be better to use phrasing like this: BCP 32 (currently RFC 2606) Tony Hansen [EMAIL PROTECTED] John C Klensin wrote: --On Wednesday, August 13, 2008 8:13 AM -0500 Eric Gray [EMAIL PROTECTED] wrote: Isn't it a little too redundant to include the parenthetical RFC 2606 or its successors along with BCP 32? This is really a separate topic and one that it would be nice if, after all these years, the IESG, RFC Editor, and, if they care, the IAB would make a decision about and then start reflecting that decision in style guidelines (including the Checklist) and in tools. While I'm going to use BCP in the examples below, the question applies equally well to STD numbers. * Is a citation of BCP NN a reference to whatever the current version of the BCP, and all of the documents that make it up? If so, we need citation and referencing formats for such things that are not tied to an RFC number (or, worse, several RFC numbers). We have no such referencing model and some tools, such as xml2rfc and its bibliographic libraries, make faking one really painful. * Is a citation of BCP NN (RFC ) or BCP NN [RFC] a reference to the BCP or a reference to the RFC with a note that it is a BCP? If the latter, should the form be RFC (BCP NN) or perhaps RFC (BCP NN) [RFC]? Or should this form be prohibited? * If RFC is a BCP, does referencing it without the BCP number mean that future revisions or updates don't count? * If a particular specification is known much more widely by its RFC number than by its BCP one (which is certainly the case for RFC 2026), what is the approved form of citation if one wants to be clear that the BCP and not the RFC is what counts? Choices include: -- Use the BCP number and make people try to find out what is being talked about by consulting the bibliography or some index outside the document. -- Use the RFC number with some text like or its successors, perhaps even or its successors as BCP NN. -- Use the BCP number with the RFC number and hope that people figure out the BCP is intended and the RFC is specific. -- Use the BCP number with the RFC number and a note to make the intent clear. I've clearly got some opinions on this, and they favor clarity over ambiguity, even if the clarity involves some possible redundancy, but YMMD.And some editorial guidance in the Checklist, in 2223bis or some other style manual, would, IMO, really be appreciated. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Experiment: More Meeting Time on Friday for IETF 73
It would be be best if the Fri afternoon slot were filled in early rather than as the last slots to be filled in. That way people would have more notice that they're being included in the experiment and there'd be less of a chance of a rude surprise. Tony Brian E Carpenter wrote: On 2008-07-18 09:33, IETF Chair wrote: The IESG is considering an experiment for IETF 73 in Minneapolis, and we would like community comments before we proceed. Face-to-face meeting time is very precious, especially with about 120 IETF WGs competing for meeting slots. Several WGs are not able to get as much meeting time as they need to progress their work. As an experiment, we are considering adding two Friday afternoon one-hour meeting slots. The proposed Friday schedule would be: 0900-1130 Morning Session I 1130-1300 Break 1300-1400 Afternoon Session I 1415-1515 Afternoon Session II Try it. We've been having periodical email arguments about Friday afternoon for years; an experiment is the best way to settle it. But please do *design* the experiment - what are you going to measure to find out if it's a success or failure? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Experiment: More Meeting Time on Friday for IETF 73
One measurement would be the number of conflicts that cannot be resolved with and without the extra slots. Tony Hansen [EMAIL PROTECTED] Andrew Sullivan wrote: On Fri, Jul 18, 2008 at 10:15:04AM +1200, Brian E Carpenter wrote: But please do *design* the experiment - what are you going to measure to find out if it's a success or failure? I agree strongly with this latter point. I've been trying to come up with a measure of success. So far, I imagine measuring additional effective sessions[1] and measuring attendance at meetings on Friday afternoons compared to other afternoons. One could also measure success as a different ratio: the number of complaints about Friday afternoon slots compared to the number of complaints that there isn't enough time for the needed meetings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
shepherd hat on During the second last call for rfc2821bis, there has been much discussion of how the implicit MX handling is to be handled in an IPv6-capable and IPv6-only environment. This has generated much heat, as well as numerous proposals that were both productive and counter-productive, and that were both in scope and out of scope. I came at this question with an open mind, trying to weigh each of the arguments being made both for and against different stances. My measuring stick in each case against has been: How does this measure against what is required to advance 2821bis to Draft Standard? What is the current usage? What do the implementation reports have to say on this issue? The SMTP implementations that have made the transition to support IPv6 appear to already have done it in a way that supports records for the implicit MX case. In some cases they are following RFC 3974, and other cases they are just using getaddrinfo() and letting it do the rest. Note that RFC 3974 itself was supposedly based on experience in deploying IPv6. At least one of these MTAs is in common use around the network in the IPv4 world. In essence, these implementations are following the RFC 821 and RFC 974 (sans WKS) rules of looking for address records. They've ignored the A-only wording of RFC 2821 and are acting like we specify currently in 2821bis-09. In my queries I haven't yet found any IPv6-capable SMTP server that doesn't do it. I've seen examples of sites that are in regular use that mail would break in an IPv6-only world if implicit MX to did not work. From this viewpoint, running code wins. I'm also swayed by the principle of least surprise. Some of the responses I've gotten have been along the lines of Why's this a question? Of course you do lookup. One person who had a site set up with an IPv6-only connection and no MX record told me I wanted to forward my e-mail to an account on that machine. It worked the first time, so I didn't see a need to change it. As mentioned above, at least one of the IPv6-capable MTAs is in common use around the network in the IPv4 world, and turning on IPv6 on those boxes should not cause surprises. Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS archive search around the question of what led to the wording change in 2821bis saying explicitly to do A lookups. These indicate that the intent of adding the A record description was to be descriptive, not prescriptive nor proscriptive. So the bottom line is that I see sufficient support for including lookups when implicit MX comes into play. It's been suggested that 2821bis revert back to either the implicit MX description found in RFC 821 or RFC 974, although Glen Anderson had some suggested improvements to that latter's description that do make it clearer. Any of these three would satisfy this decision, and I'll let John choose the wording he prefers. /shepherd hat off Tony Hansen [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue Sheet Change Proposal
Barry Leiba wrote: 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 you dipped your cast in ink and tried to write your email address with it. And that you're actually left-handed, as well. I think the illegibility factor really started in earnest after people began hearing stories about people sucking off large masses of email addresses from the blue sheets and sending spam. Thinking back to the blue sheets from 7-10 years ago, they used to be quite legible. I like Olaf's suggestion of adding a level of indirection. Tony Hansen [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Implicit MX and A RRs
As the shepherd/pseudo-chair for 2821bis effort, our plan of action is going to be as follows: *) the implicit MX issue needs to be resolved. *) there are a few other small items that need to be resolved that will be detailed on the [EMAIL PROTECTED] list We'll give the discussion about one more week and then make a consensus decision. So speak up now. Tony Hansen [EMAIL PROTECTED] John C Klensin wrote: --On Wednesday, 26 March, 2008 22:41 +1100 Mark Andrews [EMAIL PROTECTED] wrote: ... It would be needed until IPv6 takes over. It will be needed even *after* IPv6 takes over. There will be lots of queries for A records long after the majority of hosts don't have A records. We need to remove the implict MX from A to prevent the A record lookups occuring as things currently stand. Mark, Whether that proposal is a good one or a bad one, it can't be done in 2821bis because that is a document moving from Proposed to Draft Standard and the implicit MX feature is _very_ widely deployed and used. So, IMO, this discussion is not directly relevant to the (already closed) Last Call on 2821bis and should probably be move to the ietf-smtp mailing list. Second, no matter what is done with standardization, it will be many, many years before one could count on those A RR lookups not occurring -- too much software out that that is very rarely updated. The advantage of the MX 0 . approach over getting rid of the implicit MX from A is that, if there were consensus for it, it can be deployed in less than geological time. But, either way, it seems to me that the correct (and only feasible) actions start with an I-D that says something useful and is discussed on, at least, the ietf-smtp list. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Deployment Cases
Dave Crocker wrote: Well, that's such a reasonable question, I did a subjective review of Proposed Standard RFCs for the last number of years -- ignoring that most recent and going back to rougly RFC 2500 -- looking for acronyms that were for significant IETF-generated efforts. ... A number of questions come to mind: 1. What additions or removals should be made to the list? add MsgTrk Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
courtesy of google translation: http://translate.google.com/translate?u=http%3A%2F%2Fwww.apple.com%2Fjp%2Fdownloads%2Fdashboard%2Fnetworking_security%2Fipv420.html+langpair=ja%7Cenhl=ensafe=offie=UTF-8oe=UTF-8prev=%2Flanguage_tools Tony Hansen [EMAIL PROTECTED] Marc Manthey wrote: On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html well, i could imagine what its good for , but an english version would be appreciated ;) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: mandatory draft sections (was Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt))
My viewpoint is somewhat in between. The sections need to be there, but only in the final draft(s) that are intended for Last Call. Prior to that, those sections don't need anything more than a To Be Determined notation. Prior to the Last Call, those sections usually don't add anything to the technical meat of the draft and aren't necessary. (Unless of course, the draft is dealing with IANA issues throughout.) During Last Calls, there are many people reviewing the drafts from many angles, including the protocol point of view and the IANA point of view and the internationalization point of view and Tony Hansen [EMAIL PROTECTED] Ned Freed wrote: Actually I don't have so much of a problem with having such sections in drafts at review time, but I hate to see them clutter up published RFCs. My position is the exact opposite. Full and complete review of drafts it of paramount importance and anything thqt interferes with that is unacceptable. And as I have pointed out, we have running code demonstrating that these things are at best distracting and at worst actively interfere with proper review. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Lisa Dusseault wrote: I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. I could see a note being added. However, anything more than that is totally inappropriate. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Prague
Arriving early to CZ, I chose this option. It was easy to do (I called the Hilton and spoke with the concierge), and it was certainly one less thing to worry about once I got here. Tony Hansen [EMAIL PROTECTED] ASH, GERALD R, ATTLABS wrote: You can arrange a taxi pick up at the airport directly with the Hilton (Hilton taxi driver will be waiting in the arrivals hall right behind the customs holding a sign with your name and Hilton Logo). Cost for taxi (CZK 750, EUR 25) can be posted to your hotel account. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'DomainKeys Identified Mail (DKIM) Signatures' to Proposed Standard (draft-ietf-dkim-base)
Eric Allman wrote: --On November 8, 2006 12:05:07 AM +0200 Pekka Savola [EMAIL PROTECTED] wrote: == what is the expected verifier's behaviour if one or more of these MUST/MUST NOTs doesn't hold? AFAICS, that hasn't been specified, at least not very clearly. Should it be? This is already covered in (e.g.) 6.1.1: Implementers MUST meticulously validate the format and values in the DKIM-Signature header field; any inconsistency or unexpected values MUST cause the header field to be completely ignored and the verifier to return PERMFAIL (signature syntax error). Being liberal in what you accept is definitely a bad strategy in this security context. One clarification to this for Pekka, in case he missed it: Section 3.2: Unrecognized tags MUST be ignored. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'DomainKeys Identified Mail (DKIM) Signatures' to Proposed Standard (draft-ietf-dkim-base)
I have various minor nits with the base document. Overall I consider the document ready to go; these nits can be taken care of during AUTH48. Tony Hansen [EMAIL PROTECTED] 1. Introduction o archival is not a design goal All of the other bullet items have full sentences, but this one does not. (Archival is an adjective, not a noun.) Suggestions are replacing archival with message archiving or archiving. 3.2 Tag=Value Lists however, no encoding may include the semicolon (;) This is slightly ambiguous, as it could be read as saying that the value being encoded cannot have a semicolon in it, as opposed to the encoded version of the value. I suggest that this be changed to read however, no encoding may use an unencoded semicolon (;) or however, no encoding may produce an unencoded semicolon (;) 3.3.1 The rsa-sha1 Signing Algorithm 3.3.2 The rsa-sha256 Signing Algorithm (defined in PKCS#1 (actually PKCS#1 This wording is different between these two sections and could lead someone to wonder what is different in their treatment. I suggest that they be made the same. 3.3.3 Key sizes See [RFC3766] for further discussion of selecting See [RFC3766] for further discussion on selecting 3.5 The DKIM-Signature header field after the body of the message; We no longer include the body of the message in the digest calculation. I suggest changing this fragment to: after the rest of the header fields being signed; 5.4 Determine the header fields to Sign Signers MAY claim to have signed ... ... Signers choosing to sign The signer MAY include more instances of a header field ... The sentence The signer MAY is at the end of the paragraph starting Signers choosing. It would make more sense to move this information to the paragraph starting Signers MAY claim. 6.1.3 Compute the Verification 3. Verify that the hash of the canonicalized message body computed ... What happens if the hash does not match? Suggested addition is: If the hash does not match, the verifier SHOULD ignore the signature and return PERMFAIL (body hash did not verify). used the N-4 trick ... informative note in Section 5.5. The informative note is really in Section 3.4.5, but is not referred to there as 'the N-4 trick'. The reader may have a problem following this reference. I suggest you change it to this: used the N-4 trick (omitting the final --CRLF) ... informative note in Section 3.4.5. 6.2 Communicate Verification Results Verifiers may wish to delete existing results header fields after verification and before adding a new header field to circumvent this attack. This sentence is a bit awkward. I suggest his instead: To circumvent this attack, verifiers may wish to delete existing results header fields after verification and before adding a new header field . A.1 The user composes an email and A.2 The email is signed The message as shown in these two sections are not identical. In particular, the indentation before Joe is different in the two examples. The A.2 and A.3 examples are consistent, so I suggest that the example in A.1 be changed. An alternative is to provide an explicit dump of the example in A.1 so the exact bytes are known, such as: 000 F r o m : J o e S i x P a c 020 k j o e @ f o o t b a l l . 040 e x a m p l e . c o m \r \n T o 060 : S u z i e Q s u z i e 100 @ s h o p p i n g . e x a m p l 120 e . n e t \r \n S u b j e c t : 140 I s d i n n e r r e a d y 160 ? \r \n D a t e : F r i , 1 1 200 J u l 2 0 0 3 2 1 : 0 0 : 220 3 7 - 0 7 0 0 ( P D T ) \r \n 240 M e s s a g e - I D : 2 0 0 260 3 0 7 1 2 0 4 0 0 3 7 . 4 6 3 4 300 1 . 5 F 8 J @ f o o t b a l l . 320 e x a m p l e . c o m \r \n \r \n 340 H i . \r \n \r \n W e l o s t t 360 h e g a m e . A r e y o u 400 h u n g r y y e t ? \r \n \r \n 420 J o e . \r \n 433 A.2 The email is signed The hashes in this section are not what would be produced by the sample private key found in Appendix C. (This was discussed at one of the past meetings.) Change bh= and b= to the following values: bh=jpltwNFTq83Bkjt/Y2ekyqr/+i296daNkFZSdaz8VCY=; b=bnUoMBPJ5wBigyZG2V4OG2JxLWJATkSkb9Ig+8OAu3cE2x/er+B7Tp1a1kEwZKdOtlTHlvF4JKg6 RZUbN5urRJoaiD4RiSbf8D6fmMHtzEn8/OHpTCcdLOJaTp8/mKz69/RpatVBas2OqWas7jrlaLGf HdBktHs6fxOzzAB7Wro=; A.3 The email
Re: RFC Editor RFP Review Request
I use ftp all the time to access the RFCs. I use direct web URLs all the time to access the RFCs. I *occasionally* use rfc-editor.org's web interface. I agree with Henrik. Tony Hansen [EMAIL PROTECTED] Henrik Levkowetz wrote: It may be that the level of detail specification should be less than what it is now, overall; but with the current specification level I felt it is a clear omission to not specify *any* access to the documents except through a search facility. I feel that direct ftp/http/rsync access is actually more important than the search facility specified in the proposed SOW, which is why I commented on this. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
US by itself was about half, and Canada was about another 10%. The current split of 2/3 in North America and alternating Europe and Asia once a year still seems to make sense from the stats. Tony Hansen Fred Baker wrote: That said, I'll remind you of the demographics of this particular meeting, working from memory from the slide Brian showed Wednesday evening. It looked to me like this meeting was a tad less than half from North America, perhaps 20% from Japan and China, and most of the rest from Europe. That argues for roughly half of our meetings being in North America, a meeting every other year in Asia, and the rest in Europe. On Jul 14, 2006, at 10:14 AM, Scott W Brim wrote: On 07/14/2006 10:01 AM, Fred Baker allegedly wrote: Once upon a time, the guideline I followed was that about 1/6 of the IETF was from Europe, a smattering was from elsewhere, and the lion's share was from the US, so I scheduled a meeting every other year in Europe, the odd one in random places, and the lion's share in the US. Those statistics are essentially meaningless now. Why are they meaningless? The IETF should overwhelmingly meet where the participants are, wherever that might be. I still like your algorithm. http://www3.ietf.org/proceedings/06jul/slides/plenaryw-0.pdf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
good point Fred Baker wrote: from the norht american stats. I would encourage you to compare the european and asiapac meetings, from the proceedings. My observation is that the region/country the meeting happens in tends to be exaggerated. Yokohama, for example, was 1977 folks, of which 1/4 were US and perhaps 40% were Japanese. Seoul was similar. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-carpenter-newtrk-questions-00.txt
A variety of people at the plenary last night said declare victory. But I know that different people took that statement to mean different things. To me, declare victory means recognizing the reality of the single level standard as it appears to be and moving on. This doesn't mean to stop working on newtrk, but to refocus newtrk on recognizing that fact. Put an end to the arguments about whether we should go to 1-level, 2-level or 3-level, and move on from there. When a new spec is published on the standards track, it's meant to be the new standard, and the industry should be using it, and that's what industry is (more or less) doing. (The less comes into play once in a while when a non-clueful company puts out an RFP/RFQ for an old standard because that's the standard.) On the flip side is the question of when a standard is no longer a standard. For this I think it should be based on whether there is a group willing to work on: doing interop testing maintaining an errata list for the spec and/or working on a new version of it. If no one is willing to do the testing necessary to find and generate an errata list, the spec should automatically become Historic. (Pick a time span, say 2 years.) So the burden then is laid on updating the errata list in order for the spec to remain a standard. (There would be an opportunity for an empty errata to be created only if there is interop experience to back it up and only after a given time has elapsed.) If people are interested in the standard, they should be willing to do the minor amount of work to keep it from becoming Historic. Tony Hansen [EMAIL PROTECTED] Eliot Lear wrote: Fred Baker wrote: I would like to believe that a well documented interoperability test constitutes DS qualification; the current DS qualification sets the bar somewhat higher than that, and I note that few documents actually achieve that, even though we can daily see implementations interoperating in the field at PS. Some data to Fred's point: By RFC, not by STD (obviously): Status1999200020012002200320042005 - PS102 119 71 105 103 131 169 DRAFT 6 6 2 4 7 7 3 STD 3(*)2 0 8* 3 0 1 (*) 3 in 1999 were SMIv2 6 in 2002 were SNMP. These are rough based on 10 minutes of scripting I did back in March. I believe there are two reasons for the huge gap between PS and DRAFT: - it's difficult to get there (interop requirements, picking out uncommonly used features, etc) - nobody wants or needs to do the work (what GM in her right mind would want her experts working on something that neither generates new features nor fixes product bugs) If Iljitsch's proposal is that the IESG makes a call based perhaps on somebody's request with some modest effort to demonstrate that a spec is ready for the next step, I think that actually would be a fine two-step approach. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF 66 Attendees Alias
Another option to consider is to do the same thing that was done to the ietf@ietf.org list years ago: split it up into a list of important announcements that only the secretariat can post to, and a list of general interest items that anyone can post to. The announcement list would handle the schedule change announcements and would need to be extremely low traffic. The general interest list would let people post about local restaurants, local beer choices, etc. In addition to offering an optout for the subscriptions at registration time, have the list manager send a message to each person subscribed indicating what the list is about and *how to unsubscribe*. The lists *should* follow all the standards and good practices for mailing lists found in RFCs 2369, 2418, 2919 and 3934. Tony Hansen [EMAIL PROTECTED] Dave Crocker wrote: 4. Having a per-meeting special list has an obvious and reasonable basis. However it makes each meeting's list a special case for IETF administration and for attendees. Possible variations to consider: ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs
Ned Freed wrote: The RFC Editor provides an annotated differences listing showing you what changed between your final draft and what's in the actual RFC. It is a simple matter to duplicate this tool and use it to tweak your sources to match the actual RFC. I've tried using change bars and other fancier tools, but I have concluded they're more trouble than they're worth. I've gotten really good mileage from rfcdiff at http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht. It compares two RFC text files and nicely shows the diffs side by side. Regenerate the text in one browser tab pointing at xml.resource.org, do a reload on the diff tab, repeat until fully baked. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
I've been a happy camper since switching to 11a several meetings ago. It wasn't intentional; I had just gotten a new laptop that just happened to have a/b/g. But while everyone else was losing their connections, the 11a network just kept humming along. Life was no different at this meeting; the 11a network worked flawlessly all week along. Thanks NOC! Jabber/xmpp has certainly become pervasive in our environment. At first it was just a convenient side channel; then it became useful for taking notes or scribing, when it worked; and now it's practically considered indispensible in some working groups. It's been an interesting progression. One benefit I especially appreciate is being able to find out who some of the speakers are after they mumble their names at the mike. :-) Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)' to Informational RFC
And *as* one of the authors of the proposed-RFC in question, I find the statement even more curious. Given the objections, I was proposing different text that would have aligned the statement with text already found in other RFCs already published. Tony Hansen [EMAIL PROTECTED] Sam Hartman wrote: Brian == Brian E Carpenter [EMAIL PROTECTED] writes: Brian Tony, That would have amounted to the author and IESG Brian deciding to change the IETF's policy on derivative works, Brian which would have been way out of line, especially in view Brian of the ongoing debate about this point in the ipr WG. Had this sentence been added by the author it would not have changed anything about IETF policy. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
agreed. Tony Hansen [EMAIL PROTECTED] John Levine wrote: Here is the revised proposed charter text: Thanks for pulling this together. If I had unlimited time to waste, I might niggle about a word or two, but it's fine as is, and I look forward to moving ahead and getting some work done. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Back to chartering DKIM [was bozoproofing the net, was The Value of Reputation]
This thread was begun by the last call on the chartering of DKIM. The thread of messages has wandered, with some people remembering its roots (and others not), with some people taking into consideration the history of the thread (and others not), and with some people trying to keep the thread focused on its original topic (and others not). This has led to different assumptions about what lies behind responses to subsequent messages on the thread, and rancor because of those assumptions and the messages arising from those assumptions. This is disheartening. Can we please get back to the question of chartering DKIM? Tony Hansen [EMAIL PROTECTED] Harald Tveit Alvestrand wrote: I think that this discussion, if followed further, will provide neither entertainment nor information to the IETF community. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. This text still keeps the bar high for unnecessary changes, was already vetted through an existing charter, and helped us through a similar impasse when xmpp was chartered. Tony Hansen [EMAIL PROTECTED] Barry Leiba wrote: Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. Can someone propose an alternative 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 willing to accept changes that make sense to make? Barry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Making the xml source available is a boon for those working on subsequent revisions of a document. Many of the RFCs and I-Ds I've worked on have been derivative of earlier RFCs, and having an authorative source format available helps that considerably. Since I grok nroff, I've been able to make good use of the nroff source on occasion, and the RFC Editors have sometimes (in non-crunch-time situations) been quite happy to provide that. I'd much prefer having the source files available at all times so I didn't have to ask them, or make do without during those crunch times. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Henning Schulzrinne wrote: Summary of suggestions: - Official statement of encouragement from the IESG that WG drafts submitted for IESG action SHOULD be in XML-RFC format when being submitted (but can be in any format the working group feels like and the I-D editor accepts during the early stages). - Allow submission of XML-RFC format to the I-D editor, as part of the automation of that part of our process. - (Semi-serious) Have an earlier IETF cut-off date for I-Ds in ASCII, since it takes longer to automatically check them for compliance. This will solve our format problem in one IETF round :-) I love it! - Making XML-RFC versions of existing or new RFCs available to the public. absolutely! The RFC Editors actually have source versions of most existing RFCs, either as nroff or xml. They're just not easily accessible; you have to ask to get a specific copy. I've always been surprised that they haven't been accessible right next to the .txt files. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Henning's proposal (Re: ASCII art)
John, I also started by looking at the XML output from MS Word. I had grandiose ideas of writing a converter from that XML form to something closer to the XML2RFC form, but gave up because it was more daunting than expected. After that I wound up using lots of emacs macros operating on the raw text, and then used hand tuning to add in the comment information. Tony Hansen [EMAIL PROTECTED] John C Klensin wrote: ... Getting a simulation of XML out can be done simply by doing a save as from the version of Word included in Office Professional 2003. The difficulty is that it is XML-used-as-format-markup, not XML-as-generic markup, and MS-XML at that (i.e., if there is a defined DTD or Schema, it appears to be only available to and manipulable by their proprietary tools (and license-prohibited against reverse engineering). I tried to do that conversion with a version of RFC2821bis that was composed using the RFC3285 template plus a few corrections/ twitches suggested by colleagues at Microsoft for better Office 2003 compatibility. I can show pictures of the dents made in the nearest brick wall by my head, a problem that was aggravated by the fact that introducing either the 3285 template or yours into my environment screws up the normal Word working environment, which I need to keep pretty standard. RFC2821bis was finally converted to rfc2xml format on a one-time, no going back, basis by Tony Hanson. I'm not sure of exactly what he did, and suspect it involved some hand tuning, but I at least ended up with something I can work with, get into I-D form, and revise as I go along. The difficulty, of course, is that I lost all of the finely-tuned Word change tracking and comment stuff which was why I used Word in the first place: Tony converted the comments to XML comments, but that just isn't the same thing. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 63 On-line Survey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The sessions where floating mikes worked well were smaller in size, attendance wise. In fact, most of the time, the main reason for using the floating mikes was *not* so that everyone in the *room* could hear what was being said, but instead so that people listening in on the *audio stream* could hear what was being said. In larger rooms, the dynamics are much different, and floating mikes would not work as well. Tony Hansen [EMAIL PROTECTED] James M. Polk wrote: floating mics are a bad idea for many reasons - each getting worse with room and or audience size increasing. Who is in charge of who's next to speak? Who passes the mics to the folks in the middle of a row who didn't bother to get up? Turning of heads happens now to know places (mics in the aisles), but because seated persons are not standing, they cannot be easily seen, causing some confusion and general discomfort in the audience to find the person, then find their face to know who's saying what - which is important sometimes. Few people talk during sessions, and those that do, know to sit where they can readily get to a mic to make a point. I see nothing wrong with keeping this layout Participants are more than capable of turning their heads but when holding a technical discussion those extra mics make a significant difference. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDBLOdxsSylYhzrRYRAqPWAKC++Dj/Eh55CgL36ppw/hUiBy2gmACfbZKj 0H065ZkT23fJfq58v2jRiIA= =HW0c -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 network shutdown at noon today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for a good network experience overall this week! Tony Hansen [EMAIL PROTECTED] MERCIER Francois RD-CSRD-ISS wrote: Hi all, Please note that IETF network shutdown will begin at noon Friday 5th (devices will be disconnected in the afternoon in Palais des congrès, in Meridien and Concorde hotels) We hope you appreciated this event in Paris Have a nice trip back home France Telecom team and international volunteers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC80h0xsSylYhzrRYRAuRMAKCg3qjVvUmk6qRPe04g38a0LhJZfACeNVlF GJH7Gd2FV0JsCQ9c5B7JDDk= =Obw7 -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal of decision to standardize Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
I think this is one of those cases where it's best NOT to have EVERY last process detail laid in stone. :-) Tony Hansen [EMAIL PROTECTED] John C Klensin wrote: John, I don't see any text in RFC 2026 that gives an appeal suspensive effect. However, as a matter of common sense, I have asked the Secretariat to request the RFC Editor to suspend RFC publication. I don't see that text either. I suspect it was omitted because of the possibility of denial of service attacks on getting standards out (Scott Bradner, a comment on this might be helpful). But, because publication of this with an implied recommendation to implement would make any subsequent action on an appeal essentially moot, your common sense solution is appreciated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UPDATE - mp3 audio streaming...
Several of the WGs I'm in only use a jabber scribe, and it's worked well. If there's a network glitch, you have a few options: continue writing your notes locally and post the series to jabber once you reestablish connectivity, or play tag team with someone else who hasn't lost connectivity. There was a web page posted, http://www.xmpp.org/ietf-chat.html, that goes into details on how to set up jabber and access the ietf jabber chat rooms from your machine. Tony Hansen [EMAIL PROTECTED] Marshall Eubanks wrote: I think that a short BCP or the equivalent for jabber scribing would make sense, as not everyone is familiar with the technology. As a frequent scribe, I suspect that scribing and jabber could be combined for open meetings (and might improve the scribing), but 1 minute after the start of the meeting is not the time to start investigating it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UPDATE - mp3 audio streaming...
Kudos for the mp3 streams! So far, the mp3 streams have been quite a success. From the feedback I've heard, the audio quality has been mostly excellent. When combined with the xmpp/jabber rooms, we have a two way communication path, and several meetings I've been in have used this combination quite effectively. Tony Hansen [EMAIL PROTECTED] Joel Jaeggli wrote: Stats wise, on Monday 187 unique ip's joined 1487 streams over the course of the day. On Tuesday 136 ip addresses joined 835 streams over the course of the day. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UPDATE - mp3 audio streaming...
There seemed to be problems with jabber.org's server yesterday, but ietf.xmpp.org was working fine. People who logged in using another xmpp server to log in with, seemed to get to the rooms okay. Tony Hansen [EMAIL PROTECTED] John Loughney wrote: Yeah, I've had trouble with Jabber too. I was the Jabber scribe in multi6 yesterday and it just stopped working halfway through. Noone had communication, even though the wireless was working, more or less. --- Original message --- Subject: Re: UPDATE - mp3 audio streaming... From: Ken Raeburn [EMAIL PROTECTED] In krb-wg this morning, I've heard reports of people being unable to join the jabber chat rooms, including at least one person listed as being in the chat room but report (by email) unable to send anything. (Haven't heard of problems with audio though.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MARID back from the grave?
Of course, the rule about -00 drafts could be modified to allow them to be posted on the followup date IF and ONLY IF they are now a WG draft AND they've been previously published as an individual submission. Tony Hansen [EMAIL PROTECTED] John C Klensin wrote: The notion that new documents were required to be posted a week earlier than updated ones seemed like a good idea at the time (and I bear some of the blame) because the secretariat was spending much more processing, and rule-verification time on the new ones than on the updates. But then we introduced all of this other baggage associated with metadata and semantics and, at the same time, the secretariat stopped doing significant checking of _documents_. Whether your WG's strategy of just leaving everything as a individually-named draft is a good general principle or just an effective workaround for an administrative problem, it seems to me that we shouldn't have procedures that put significant barriers in the way of new WG drafts. As you put it, renaming an existing document, or producing a closely-coupled revision of it, should not advance the posting deadline from two weeks to a month. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Labels in Subject Headers Considered Ineffective At Best' to Informational RFC
The document does not discuss the type of mailing list subject labels that you're referring to. I'm arguing that a better title of the document would be Legislated Labels in Email Subject Headers Considered Ineffective At Best Tony Hansen [EMAIL PROTECTED] Carl Malamud wrote: Hi Brian - I read the first draft of this document, and wondered: Does this propose to change IETF behavior on list management, so that the name of the list (usually same as working group) is not put in the Subject: using the feature of mailman that does this? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: email document delivery service
John C Klensin wrote: --On Friday, February 04, 2005 8:41 AM + Tim Chown wrote: Our anti-virus system tags all IETF draft announcements as being potentially dangerous. I suspect because of the unusual options to fetch the data that are encoded in the MIME header. Hmm. There is a case to be made that those external body part options are as safe, or safer, than a delivered attachment: you can, in principle, inspect either before opening or executing it, but I can easily imagine one of those a good/fun user experience is more important than security or bullet-proof-ness MUAs being designed to provide better access for an actual virus-checker for the external body parts. Certainly an external body part is as safe and probably safer than an imbedded URL, especially in an MUA that opens those URLs automatically. So my instinctive response to that request is have you considered getting your anti-virus software fixed?. Our firewall software here also briefly tagged message/external-body attachments as dangerous. Instead of just removing the attachment, the software deleted the entire message and sent a note saying that they had done so. Whoever had installed the software just didn't get it; it took us a bit to get them to fix it. Even more fearful, I have a feeling that they were just following instructions provided by the firewall software people, who SHOULD know better. Tony Hansen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
