RE: Visa for Korea
Thanks a lot Gene, for your persistence and follow-through! You've done a real service for the IETF community. It is appreciated. Regards, Jerry -Original Message- From: Gene Gaines [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 7:44 PM To: [EMAIL PROTECTED] Subject: Visa for Korea As promised. The Korean consulate in DC has produced two letters for U.S. citizens to carry with them to the IETF Seoul meeting. The letters state that U.S. citizens carrying a valid passport traveling to Korea to attend the IETF meeting and/or tourism for up to 30 days DO NOT NEED A VISA. The letters have been confirmed with the responsible minitries in Korea, and copies sent immigration at Incheon airport, the usual point of entry for Seoul. I have made graphic files and sent them on to the IETF Secretariat people to post to the web. Give them a couple of days to review and get them up. Print and take with you. Show if border officials ask for them. Gene Gaines [EMAIL PROTECTED] Sterling, Virginia USA
RE: Who can do me a faver to send me the latest version of RFC2916bis?
http://ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-07.txt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Felix, Zhang Sent: Thursday, March 11, 2004 9:14 PM To: [EMAIL PROTECTED] Subject: Who can do me a faver to send me the latest version of RFC2916bis? I have tried to search in the IETF website, but only lots of dicussion version about it, no clean doucments. Thanks ahead.
RE: Last Call: CR-LDP Extensions for ASON to Informational
Parallel discussions on the thread 'IANA considerations for RSVP' (postings by Steve Trowbridge and David Charlap) and this thread (Loa Andersson) have shed some light on a) how extensions to GMPLS protocols to satisfy ASON requirements shifted from IETF to ITU, and b) the consequences: steve> - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding steve> the gaps that had been identified between the ITU-T requirements (sent steve> earlier) and what seemed to be implemented by the GMPLS protocols. steve> Specifically, steve> 1. Call & Connection separation, e.g., a call provides the service steve> relationship, which may support connection operations as part of a steve> call. steve> 2. Additional error codes/values, for example, for connection rejection steve> (invalid connection ID). steve> 3. Restart mechanisms: Depending on the introduction by the ITU of steve> additional control plane resiliency requirements, enhancements of the steve> protocol (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be steve> required. steve> 4. Protocol enhancements in CR-LDP for support of crankback capability steve> from intermediate nodes. steve> This liaison was presented in the Minneapolis IETF meeting during the steve> ccamp working group and posted on the IESG web site. The liaison requested steve> assistance in closing these gaps and invited input from IETF on our work steve> in ITU-T. I recall this discussion and understood that the intent was to have extensions made by CCAMP to GMPLS protocols based on these ASON requirements and thus close the 'gaps'. steve> - At the April/May 2002 meeting of ITU-T Study Group 15 meeting, steve> contributions were considered to close these gaps, resulting in text for steve> draft Recommendations G.7713.2 (our rsvp-te document) and G.7713.3 steve> (our cr-ldp document). Again, we sent a liaison (dated May 10, 2002) to ask steve> for comments on our draft Recommendations (made available on the ftp site), steve> to request alignment, and to ask for IANA code point assignments. To quote steve> from that liaison: steve> "Please consider including the proposed solutions provided in G.7713.2 and steve> G.7713.3 to update the existing GMPLS signaling work in support of ASON steve> requirements. I think this is consistent with the understanding that the intent was to have extensions made by CCAMP to GMPLS protocols based on the ASON requirements and thus close the 'gaps'. steve> To hear now that someone thinks that the ASON work in ITU-T is some kind steve> of secret end-run around IETF, and not involved with or related to the steve> work being done internally in IETF is absurd. At every stage of the work, steve> IETF was kept informed of the work and invited to participate. At the steve> invitation for help to address the additional ITU-T requirements, there steve> was no response. As ITU-T progressed this work and invited further comments steve> and alignment of the base GMPLS protocols, again no response. And to the steve> final pleas for comments and codepoint assignments, no response. steve> ... steve> After some private communication with the Area directors, we received some steve> advice that one tool that might be used to finally get the IANA codepoint steve> assignment complete would be to publish what we were doing in ITU-T as steve> informational RFCs. This is the stage we are at today, and given the steve> history I describe above, I do not think anybody can say that we are steve> at this point because any of us did not do everything possible to steve> do this work (a) in IETF, with the initial communication of requirements; steve> or (b) in cooperation between ITU-T and IETF, once this work had steve> progressed in ITU-T. steve> steve> But this is all water under the bridge. We are at the point of trying steve> to get some codepoints assigned for ITU-T documents we are trying to steve> complete. Nobody should say "no" at this point because they think we steve> didn't try to work this IN or WITH IETF first. It should be clear to steve> all that this is not the case. I can understand the frustration in not getting cooperation and follow-up on the ITU/ASON requirements. However, the 'private communication with ADs' left most of us in the dark as to what was (is) going on. The concern still is (drawing from posts by Loa Andersson and David Charlap): loa> The consequence of approving the drafts will be that the extensions loa> by OIF and ITU will be approved by the IETF. I'm not sure that this loa> has been in the open. david> I'm far more concerned with non-IETF groups (like ITU, ATM Forum and david> others) deciding to develop their own incompatible extensions without david> even informing any IETF groups of their actions. david> Groups like these should not be extending IETF protocols without david> consulting with the relevant IETF working groups. Otherwise dav
RE: Last Call: CR-LDP Extensions for ASON to Informational
Zhi, I have followed the ASON and CCAMP work quite closely over the last couple of years. I am quite familiar and mostly in agreement with your summary of events below. What was not well communicated is that the ITU decided (recently) to do the GMPLS/ASON extensions themselves. I think many of the postings on this thread indicate that people were not aware of, and disagree with, this approach. I can understand the frustration of not getting attention to the needed ASON requirements in IETF/CCAMP. IETF/CCAMP had been saying (quoting statements made by chairs and ADs) they need to 'close the gaps' to meet ASON requirements as far back as IETF-53/Minneapolis (March). CCAMP charter extensions to address same were suggested(IETF-54/Yokohama CCAMP meeting minutes say "The charter update is way overdue. Items may be added - protection/restoration, crankback and multi-area operations."), but CCAMP charter extensions are still pending even to this day. However, the answer is not for the ITU (or any other standards body) to extend IETF protocols, and visa versa. This leads to interoperability problems, I believe, wherein we have 'ITU-TLVs', 'IETF-TLVs', 'OIF-TLVs', etc. for GMPLS protocols. Furthermore, we are now inheriting many 'ITU-TLVs' for RSVP-TE and CRLDP. This precludes, or at least inhibits, proper technical discussion to arrive at the best technical approach. Further discussion on 'ITU-TLVs' (e.g., call control, crankback, etc.) is now moot. Perhaps we can learn from this and improve the process, e.g.: a) Bert has proposed a (G)MPLS change process (seems like a good idea), b) better communication and responsiveness, especially from WG chairs on direct queries (e.g., 'where is the CCAMP charter update?' has been asked many times, but there is no response, still pending). Regards, Jerry > -Original Message- > From: Lin, Zhi-Wei (Zhi) [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 24, 2003 2:57 AM > To: Ash, Gerald R (Jerry), ALABS; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: Stephen Trowbridge; David Charlap; Loa Andersson > Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational > > Hi Jerry, > > I'm not sure how long you've followed the entire GMPLS and > ASON work, but I'm assuming here that you weren't part of the > original discussions over the last 1.5 to 2 years on this > matter. That's understandable as this wasn't your original > area of interest. > > However, if you talk with some folks involved since the > beginning, you would realize (and also reading Steve's email > on the history, or simply going back to the email archives in > both MPLS and CCAMP) that > (a) ITU-T tried to get the work done in IETF (I believe Steve > mentioned Oct. 21, 2001) > (b) IETF never actually started/initiated work to fill these > gaps. So a set of individuals who happens to attend IETF, OIF > and ITU decided that they would work towards a solution > (c) This solution was submitted into IETF, OIF, and ITU -- > with clear intention of trying to get feedback from the > "true" RSVP experts > (d) I (and Bala) created I-Ds in IETF (Bala actually started > this I think sometime in early 2002? -- Bala you can confirm > or correct -- while I submitted my I-D in June 2002) > (e) These documents were never taken seriously (This is the > first email I sent: > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00918.html -- > but of course no one responded) > (f) ITU-T requests which were publicly presented in CCAMP > meetings by Wesam and Steve (see Steve's email to see how > many requests were made) were never taken seriously > > The ITU-T delayed their process by several months in order > for RSVP experts (I guess Bob Braden would call folks who's > done this work "non-RSVP experts") to review. Of course no > comments were ever provided by the "true" RSVP experts. > > Several individuals tried very hard to try and get a good > relationship and collaboration going amongst the three > organizations. The break-down is not for lack of trying or > exposing the work to the RSVP experts. > > As such, although I agree that the original intent of all the > individuals who came into this work expecting to collaborate > and do the work in IETF CCAMP WG, the actual situation is > very much different, and is a result of certain members of > the CCAMP WG community deciding not to bother with paying > attention to the work. Again I can understand the perception > that you get since you weren't involved from the beginning. > But a casual perusal of the email archives (too much work for > me, if you're interested you should take a look at the > history first) would give you a much better and accurate > history of the discussions (see > http://ops.ietf.org/lists/ccamp for the CCAMP email archive, > and > http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html > for the MPLS email archive). > > Thanks > Zhi
RE: Last Call: CR-LDP Extensions for ASON to Informational
Zhi, > (e) These documents were never taken seriously (This is the first email I > sent: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00918.html -- but of > course no one responded) Reminder, I responded to your email on June 18, very shortly after you posted (my email to you is attached below). That I did this off the list was probably a mistake. We (you, your co-authors, Adrian and I) then had a prolonged exchange of emails about the draft. Adrian sent you extensive comments on the draft highlighting concerns, suggesting text, and pointing out nits. That you have a reasonably long list of acknowledgements and contributors suggests that the draft was not ignored. As I commented in the attached email to you, "Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such?" I still maintain that this would be the correct way to handle this: bring the requirements to CCAMP as a requirements draft, thrash them out, and get the necessary extensions adopted in CCAMP. Rather, the ITU has developed protocol extensions for GMPLS, something outside the charter of the ITU I believe. Jerry -Original Message- From: Ash, Gerald R (Jerry), ALASO Sent: Tuesday, June 18, 2002 12:58 PM To: 'Zhi-Wei Lin' Cc: Ash, Gerald R (Jerry), ALASO; 'Adrian Farrel' Subject: RE: new draft: GMPLS for ASON Hi Zhi, > I've uploaded a new draft covering the GMPLS usage and extensions to > support the ASON requirements. This document proposes appropriate > extensions towards the resolution of additional requirements identified > and communicated by the ITU-T in support of ITU's ASON standardization > effort, and only provides the extensions for RSVP-TE signaling. Among > the major extensions include support for the concept of "call", as well > as support for setting up soft permanent connections. > > http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-00.txt Looks good. I've attached some excerpts below from the (unpublished) IETF-54/CCAMP meeting minutes. These also identify crankback, restart, etc. as 'gaps' needing to be filled. I guess most of these are being worked on, including restart and crankback http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-03.txt (Adrian is currently providing a significant extension for the 04 version of the crankback draft). Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such? Your comments/suggestions are appreciated. Thanks, Regards, Jerry %% Steve Trowbridge Outlined a variety of "gaps" in the current work: - Call and connection separation - Additional error codes/value - Restart mechanisms - Support for crankback - Support for soft permanent connection See proceedings for details. Eric Mannie: Referring to slide "Identified Gaps". Gaps seem to be very small. Most of the points are solved, can be easily solved, or are in the process of being solved. Trowbridge: This was a preliminary scan. Further review, might turn up more issues. Technologies are similar, so lets identify and minimize gaps. Dimitri: ITU requirements precede much of IETF work. Preliminary discussions indicate that the current gaps are covered by existing protocol work. Areas where additional work will be required are probably minimal, but need to be looked at. IETF may gain final improvements by looking at ITU work. Yong Xue: ITU is working on v2 ASON document so more things could turn up as "gaps". Further communication between ITU and IETF should continue. Trowbridge: Technology will evolve within both organizations. Should expend effort to make sure that they evolve together. %% % Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt. Draft addresses one of the issues that Tolbridge highlighted in his talk - call and connection control separation. Kireeti: There is an explicit statement from ITU requiring this. There is nothing in the charter about this. This is good stuff. Ron and I will go through a charter revision with Ads and discuss putting this in the charter. Also need to address other gaps that were raised by ITU. Scott: When you propose to add something to WG, it would be helpful to state where it fits in the existing charter OR how and why charter should be extended. Eva: I think that it fits into the character as a requirement to the signaling protocols. Scott: OK - that is a good clean explanation that might save chairs some time. Yong: I second Eva's comment. Kireeti: Need to figure out how to address other issues as well. %%
RE: Last Call: CR-LDP Extensions for ASON to Informational
Zhi, > (e) These documents were never taken seriously (This is the first email I > sent: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00918.html -- but of > course no one responded) Reminder, I responded to your email on June 18, very shortly after you posted (my email to you is attached below). That I did this off the list was probably a mistake. We (you, your co-authors, Adrian and I) then had a prolonged exchange of emails about the draft. Adrian sent you extensive comments on the draft highlighting concerns, suggesting text, and pointing out nits. That you have a reasonably long list of acknowledgements and contributors suggests that the draft was not ignored. As I commented in the attached email to you, "Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such?" I still maintain that this would be the correct way to handle this: bring the requirements to CCAMP as a requirements draft, thrash them out, and get the necessary extensions adopted in CCAMP. Rather, the ITU has developed protocol extensions for GMPLS, something outside the charter of the ITU I believe. Jerry -Original Message- From: Ash, Gerald R (Jerry), ALASO Sent: Tuesday, June 18, 2002 12:58 PM To: 'Zhi-Wei Lin' Cc: Ash, Gerald R (Jerry), ALASO; 'Adrian Farrel' Subject: RE: new draft: GMPLS for ASON Hi Zhi, > I've uploaded a new draft covering the GMPLS usage and extensions to > support the ASON requirements. This document proposes appropriate > extensions towards the resolution of additional requirements identified > and communicated by the ITU-T in support of ITU's ASON standardization > effort, and only provides the extensions for RSVP-TE signaling. Among > the major extensions include support for the concept of "call", as well > as support for setting up soft permanent connections. > > http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-00.txt Looks good. I've attached some excerpts below from the (unpublished) IETF-54/CCAMP meeting minutes. These also identify crankback, restart, etc. as 'gaps' needing to be filled. I guess most of these are being worked on, including restart and crankback http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-03.txt (Adrian is currently providing a significant extension for the 04 version of the crankback draft). Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such? Your comments/suggestions are appreciated. Thanks, Regards, Jerry %% Steve Trowbridge Outlined a variety of "gaps" in the current work: - Call and connection separation - Additional error codes/value - Restart mechanisms - Support for crankback - Support for soft permanent connection See proceedings for details. Eric Mannie: Referring to slide "Identified Gaps". Gaps seem to be very small. Most of the points are solved, can be easily solved, or are in the process of being solved. Trowbridge: This was a preliminary scan. Further review, might turn up more issues. Technologies are similar, so lets identify and minimize gaps. Dimitri: ITU requirements precede much of IETF work. Preliminary discussions indicate that the current gaps are covered by existing protocol work. Areas where additional work will be required are probably minimal, but need to be looked at. IETF may gain final improvements by looking at ITU work. Yong Xue: ITU is working on v2 ASON document so more things could turn up as "gaps". Further communication between ITU and IETF should continue. Trowbridge: Technology will evolve within both organizations. Should expend effort to make sure that they evolve together. %% % Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt. Draft addresses one of the issues that Tolbridge highlighted in his talk - call and connection control separation. Kireeti: There is an explicit statement from ITU requiring this. There is nothing in the charter about this. This is good stuff. Ron and I will go through a charter revision with Ads and discuss putting this in the charter. Also need to address other gaps that were raised by ITU. Scott: When you propose to add something to WG, it would be helpful to state where it fits in the existing charter OR how and why charter should be extended. Eva: I think that it fits into the character as a requirement to the signaling protocols. Scott: OK - that is a good clean explanation that might save chairs some time. Yong: I second Eva's comment. Kireeti: Need to figure out how to address other issues as well. %%
IETF Throughput (was RE: Voting (again))
IMO the major problem to be solved is IETF throughput, takes far too long to produce RFCs, **years**, and getting worse. Unacceptably long for users of the standards. IESG is a bottleneck, well known, stated in RFC 3773 http://ietf.org/rfc/rfc3774.txt?number=3774, Section 2.6.2 "Workload of the IESG" There are 2 issues to be solved wrt throughput: 1. needs to be vastly increased 2. with no loss in current quality Candidate solution: 1. WG takes over full responsibility for RFC production ==> parallel processing 2. IESG maintains RFC quality with uniform WG process created, maintained, and enforced by IESG. The PROTO team has a 'shepherding' proposal to offload some of the RFC approval work to WGs. IMO this doesn't go far enough to offload the IESG sufficiently to eliminate the IESG bottleneck and create a parallel process at the WG level. WG procedures would be developed to ensure RFC quality. The procedures would be created, maintained, and enforced by the IESG. WGs I participate in are mostly competent and thorough in RFC production, necessary cross-WG review is done, etc. Many comments on this thread that this quality isn't uniform across WGs, and needs to be. I see no reason this couldn't be made to work, proof is that it works like this, successfully, in other SDOs. Jerry Ash ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Unneccesary slowness.
> When I step back and ask what leads to the best specifications (and > indeed, documents in general), it is all rather simple: > > 1) produce a document. > 2) get a small number of quality reviews. > 3) revise in response to those reviews > 4) ensure that reviewers in step 2 are satisfied by the revision. > 5) Repeat steps 1-3 with a _different_ set of reviewers. > 6) Repeat step 5 until it becomes clear that the reviewers are finding >only minor editorial issues. > > Observations: > > 1) You can't hurry the above, e.g., by imposing artificial deadlines, >or by saying "no objections during LC, therefore ready to go". You >have to have the reviews, and you have to iterate. > > 2) Where the IETF is failing (at times) today is that it isn't >actually reaching step 6) prior to sending a document to the >IESG. Result: IESG finds issues that should have been found >earlier. > > 3) You can "hurry" the process somewhat, but not too much. You can >hurry it in the sense of having steps 1-3 take on the order of 3-5 >weeks. I.e., if you get fast (but good reviewers) and responsive >editors, that is a huge win. The obvious corollary is that if steps >3-5 take too long, you lose momentum big time. Indeed, one real >problem we have today is too many WGs/documents are in a one >revision per IETF meeting cycle. I would assert that any >document/WG in this mode has veered off the road and into a ditch. > >You can also hurry the process by having good editors and good >reviewers, as they help ensure that one doesn't get stuck in a rut >at step 5). > > 4) In the above, there is nothing that requires the IESG do things >differently. It really requires that _WGs_ do things >differently. And, indeed there are some WGs that are doing the >above, and doing it fairly well. They have >chairs/editors/participants that move the discussions/the process >along, they employ issue trackers to ensure that things don't get >lost and so they can actually see whether the sorts of issues that >are being raised are still serious, etc. And when those WGs do a >good job, the IESG "delays" are generally short. > > In summary, the most important improvement that the IETF needs to make > (IMO) is to get its WGs operating better and make them responsible for > demonstrating that the above steps have been followed (and > specifically, step 6 has been reached) before a document is allowed to > go to the IESG, and having those steps be done in a _timely_ manner. 'Spot on'. Also suggested in http://www1.ietf.org/mail-archive/web/ietf/current/msg35135.html "WG procedures would be developed to ensure RFC quality. The procedures would be created, maintained, and enforced by the IESG. WGs I participate in are mostly competent and thorough in RFC production, necessary cross-WG review is done, etc. Many comments on this thread that this quality isn't uniform across WGs, and needs to be. I see no reason this couldn't be made to work, proof is that it works like this, successfully, in other SDOs." Brian Carpenter agreed http://www1.ietf.org/mail-archive/web/ietf/current/msg35167.html: "you're fundamentally correct that the solution lies in the WGs. If WGs produce output that is truly ready to ship, it will get shipped quicker, whatever the formal path." So let's get on with it. Jerry Ash ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Process for Process Change (Was Diagrams ((Was RFCs should be distributed in XML))
This is the nth time we've had this discussion RE ASCII art in IETF, but without a process for process change, no change could be made even if we all agreed, which we never do of course. While the discussion may be enlightening and entertaining, in the end it does nothing but waste cycles, there can be no forward motion without a way to change the process. IMO the ASCII art issue is an important case in point where it would be good to actually resolve the issue. Can we develop a process for process change where a proposal like 'allow I-Ds/RFCs to be posted in Word' can be resolved? Here's a possible approach: 1. submit a proposal to the IESG for a process change (in the form of an I-D) 2. the IESG decides by majority vote whether or not to take up the proposal 3. if #2 is yes, arguments are made for and against by anyone (in the form of an I-D) 4. after a specified period, IESG votes on the proposal 5. the majority decision of the IESG is binding But how do we implement *any* such proposal for a process change process, do we need a process for that?? Jerry P.S. Some good arguments have already been made on both sides of the ASCII art issue. I, like many others, use Word, etc. editors capable of sophisticated graphics, and have to struggle to convert to ASCII art in I-Ds. IMO this is a ridiculous waste of time and loss of information! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars-Erik Jonsson (LU/EAB) Sent: Tuesday, November 15, 2005 9:19 AM To: Gray, Eric; Stewart Bryant Cc: ietf@ietf.org Subject: RE: Diagrams (Was RFCs should be distributed in XML) Very well stated!!! The ASCII-requirement is (apart from being a compact, generic, free, non-complex, document format) indirectly forcing people to really make diagrams simple, i.e. not put too much crap (complexity) in one single figure. After having had to read documents from other organisations people often cite as "SDO's", I am personally convinced that the good sides of using ASCII completely outweights the potential negative aspects. /L-E > Stewart, > > I suspect most people prefer reading documents that contain > diagrams, but anything that limits the complexity of a diagram - > especially for documents most often read on a computer screen - is > a feature, rather than a bug. > > If a diagram is included to communicate (rather than obscure) > an idea, then readers should be able to correlate descriptive text > to the diagram - either because the diagram is simple enough that > it is not necessary to keep referring to it, or because the entire > description can be viewed while looking at the diagram. > > Sometimes language limitations are a good thing, when they > are tied to specific ways of presenting information. > > -- > Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-ash-alt-formats-01.txt
Hi All, As a follow-up to our recent discussion, please review the draft at http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.txt, .pdf version available at http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.pdf. We propose an experiment based on RFC 3933 allowing, in addition to ASCII text as a normative input/output format, PDF as an additional normative output format. We look forward to your comments and suggestions. Thanks, Regards, Jerry, Stewart, Yaakov -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 31, 2006 10:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ash-alt-formats-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Experiment: Normative Format in Addition to ASCII Text Author(s) : J. Ash, et al. Filename: draft-ash-alt-formats-01.txt,.pdf Pages : 8 Date: 2006-1-31 Following RFC 3933, the authors propose an experiment allowing, in addition to ASCII text as a normative input/output format, PDF as an additional normative output format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-ash-alt-formats-02.txt
Hi All, Please see the updated draft "Proposed Experiment: Normative Format in Addition to ASCII Text" at http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.txt, .pdf version available at http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.pdf. The draft describes an RFC 3933 Process Experiment allowing normative PDF output be trialed for RFCs and I-Ds. As discussed in Section 3, documents in the Routing Area Working Group ([U-TURN]) and Network Time Protocol Working Group ([NTP-ALGORITHM]) will be progressed through IESG review and RFC Editor review in PDF format and also in ASCII format. The ASCII format version may be limited to text only and not include figures, diagrams, or equations. The method to progress the PDF format version is as specified in RFC2223bis http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt: "When the .pdf version is submitted with the .txt version, the RFC Editor will first edit the .txt version. The final form of the .txt version (or, when feasible, the diffs) will be returned to the author. The author must then update the .pdf files to match, as closely as possible, the content and format of the ASCII .txt file. When the RFC Editor agrees that the .pdf version is acceptable, it is published simultaneously with the .txt version." The IESG (shepherded by Bill Fenner, Routing AD) has agreed to proceed with the experiment. Please let us know of any comments or suggestions on the updated draft. Thanks, Jerry, Stewart, Yaakov -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ash-alt-formats-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Experiment: Normative Format in Addition to ASCII Text Author(s) : J. Ash, et al. Filename: draft-ash-alt-formats-02.txt,.pdf Pages : 9 Date: 2006-5-25 Following RFC 3933, the authors propose an experiment allowing, in addition to ASCII text as a normative input/output format, PDF as an additional normative output format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
> As the author notes, there was > indeed a replay > of the usual > discussion about RFC formats in winter 2006. The author > says, "... the > quite thoughtful, > extended, and detailed discussion ... resulted in no change". > There is a > reason it did > not result in change... there were cogent arguments against > all proposals > that were > made. Cogent arguments against? Very few people came out and said that we need nothing beyond ASCII art. OTOH, many supported the need for something better than archaic ASCII art/equations, given that almost all of us recognize the limitations of ASCII art/equations, generate/use complex graphics every day (in many formats), and very few of us generate/use stick figures beyond IETF. > So, when it has no good ideas, the IETF randomly picks > one of the bad > ones? > That is apparently happening here. > > How DID it get last called, by the way? If I write up a > arbitrary process > experiment, > will the IESG automatically last call it? Yummy. It is quite reasonable to last call this draft at this point. It has been reviewed for ~6 months. This version posted to the list for comments more than 3 weeks ago, plenty of time for more comments, but no comments were posted to the list on this version. In addition, you/RFC Editor were asked to comment on this version (before it was submitted), starting on May 5, but you did not comment. There was an exchange with the AD during this period regarding his concerns RE RFC Editor buy-in, but you still did not comment. We could have incorporated your comments into the LC version had we known them. > The experiment picks on two working groups and specifies > that for one year review > it will > treat the results of these working groups differently from all other > working group > output. Only 2 drafts are involved, and both WGs have agreed. Both of these drafts are good examples of where .pdf is preferable to ASCII art. > How will a future implementor know which version is > normative? At > present, > there is a simple rule... it is always the ASCII version. If > this exercise > goes > ahead, some PDF files (which ones?) will be normative, and some ASCII > files won't. I'm sure with all the brain power at hand we can solve that daunting riddle with another simple rule. > the I-D has some misleading > examples of > bad ASCII art. You cannot honestly prove that ASCII art is unusable > by abusing it. I spent a few minutes cleaning up the terrible example > in the I-D (Sorry, I am in Washington and don't have ready access to > it; I will forward it when I get back.) Yes please send us the competing ASCII diagrams. We can provide you with even more complex artwork/diagrams to convert to ASCII art -- this will allow you to further prove your point. > As Joel mentions, this experiment will have a negative impact on > RFC Editor throughput. Shouldn't the IAB and perhaps the IAD > have some part in this? .pdf is allowed now for drafts and RFCs. There are procedures in place for .pdf output. In fact, the proposed experiment uses exactly the same procedures followed now wrt RFC Editor processing of .pdf output documents. As stated in the draft: "These documents will be progressed through WG review, IESG review, and RFC Editor review and approval. The method to progress the PDF format version is as specified in [RFC2223bis]: When the .pdf version is submitted with the .txt version, the RFC Editor will first edit the .txt version. The final form of the .txt version (or, when feasible, the diffs) will be returned to the author. The author must then update the .pdf files to match, as closely as possible, the content and format of the ASCII .txt file. When the RFC Editor agrees that the .pdf version is acceptable, it is published simultaneously with the .txt version." Since these same procedures are specified in [RFC2223bis] http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt, authored by the RFC Editor, it is reasonable to assume they are OK for our experiment. It is also hard to see how these procedures will lead to more work for the RFC Editor given they are used now. In addition, tools can be developed to assist the authors and RFC editor if necessary. It is straightforward to specify required .pdf versions/formats if that is essential, as some have suggested (although there is no such requirement now on .pdf drafts and RFCs AFAIK). > For all the reasons that Joel said, plus the reasons I have given, I > request that the IESG reject this last call. At the very least, the > base document needs more work, and the implications need > more mature thought. And it seems to there is a badly broken > process lurking here. > > I am somewhat astonished that the IESG chose to last call > 'this document. It's quite legitimate to last call this (6 months of discussion, several weeks to comment on this version, etc.). I'm rather asto
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
John, > I continue to wonder whether what we should be doing here is not > to invent a new normative document format, but to figure out how > attach image-type figures to ASCII RFCs. "plates glued in the > back" is almost exactly the same as the analogy I have been > thinking about. This is a new output format, and previous suggestions for new input/output formats have not reached any agreement whatever -- there is every possible opinion expressed on what format to use or not to use, and why. IMO a big drawback of this approach is that figures (and equations) don't appear with the text, which is not easy to use. Also, your suggestion for a "figure supplement" to RFCs (with multiple figures in a single PDF? file) has the same drawback. The advantage of using PDF is that we already use it, for both drafts and RFCs, and have a lot of experience using it. For most people it seems to work just fine. IMO PDF is our best shot in IETF at solving the graphics and equations issues raised in the draft. > So, while I don't think this particular experiment, as > described, is plausible, there are two ideas I'd like to see > proposed, perhaps experimentally, for the future: > > (1) A PDF approach, but with PDF carefully researched and > profiled (to include searchability and copy-and-paste extraction > in addition to stability and very wide availability for readers > and formatters) and a back-out plan should the community not be > happy about the experimental results. Specifying profiles for PDF is fine, as long as there is agreement that it's necessary. > When I said "should not have been last-called" in a prior > note, I wasn't trying to suggest that the _idea_ was obviously > dead or bad. I was trying to suggest, instead, that, when an > idea is discussed at length on the IETF list and a number of > issues raised with it, it is normal for the IESG to insist that > any version of the idea that is subsequently to be last-called > address most of those issues in some substantive way. "We > don't see X as a problem" may be appropriate; pretending > (deliberately or by accidental omission) that X was not raised > or discussed as an issue is usually not. The fraction of the > Last Call discussion that essentially duplicates the discussions > of some months ago is probably testimony to the wisdom of that > principle. I think you're referring to the comment (from a couple of people) that the authors "ignored" a "consensus" to specify PDF profiles in the proposed experiment. However, we did not "ignore" anything. It was not clear to me (or the other co-authors) prior to the -02 version that there was any "consensus" RE specifying PDF profiles/formats/versions, a couple of people as I recall commented on that perhaps, among dozens of other suggestions. Which suggestions are we supposed to treat as consensus? It isn't up to any one individual to declare one comment or another comment as "consensus" and then charge the authors with ignoring the supposed "consensus" after the fact. If the authors agree to address a particular comment, OK, but we didn't get that far in the discussion of the -01 draft leading up to the -02 draft. Also, no additional comments were made during the 3-week comment period on the -02 draft before last call was initiated; there was time to raise the comment again. In any case, it is OK to specify profiles/versions/features in the next revision if there is agreement. It is a last call comment that can be incorporated in the -03 version. Jerry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
John, > > The advantage of using PDF is that we already use it, for both > > drafts and RFCs, and have a lot of experience using it. For > > most people it seems to work just fine. IMO PDF is our best > > shot in IETF at solving the graphics and equations issues > > raised in the draft. > Good. I actually agree, albeit very tentatively, that it is our > best shot. But I believe that saying "PDF" isn't adequate and > that a lot of work has to be done and specified before we are > able to use it as a normative or exclusive form for archival RFC > documents. ... > Note 1: I believe that constraints are imposed on _any_ > normative publication format for the IETF by the way we use > these documents. In particular, I believe that for files > containing the text of the specifications, searchability and > extractability are absolutely critical. One thing almost all > of those of us who have used PDF know is that some files have > those properties while others, often referred to as PDF image > files, do not.As soon as one gets to "need to be able to > search", then it is necessary to profile PDF so that the right > sorts of files appear. And, as I think Bob Braden pointed out, > one also has to have the tools in place to verify that. > > It is reasonable for you to disagree with the main premise of > the above paragraph, i.e., you may believe that we can dispense > with searching and extraction. If so, I would encourage you to > say that, since it would make the PDF profiling problem much > easier. My personal guess is that you would find it quite hard > to sell to the IETF community, but that is just a guess. Of course I believe that searching and extraction from PDF is highly desirable. However I think that is probably not easy, and it's likely that most people can't generate such searchable/extractable PDF files. I also doubt that searchable/extractable PDF is the secret sauce that will suddenly lead to agreement on this list. Besides the beatings administered RE the proposed experiment, we've seen the usual myriad proposals all over again. Based on these discussions, it's hard to see how any way forward other than "do nothing" will fly. Hopefully the IESG, in spite of the discussions, will propose a viable way forward. > Note 2: Unlike some others on the IETF list, I recognize the > importance of having illustrations in better-than-ASCII forms. > We may disagree on how often it is important, or even on whether > "important" should be a criterion or the criterion should be > closer to "convenience". I am nonetheless very sympathetic to > the arguments that fancy illustrations often hide fuzzy thinking > while the discipline of producing ASCII line art tends to > clarify thinking and encourage simplicity in design. Perhaps as > a result of those possible disagreement, we might disagree on > the relevance of ASCII versions of text and ASCII approximations > to the more advanced, image-type, illustrations. But we at > least share the belief that there is a problem in this area that > should be solved. I am not positive that even that position has > IETF community consensus. It's good that a key person such as yourself sees a problem that needs solving. Hopefully we'll find a way forward to solve the problem. Thanks, Regards, Jerry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
