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
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: 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 astonished that you ignored specific requests to comment on
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: 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
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: 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
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: 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
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. %%
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 david we end up with extensions that duplicate existing IETF
