Re: cApitalization
Trust me, you're better off not having done this or any other name chicanery. My full name is Edwin Earl Freed (after my uncle), and the hiccups caused by people not knowing Ned is a nickname for Edwin long ago ceased to be in any way amusing. I thought the nickname for Edwin was Buzz :-) Ross (who had always thought that Ned was a(nother) nickname for Edward) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Hi Sam, I wish you had approached the PANA WG first to get clarification on your concerns and questions. And I wish the responsible AD had said go to PANA WG rather than don't go there when you consulted him. Even after the PANA WG was chartered, we went through your suggested exercise twice with our AD (Thomas Narten), and got the problem statement approved in RFC 4058. No conditions have changed since than, so I am not sure why we need to go through this exercise again at this stage (the protocol documents passed AD review and getting readied for IESG review). I am sure if you ask a broad question like who is confused about a given protocol, you'd always have many positive answers -- for various reasons. Not sure if this is helpful. Having basic knowledge about network access authentication and EAP is a prerequisite for anyone to understand what PANA really does. And for the question of where it would be used... One answer is already in the IETF NEA BoF. It calls for EAPoverL3 transport. And the other answer is in the DSL networks. If you have access to DSL Forum documents, I recommend you look at dsl2006.174.02. The document lists requirements for network access authentication protocol. PANA is a documented candidate and in fact it is the only one that satisfies all of the requirements. I hope these answer your concerns. Alper -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 8:12 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: The Emperor Has No Clothes: Is PANA actually useful? Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community
Tracking IPR (Re: RFC Author Count and IPR)
Just one note on this long thread: At present, the IETF secretariat does *not* attempt to track who has copyright rights on what parts of the text. Neither, as far as I know, does anyone else (WG chair or editors), apart from following the RFC 2026 rule that significant contributions should be acknowledged - this is commonly done by Authors, Contributors and Acknowledgement sections, which rarely point to specific pieces of text. Claiming that we track copyrights on pieces of text, and then not doing it, would, in my opinion, be extremely stupid for multiple reasons. So I want to make it perfectly clear that the IETF is NOT doing this. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
Bob Braden wrote: * * I am concerned that the current RFC Editor practice that limits the * number of authors is in conflict with the IETF IPR policies. The RFC * Editor currently limits the author count to five people. Recent IPR * WG discussions make it clear to me that authors retain significant copyright. Note that the number 5 is not magic here. When the phenomenon of balooning lists of authors (say, one or more from every telecom vendor you ever heard of) was first noticed, there was a discussion on the IETF list. The community consensus was that author list inflation was un-IETF. I don't recall the details (there may have been a last call from the IESG, but I am not sure), but it was left to the RFC Editor to formulate the precise guideline. The Last Call on draft-rfc-editor-author-lists was issued on May 20, 2002, and the IESG approved that document on August 27, 2002, according to the tracker: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=8778rfc_flag=0 On Jan 3, 2005, it was marked dead based on the fact that the text had been incorporated into the 2223bis draft. So it's been almost 4 years since IETF consensus was declared for this policy. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
Lucy E. Lynch wrote: Let me try re-stating my question. Is there a one-to-one relationship between the listed authors on an IETF document and ownership of the given document's Intellectual Property? I can answer that one... No. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-alvestrand-ipod-01.txt
Note: The IPOD draft says that these notes can be approved by multiple entities - I did not see any reason to insist that the mechanism impose a further burden on the IESG for *every* document that needs to be issued in the course of IETF operations. So the reason for the IETF in IETF Operational Notes is related to the IETF, not approved by the IETF. Much like the way Internet Engineering Task Force is related to the Internet, not approved by the Internet.. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Call for Entries, Deadline 15th June 2006
Call for Entries After the major success of 'Young ART' 2005 and 'Project Calendar' 2006, artExperiments.com is presenting a series of five international curated exhibition 'Expressions in miniature size' is first to start from the series.'Expressions in miniature size' is an inaugural annual event, from the series of international curated exhibitions by artEperiments.com in association with Waves Art Gallery. _expression_ can never be judged by the scale, but by its depth and intensity. Art in miniature size is like the Japanese 'Haiku' where the saturation is at optimum of ones _expression_, and is sometimes has a lasting impact. We intend to call entries from the artists all over the world, and at least 20 entries will be selected by artist/curator Raju Sutar for a physical as well as online exhibition, along with a catalogue to be printed of the select exhibits. In case of more selections the exhibition will be held in sequence like 'I II' Waves Art Gallery is located in Pune (INDIA), a city that is known to be the city of knowledge and culture. Our endeavor is to bring out the best possible works of art, to understand the growth of the contemporary art. Eligibility Any artist from any country can participate, provided: Art works falling under the category of painting, graphic, drawing, collage etc. except photography, installation and sculpture. Size not more than 30 X 30 cms inclusive of frame. Note: Processing fees INR 100/- or $ 2.5 per application (up to three images) Please submit your entries at www.artexperiments.com online! Deadline 15th June 2006. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LC on draft-mankin-pub-req-08.txt
Reading this, a few items caught my eye. The POSTEDIT requirements seem to be worded as if it is desirable to minimize the changes that the document editor makes, or even the changes the document editor can make. The general tone of don't mess with the words we have carefully honed is understandable. However, in practice many of the words have not been carefully honed. And they need to be. For example, there is a document I just reviewed to which my personal reaction is this needs massive editing. It is not technically wrong. But the language use makes it hard for the reader to understand what is intended. I would sincerely hope that if it is approved as-is by the IESG that the RFC Editor would edit the document. In general the editor has little or no way to tell which words are carefully crafted. I would hate to have a presumption that all the words a sacrosanct. I realize that the text calls out the special case of don't touch a letter of this, and even acknowledges that it is a rare case. But the wording of the earlier text is not in line with that. Specifically, POSTEDIT-4 reads The IETF Technical editor should refrain from changes to improve readability that may change technical and consensus wording. This appears to be a directive that prohibits almost all changes, since in a formal sense all the words in an WG and IETF LC approved document are consensus wording. That leads to what I consider a bad situation where we have essentially prohibited the editor from editing. On a related note, POSTEDIT-3 seems to be inadvertently worded too strongly. It prohibits changes which introduce a substantial review load but only provides incremental increase in the clarity of the specification. However, by definition any change at all, even a significant change that transforms a document from unintelligible to highly readable, is always an incremental increase in the clarity of the specification. With regard to the metrics, I think that it would be helpful to separate the notion of having metrics from the specific values. I would suggest moving the specific values to an appendix, with a notation that these values are advisory and based on IETF perception at the time of writing. I don't want to lose the numbers, but I think that they have a different status as requirements than the point that these time frames should be tracked, and should have well understood targets. Separating this also allows for negotiation of cost-benefit tradeoffs without violating requirements. As a minor matter, figure one is trying to make a useful statement, but one of the headings caused me to have to spend more time staring at the figure, rather than making things clearer. In the row labeled Actors, WGLC and IETF LC appear. Those are states, not actors. Also, the action listed (Formal Reviewing) does not, as far as I know, currently occur during those phases. The formal reviewing occurs after IETF LC ends, during IESG deliberations. Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
See inline. Stephen Hayes -Original Message- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 3:17 PM To: ietf@ietf.org Subject: Re: LC on draft-mankin-pub-req-08.txt Reading this, a few items caught my eye. The POSTEDIT requirements seem to be worded as if it is desirable to minimize the changes that the document editor makes, or even the changes the document editor can make. The general tone of don't mess with the words we have carefully honed is understandable. However, in practice many of the words have not been carefully honed. And they need to be. For example, there is a document I just reviewed to which my personal reaction is this needs massive editing. It is not technically wrong. But the language use makes it hard for the reader to understand what is intended. I would sincerely hope that if it is approved as-is by the IESG that the RFC Editor would edit the document. In general the editor has little or no way to tell which words are carefully crafted. I would hate to have a presumption that all the words a sacrosanct. I realize that the text calls out the special case of don't touch a letter of this, and even acknowledges that it is a rare case. But the wording of the earlier text is not in line with that. Specifically, POSTEDIT-4 reads The IETF Technical editor should refrain from changes to improve readability that may change technical and consensus wording. This appears to be a directive that prohibits almost all changes, since in a formal sense all the words in an WG and IETF LC approved document are consensus wording. That leads to what I consider a bad situation where we have essentially prohibited the editor from editing. On a related note, POSTEDIT-3 seems to be inadvertently worded too strongly. It prohibits changes which introduce a substantial review load but only provides incremental increase in the clarity of the specification. However, by definition any change at all, even a significant change that transforms a document from unintelligible to highly readable, is always an incremental increase in the clarity of the specification. Although the wording could be tuned to be more permissive, it's not possible to satisfy everybody with the POSTEDIT requirements. People just tend to end up at slightly different places along the how much the technical publisher should do curve. People can point to examples with badly written documents that needed considerable clean-up or examples where changes were done that added little overall benefit to a document. The natural tendency of a technical publisher will be to improve documents, since to a large degree they view themselves as responsible for the output quality. The current highly restrictive wording was selected to counterbalance that tendency. The current wording also reflects that I heard more complaints about too much editing than not enough editing. With regard to the metrics, I think that it would be helpful to separate the notion of having metrics from the specific values. I would suggest moving the specific values to an appendix, with a notation that these values are advisory and based on IETF perception at the time of writing. I don't want to lose the numbers, but I think that they have a different status as requirements than the point that these time frames should be tracked, and should have well understood targets. Separating this also allows for negotiation of cost-benefit tradeoffs without violating requirements. I agree, the requirements to keep metrics and the recommended values for metrics are different and should be distinguished in some way. I am not sure an appendix is the best way, but some separation is needed. As a minor matter, figure one is trying to make a useful statement, but one of the headings caused me to have to spend more time staring at the figure, rather than making things clearer. In the row labeled Actors, WGLC and IETF LC appear. Those are states, not actors. Also, the action listed (Formal Reviewing) does not, as far as I know, currently occur during those phases. The formal reviewing occurs after IETF LC ends, during IESG deliberations. I guess some minor surgery would be to change WGLC-WG, IETF LC- IETF, and Formal Reviewing- Reviewing. Yours, Joel M. Halpern ___ 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
'help'
PROTECTED] Cc: ipr-wg@ietf.org, Bob Braden [EMAIL PROTECTED], ietf@ietf.org, techspec@ietf.org, rfc-editor@rfc-editor.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Lucy E. Lynch wrote: Let me try re-stating my question. Is there a one-to-one relationship between the listed authors on an IETF document and ownership of the given document's Intellectual Property? I can answer that one... No. -- Message: 6 Date: Thu, 25 May 2006 10:54:33 +0200 From: Harald Alvestrand [EMAIL PROTECTED] Subject: Re: I-D ACTION:draft-alvestrand-ipod-01.txt To: John C Klensin [EMAIL PROTECTED] Cc: ietf@ietf.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Note: The IPOD draft says that these notes can be approved by multiple entities - I did not see any reason to insist that the mechanism impose a further burden on the IESG for *every* document that needs to be issued in the course of IETF operations. So the reason for the IETF in IETF Operational Notes is related to the IETF, not approved by the IETF. Much like the way Internet Engineering Task Force is related to the Internet, not approved by the Internet.. Harald -- Message: 7 Date: Thu, 25 May 2006 13:43:12 +0530 From: Raju Sutar [EMAIL PROTECTED] Subject: Call for Entries, Deadline 15th June 2006 To: ietf@ietf.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 *Call for Entries * After the major success of 'Young ART' 2005 and 'Project Calendar' 2006, artExperiments.com is presenting a series of five international curated exhibition *'Expressions in miniature size' *is first to start from the series. 'Expressions in miniature size'* *is an inaugural annual event, from the series of international curated exhibitions by artEperiments.com in association with Waves Art Gallery. Expression can never be judged by the scale, but by its depth and intensity. Art in miniature size is like the Japanese 'Haiku' where the saturation is at optimum of ones expression, and is sometimes has a lasting impact. We intend to call entries from the artists all over the world, and at least 20 entries will be selected by artist/curator Raju Sutar for a physical as well as online exhibition, along with a catalogue to be printed of the select exhibits. In case of more selections the exhibition will be held in sequence like 'I II' Waves Art Gallery is located in Pune (INDIA), a city that is known to be the city of knowledge and culture. Our endeavor is to bring out the best possible works of art, to understand the growth of the contemporary art. *Eligibility* Any artist from any country can participate, provided: - Art works falling under the category of painting, graphic, drawing, collage etc. except photography, installation and sculpture. - Size not more than 30 X 30 cms inclusive of frame. Note: Processing fees INR 100/- or $ 2.5 per application (up to three images) Please submit your entries at *www.artexperiments.com* online! Deadline 15th June 2006. -- next part -- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/ietf/attachments/20060525/0e9ac6d5/attachment.html -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf End of Ietf Digest, Vol 25, Issue 34 winmail.dat___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
On Thu, 25 May 2006, Harald Alvestrand wrote: Lucy E. Lynch wrote: Let me try re-stating my question. Is there a one-to-one relationship between the listed authors on an IETF document and ownership of the given document's Intellectual Property? I can answer that one... No. Thank you! -- Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
L2, The IETF's policy here has a couple of problems I think - and that is that it limits the number of parties that can claim control over a document and in doing so limits the representation of legal ownership or rights to the filing. This is a very bad thing, since each of those authors has legal control over their portions of the work or derivatives of their contribution within the work itself. I.e. they are all legal signatories to any conveyance of copyrights or derivative use rights including implementaiton rights. It also seems to limit who can converse with the Secretariat or WG in regard to the management of any particular Document's Initiative which may prevent legitimate IP owners from interacting with the IETF's processes. Perhaps we need to apply the same standards to these that are applied to US Patents, and BTW did you know that a person licensing someone to use a patent can revoke that license for cause 20 years later... that is an important statement since it means that anything can be pulled out from under anyone these days. The use of the IP for reprinting is Copyright controlled - but the implementation of actual code or a 'system from the description' is more specific to patent protection and should be dealt with as such since it is not 'republication' but commercial/private use of the described IP that is being dealt with. The point is that the IP Control and Transfer model is to complex and needs to be made simpler if the Trust idea is to work at all IMHO. For instance, you have a piece of IP that is patented and there are four listed Inventor's - that has very specific rights attached to it and it generally similar if not the same for Author's of copyrighted works. And for this example say one of those Four Inventor's is dissatisfied with a buy-out or other matter and decides to rescind the transfer of the IP... there are of course legal issues and processes to be addressed, but it does happen. The point is that in any IP licensing model its critical to get continuing agreement as to the intent and willingness of the AUTHORS/INVENTORS to continue participating and that means that there needs to be an ongoing process for getting that formal release. Say a RFC for instance was derived from a document that had four authors and one of them decided to leave the Vetting Team that submitted the document (notice also I snuck a new Governance term in - Vetting Team)... Now when each revision to that I-D that is done the same four people would have to agree to the ongoing license to use, which the one who left can clearly say no to... What does this cause? nothing inside the IETF since its use rights are protected by the Research Exemptions but anyone else? could be messy. Todd - Original Message - From: Lucy E. Lynch [EMAIL PROTECTED] To: Harald Alvestrand [EMAIL PROTECTED] Cc: ipr-wg@ietf.org; Bob Braden [EMAIL PROTECTED]; ietf@ietf.org; techspec@ietf.org; rfc-editor@rfc-editor.org Sent: Thursday, May 25, 2006 6:42 AM Subject: Re: [Techspec] RFC Author Count and IPR On Thu, 25 May 2006, Harald Alvestrand wrote: Lucy E. Lynch wrote: Let me try re-stating my question. Is there a one-to-one relationship between the listed authors on an IETF document and ownership of the given document's Intellectual Property? I can answer that one... No. Thank you! -- Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ipr-wg mailing list Ipr-wg@ietf.org https://www1.ietf.org/mailman/listinfo/ipr-wg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
--On Thursday, 25 May, 2006 07:18 -0500 Stephen Hayes (TX/EUS) [EMAIL PROTECTED] wrote: See inline. Stephen Hayes -Original Message- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 3:17 PM To: ietf@ietf.org Subject: Re: LC on draft-mankin-pub-req-08.txt ... Although the wording could be tuned to be more permissive, it's not possible to satisfy everybody with the POSTEDIT requirements. People just tend to end up at slightly different places along the how much the technical publisher should do curve. People can point to examples with badly written documents that needed considerable clean-up or examples where changes were done that added little overall benefit to a document. The natural tendency of a technical publisher will be to improve documents, since to a large degree they view themselves as responsible for the output quality. The current highly restrictive wording was selected to counterbalance that tendency. The current wording also reflects that I heard more complaints about too much editing than not enough editing. Stephen, I routinely complain about too much editing -- if not on every document I submit for RFC publication, at least most of them. I believe that, in the last couple of years there has been a trend toward more editing that I consider gratuitous, e.g., changing one correct and consistent style to another one. So I may well be the source of some of the complaints you heard. On the other hand, I'm appalled by the editorial and presentation quality of some of the documents that I've seen go to the RFC Editor, even after Last Call and IESG signoff. In my opinion, absent something that the document skirts, the current highly restrictive reading goes much too far. Yes, I understand the desire to counterbalance both natural tendencies and some history of over-editing. But, to the extent to which this document is expected, post-last-call, to form part of the basis for solicitation of people who are interested in doing the job and selection from among those people, and then of a contract with the selected party, I believe it goes _much_ too far: that degree of restrictiveness is simply not what we want or need, IMO. The exception case mentioned above would involve a shift to doing substantially all editing prior to IETF Last Call and doing it again if textual changes are made after Last Call, so that the document that is approved is the document that is published. That is more or less the practice in a number of other standards bodies. For reasons of both cost and process, it has never been embraced here and I don't take anything in TechSpec as either forcing that model or as otherwise assuring that documents that come into the process are of a quality that would justify very restrictive text about post-editing. regards, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
(several lists deleted) --On Thursday, 25 May, 2006 10:44 +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: The Last Call on draft-rfc-editor-author-lists was issued on May 20, 2002, and the IESG approved that document on August 27, 2002, according to the tracker: https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=8778rfc_flag=0 On Jan 3, 2005, it was marked dead based on the fact that the text had been incorporated into the 2223bis draft. So it's been almost 4 years since IETF consensus was declared for this policy. Since, as I understand it, completion and publication of 2223bis has been put on indefinite hold, is it time to dust off draft-rfc-editor-author-lists and publish it? Also, since we have a last call on the IPOD/ION draft in effect, could you, Harald, walk us quickly through how you would see this situation being untangled, or handled in a more clear way, were the ION series in effect? Would the content of draft-rfc-editor-author-lists fall into that series? Would 2223bis? john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
On Thu, 25 May 2006, [EMAIL PROTECTED] wrote: On Thu, May 25, 2006 at 06:42:06AM -0700, Lucy E. Lynch wrote: On Thu, 25 May 2006, Harald Alvestrand wrote: Lucy E. Lynch wrote: Let me try re-stating my question. Is there a one-to-one relationship between the listed authors on an IETF document and ownership of the given document's Intellectual Property? I can answer that one... No. Thank you! Lucy E. Lynch Academic User Services not knowing Harolds legal background or current standing w/ the ABA, (or EU equivalent) I think that Bob's recommendation on getting actual legal advice on your question puts you and the organziation represented (IETF) on much better grounding than a simple; I can answer that... no on an email list. just my (uninformed) opinion. Bill - Understood, as I say, I'm just trying to get a handle the range of community opinion(s) and the scope of the problem. This issue cuts across TechSpec, the IPR WG, the RFC-Editor's office, and the IETF Trust (as well as individual authors etc.). Everyone sees this slightly differently. Before we ask for advise, I'd like to understand the problem set. --bill -- Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Comments on draft-iab-rfc-editor: IETF control
I finished reading the RFC editor document and have one major concern. Ultimately, the rfc-editor function needs to be accountable to the IETF community because we're the ones paying for it. In particular I believe that the IETF should be able to pass a BCP placing requirements on an rfc-editor stream. We've done this with RFC 3932 for example, and I think that was a good thing. In effect, community consensus within the IETF should trump anything else. Now, we need to be careful about how to use that consensus. Several RFC streams serve communities broader than the IETF. Unless we have good reason to do so, we should not step on those communities by overriding their requirements. I also have specific concerns about how this document interacts with the IAOC and IASA. 1) The document gives the IAB the authority to terminate the rfc-editor contract. Depending on when we do that, there may be significant budget impacts and it may not be consistent with ISOC's carrying out its financial responsibilities to terminate the rfc-editor contract at an arbitrary point in time. 2) The document allows the IAB to create new streams of rfcs on its own authority. It seems that we need ISOC and IAOC approval at least on the budget question to do so. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
At 05:07 PM 5/24/2006, Vijay Devarapallli wrote: On 5/24/06, Lakshminath Dondeti [EMAIL PROTECTED] wrote: ** EAP over IKEv2 seems like a more viable alternative: apparently being proposed in 3G-WLAN interworking scenario as the access auth protocol. the 3G-WLAN interworking scenario is similar to an enterprise user gaining access to the enterprise via an IPsec gateway. a user who is subscribed to a mobile operator's services uses IKEv2 with a VPN-like gateway to access the operator's services. the mode is different. therefore I don't think this is an alternative to PANA and shouldn't be confused with PANA. we could discuss this more, but on a separate thread. Vijay /x-flowed Hi, I guess there are differences in our understanding of 3G-WLAN interworking (and I could be wrong), but the point is that they (plan to) use EAP over IKEv2. We can try and debate the details offline, as that is not central to the discussion here. regards, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
I have reviewed the PANA framework document, the PANA protocol spec, and the PANA/IPsec document. After reading all these documents, I still do not understand why PANA is useful. The PANA framework document claims that it can be used along with IEEE 802.11i. However, IEEE 802.11 reviewed the document, and came to a different conclusion: http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-IETF-PANA.doc The other potential scenario outlined by the framework document is use along with IPsec. However, IKEv2 already supports EAP authentication, so I don't understand why PANA would be used for that scenario instead of IKEv2. I do understand the potential need for EAP to be encapsulated over IP. However, in practice PANA is more complex than EAP over UDP (see draft-thomson-nacp-02.txt), which looks like it is on the road to becoming the defacto standard for EAP encapsulation over IP. So from what I can tell, in each potential usage scenario PANA is either not feasible, is more complex than an established alternative, or has been rejected by the SDOs that have examined it. --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: IETF Calendar 2008 - 2010 Ver 02
This is a Last Call for feedback on Version 02 proposed 2008 - 2010 IETF Meeting dates. The IAOC anticipates taking action to formally adopt dates on 1 June. These dates differ from the version 01 dates based upon community feedback, a review of meeting dates of those organizations on the Clash List and maintenance of a reasonably similar period between meetings. While every effort was made to avoid conflicts where known, it was not always possible with those organizations in the should avoid category and on many occasions the IETF meetings are back to back with the IEEE Plenaries. Future location decisions will take into consideration the location of other organization meetings with which the community interacts. Your feedback to [EMAIL PROTECTED] on conflicts with these dates would be appreciated. Proposed 2008 - 2010 meeting dates: 2008 IETF 71 Mar 23 - 28 IETF 72 Jul 27 - Aug 1 IETF 73 Nov 16 - 21 2009 IETF 74 Mar 22 - 27 IETF 75 Jul 26 - 31 IETF 76 Nov 8 - 13 2010 IETF 77 Mar 21 - 26 IETF 78 Jul 25 - 30 IETF 79 Nov 7 - 12 The schedules of other organization's meetings as known can be found at: http://www.ietf.org/meetings/events.cal.html. Thanks for your continuing assistance. Ray Pelletier IAD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Sam, Some high-level responses, and I'm sure we'll hear other input: 1/ I think you're overlooking something in IETF pays for RFC Editor; RFC Editor has been paid by ISOC for years, and *that* largely comes out of contributions from corporations. We actually have no data beyond the fact that they support the RFC Editor as currently constituted (i.e., including independent submissions). We've already heard (in IETF discussion in March) input that no in fact the IETF does not get to define the *in*dependent submission process; one purpose of the planned discussion is to ensure that the process is not at odds with the IETF's standards needs, but that is very different than having the IETF define it, as you describe. 2/ Termination of any contract is always going to be based on terms in said contract. I assume ISOC BoT wouldn't approve something that leaves them with dangerous exposure; that's what they do. This document is aiming to capture the principle of the IAB's responsibility; the counter example is not right, either (the IASA giving the IAB/IETF the news that there is a new RFC Editor in town). 3/ Re. approval of ISOC BoT/IASA for creation of new streams: we need to be careful with terminology. The IASA exists to implement adminstrative support to meet the needs of the IETF IAB IRTFs needs. Leslie. Sam Hartman wrote: I finished reading the RFC editor document and have one major concern. Ultimately, the rfc-editor function needs to be accountable to the IETF community because we're the ones paying for it. In particular I believe that the IETF should be able to pass a BCP placing requirements on an rfc-editor stream. We've done this with RFC 3932 for example, and I think that was a good thing. In effect, community consensus within the IETF should trump anything else. Now, we need to be careful about how to use that consensus. Several RFC streams serve communities broader than the IETF. Unless we have good reason to do so, we should not step on those communities by overriding their requirements. I also have specific concerns about how this document interacts with the IAOC and IASA. 1) The document gives the IAB the authority to terminate the rfc-editor contract. Depending on when we do that, there may be significant budget impacts and it may not be consistent with ISOC's carrying out its financial responsibilities to terminate the rfc-editor contract at an arbitrary point in time. 2) The document allows the IAB to create new streams of rfcs on its own authority. It seems that we need ISOC and IAOC approval at least on the budget question to do so. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Leslie == Leslie Daigle [EMAIL PROTECTED] writes: Leslie Sam, Leslie Some high-level responses, and I'm sure we'll hear other Leslie input: Leslie 1/ I think you're overlooking something in IETF pays for Leslie RFC Editor; RFC Editor has been paid by ISOC for years, Leslie and *that* largely comes out of contributions from Leslie corporations. We actually have no data beyond the fact Leslie that they support the RFC Editor as currently constituted Leslie (i.e., including independent submissions). Leslie We've already heard (in IETF discussion in March) input Leslie that no in fact the IETF does not get to define the Leslie *in*dependent submission process; one purpose of the Leslie planned discussion is to ensure that the process is not at Leslie odds with the IETF's standards needs, but that is very Leslie different than having the IETF define it, as you describe. OK. I was not paying that much attention in March,and if I'm too late, I certainly have no problem with the community choosing to allow a broader group to control the independent submission track, or to seed that to the IAB. I think though that the community ultimately needs to have the power to take back anything it has given. Basically, I think it is critical that ultimately everything within the greater IETF context be accountable to the IETF community. That is true of the IESG, the IAB and everything they do. I don't think this document represents that. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Howdy, I think though that the community ultimately needs to have the power to take back anything it has given. Basically, I think it is critical that ultimately everything within the greater IETF context be accountable to the IETF community. That is true of the IESG, the IAB and everything they do. I don't think this document represents that. It is, at its heart, an -00 :-) Let's work on trying to fix the text before assuming the whole structure is wrong. Let's set aside *which* community for a moment (IETF community or something larger) and work on making sure the document is clear where the IAB makes decisions versus where it facilitates the detection of and action upon consensus. Can you propose some text improvements? Leslie. Sam Hartman wrote: Leslie == Leslie Daigle [EMAIL PROTECTED] writes: Leslie Sam, Leslie Some high-level responses, and I'm sure we'll hear other Leslie input: Leslie 1/ I think you're overlooking something in IETF pays for Leslie RFC Editor; RFC Editor has been paid by ISOC for years, Leslie and *that* largely comes out of contributions from Leslie corporations. We actually have no data beyond the fact Leslie that they support the RFC Editor as currently constituted Leslie (i.e., including independent submissions). Leslie We've already heard (in IETF discussion in March) input Leslie that no in fact the IETF does not get to define the Leslie *in*dependent submission process; one purpose of the Leslie planned discussion is to ensure that the process is not at Leslie odds with the IETF's standards needs, but that is very Leslie different than having the IETF define it, as you describe. OK. I was not paying that much attention in March,and if I'm too late, I certainly have no problem with the community choosing to allow a broader group to control the independent submission track, or to seed that to the IAB. I think though that the community ultimately needs to have the power to take back anything it has given. Basically, I think it is critical that ultimately everything within the greater IETF context be accountable to the IETF community. That is true of the IESG, the IAB and everything they do. I don't think this document represents that. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
John Klensin wrote: Stephen, I routinely complain about too much editing -- if not on every document I submit for RFC publication, at least most of them. I believe that, in the last couple of years there has been a trend toward more editing that I consider gratuitous, e.g., changing one correct and consistent style to another one. So I may well be the source of some of the complaints you heard. On the other hand, I'm appalled by the editorial and presentation quality of some of the documents that I've seen go to the RFC Editor, even after Last Call and IESG signoff. In my opinion, absent something that the document skirts, the current highly restrictive reading goes much too far. Yes, I understand the desire to counterbalance both natural tendencies and some history of over-editing. But, to the extent to which this document is expected, post-last-call, to form part of the basis for solicitation of people who are interested in doing the job and selection from among those people, and then of a contract with the selected party, I believe it goes _much_ too far: that degree of restrictiveness is simply not what we want or need, IMO. Do you have any suggested text? What I am hearing is something like be frugal in changes except when the document needs it, which IMHO doesn't seem to help. Stephen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
After some consideration, I can understand how the current text in mankin-pub-req would be discouraging to the technical publisher. If we changed refrain from to exercise restraint in making in requirements POSTEDIT-3 and POSTEDIT-4, I assume this would solve Joel and John's concerns. The question now is if I will get shot from the keep your grubby hands off my document crowd. Stephen -Original Message- From: Stephen Hayes (TX/EUS) [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 8:01 PM To: John C Klensin Cc: Joel M. Halpern; ietf@ietf.org Subject: RE: LC on draft-mankin-pub-req-08.txt John Klensin wrote: Stephen, I routinely complain about too much editing -- if not on every document I submit for RFC publication, at least most of them. I believe that, in the last couple of years there has been a trend toward more editing that I consider gratuitous, e.g., changing one correct and consistent style to another one. So I may well be the source of some of the complaints you heard. On the other hand, I'm appalled by the editorial and presentation quality of some of the documents that I've seen go to the RFC Editor, even after Last Call and IESG signoff. In my opinion, absent something that the document skirts, the current highly restrictive reading goes much too far. Yes, I understand the desire to counterbalance both natural tendencies and some history of over-editing. But, to the extent to which this document is expected, post-last-call, to form part of the basis for solicitation of people who are interested in doing the job and selection from among those people, and then of a contract with the selected party, I believe it goes _much_ too far: that degree of restrictiveness is simply not what we want or need, IMO. Do you have any suggested text? What I am hearing is something like be frugal in changes except when the document needs it, which IMHO doesn't seem to help. Stephen ___ 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: The Emperor Has No Clothes: Is PANA actually useful?
Hi Bernard, -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 4:46 PM To: ietf@ietf.org Subject: Re: The Emperor Has No Clothes: Is PANA actually useful? I have reviewed the PANA framework document, the PANA protocol spec, and the PANA/IPsec document. After reading all these documents, I still do not understand why PANA is useful. Just below you are acknowledging the need for EAP over IP. I don't understand how you can still claim you don't understand why PANA is useful... The PANA framework document claims that it can be used along with IEEE 802.11i. However, IEEE 802.11 reviewed the document, and came to a different conclusion: http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response- IETF-PANA.doc This is an inaccurate reading of the IEEE response (and you are the liaison). You are aware that virtual open-access AP mode is OK. One of the two alternatives we proposed had an issue, and the other one still holds. The other potential scenario outlined by the framework document is use along with IPsec. However, IKEv2 already supports EAP authentication, so I don't understand why PANA would be used for that scenario instead of IKEv2. You had commented on that earlier and I had explained it. http://www1.ietf.org/mail-archive/web/pana/current/msg02234.html. If not clear, please follow up from there (we don't need to go back to your original question). I do understand the potential need for EAP to be encapsulated over IP. Thank you. However, in practice PANA is more complex than EAP over UDP (see draft-thomson-nacp-02.txt), which looks like it is on the road to becoming the defacto standard for EAP encapsulation over IP. De-facto? Could you please elaborate how it is becoming a de-facto standard? Besides. Of course PANA is more complex than EAPoUDP. The latter (an individual I-D) has very limited applicability. If it were to handle mobility and wireless, it'll also grow in complexity. Just to get some sense of it, compare 802.1X and 802.11r. So from what I can tell, in each potential usage scenario PANA is either not feasible, is more complex than an established alternative, or has been rejected by the SDOs that have examined it. Which SDOs? Please give us more detail. Thank you. Alper --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to
RE: The Emperor Has No Clothes: Is PANA actually useful?
Just below you are acknowledging the need for EAP over IP. I don't understand how you can still claim you don't understand why PANA is useful... The framework doesn't seem to talk much about simple EAP over IP scenarios, so I have assumed this is not the major focus. You are aware that virtual open-access AP mode is OK. One of the two alternatives we proposed had an issue, and the other one still holds. Right. I was referring only to the WPA/WPA2 scenarios. De-facto? Could you please elaborate how it is becoming a de-facto standard? EAP over UDP is one of the foundation technologies for Network Endpoint Assessment (NEA). As I understand it, EAPoUDP is being made available on most operating systems, and is in the process of being deployed by many enterprise customers. Besides. Of course PANA is more complex than EAPoUDP. The latter (an individual I-D) has very limited applicability. As I understand it, EAP over UDP is mostly being deployed for wired access scenarios where IEEE 802.1X might not work well (e.g. multiple hosts sharing a port). Which SDOs? Please give us more detail. As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has evaluated the PANA framework document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
--On Thursday, 25 May, 2006 20:27 -0500 Stephen Hayes (TX/EUS) [EMAIL PROTECTED] wrote: After some consideration, I can understand how the current text in mankin-pub-req would be discouraging to the technical publisher. If we changed refrain from to exercise restraint in making in requirements POSTEDIT-3 and POSTEDIT-4, I assume this would solve Joel and John's concerns. Yes, from my standpoint, that would be a very significant improvement. The question now is if I will get shot from the keep your grubby hands off my document crowd. One hopes not. But that question is, of course, intimately related to whether there is actually a plausible pre-approval editing process (not just a suggestion process to editors, but actual definitive editing). If there is no such process, then, for some very significant number of cases keep your hands off my document would be equivalent to publish ungrammatical, badly-written and badly-organized trash. And I don't think anyone really wants that. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
I can live with that. And I hope so can those who want to be restrictive as to what editing takes place. Yours, Joel At 09:27 PM 5/25/2006, Stephen Hayes (TX/EUS) wrote: After some consideration, I can understand how the current text in mankin-pub-req would be discouraging to the technical publisher. If we changed refrain from to exercise restraint in making in requirements POSTEDIT-3 and POSTEDIT-4, I assume this would solve Joel and John's concerns. The question now is if I will get shot from the keep your grubby hands off my document crowd. Stephen ___ 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: 'SMTP Submission Service Extension for Future Message Release' to Proposed Standard (draft-vaudreuil-futuredelivery)
On Thursday 25 May 2006 18:39, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'SMTP Submission Service Extension for Future Message Release ' draft-vaudreuil-futuredelivery-03.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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-vaudreuil-futuredelivery-03.txt This is the first time I've seen this document. Based on a once through it seems technically complete and coherent. The security considerations section addressed the issues that I thought of when reading the document. I do have a couple of minor comments: In the change log, it mentions that the term HOLD has been changed to HOLDFOR and HOLDUNTIL in this revision of the draft. In paragraph 4.2.2, MSA interaction with DSN, the obsolete term HOLD still appears in sub-para 2. While minor, this should be corrected prior to publication. There is no collected ABNF. In general, I find having the entire ABNF together for reference to be useful as an implementer and so it would be nice to have in this document. Additionally, I think that the omission mentioned in the previous comment would have been obvious in a collected ABNF. Scott Kitterman ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Just below you are acknowledging the need for EAP over IP. I don't understand how you can still claim you don't understand why PANA is useful... The framework doesn't seem to talk much about simple EAP over IP scenarios, so I have assumed this is not the major focus. I am sure you read RFC 4058 (like anyone who claims they don't understand PANA should have done). RFC 4058 said: PANA will carry EAP above IP in order to enable any authentication method on any link-layer. You are aware that virtual open-access AP mode is OK. One of the two alternatives we proposed had an issue, and the other one still holds. Right. I was referring only to the WPA/WPA2 scenarios. Your earlier statement did give another impression, like PANA does not work with 802.11i at all. Thanks for clarifying it now! De-facto? Could you please elaborate how it is becoming a de-facto standard? EAP over UDP is one of the foundation technologies for Network Endpoint Assessment (NEA). As I understand it, EAPoUDP is being made available on most operating systems, and is in the process of being deployed by many enterprise customers. Yes, that individual I-D is productized as a proprietary protocol by one company (Cisco). Client-side software may be made available by them for various platforms (note PANA is already made available as an open source --both client and software side). If Cisco develops a proprietary protocol on its own for a subset of our work, should we now stop what we do at IETF? Is that where this whole fuss is coming from now? Besides. Of course PANA is more complex than EAPoUDP. The latter (an individual I-D) has very limited applicability. As I understand it, EAP over UDP is mostly being deployed for wired access scenarios where IEEE 802.1X might not work well (e.g. multiple hosts sharing a port). Which SDOs? Please give us more detail. As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has evaluated the PANA framework document. How does this explain your rejected by the SDOs claim? IEEE 802.11 provided a review feedback and they fixed few important problems and acknowledged the applicability of our other alternative solutions. How is that a rejection?!? As for 3GPP2, I can get into really gory details of what has been happening there, but it's not technical at all (if you are familiar with 3GPP2 and the relevant players in this discussion, you can guess). Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On Thu, May 25, 2006 at 04:45:39PM -0700, Bernard Aboba wrote: I do understand the potential need for EAP to be encapsulated over IP. However, in practice PANA is more complex than EAP over UDP (see draft-thomson-nacp-02.txt), which looks like it is on the road to becoming the defacto standard for EAP encapsulation over IP. I don't think draft-thomson-nacp-02.txt is something to become an IETF standard EAP over UDP protocol because of its lack of security. In fact the draft admits: If breach of confidentiality and deliberate attacks on the integrity of the NACP protocol itself are a significant risk in certain deployment environments, NACP should be protected by a protocol that offers confidentiality and/or packet authentication, integrity and protection against replay e.g. IPSEC [RFC2401]. Why IPsec is needed to carry EAP? What is authentication protocol for bootstrapping IPsec to protect NACP, perhaps EAP over IKEv2?? I have other security-related issues on NACP. My view is that secure enhancement of NACP will be equivalent to the EAP over UDP protocol the IETF is standardizing, PANA. Yoshihiro Ohba So from what I can tell, in each potential usage scenario PANA is either not feasible, is more complex than an established alternative, or has been rejected by the SDOs that have examined it. --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Yes, that individual I-D is productized as a proprietary protocol by one company (Cisco). As I understand it, EAP over UDP is one of the items proposed for standardization in the NEA WG. That leads me to wonder whether the IETF will be chartering multiple WGs to standardize EAP encapsulation over IP. Although my understanding of both PANA and NEA is no doubt incomplete/wrong/confusled, having multiple EAP encapsulation standards seems duplicative to me. As for 3GPP2, I can get into really gory details of what has been happening there, but it's not technical at all (if you are familiar with 3GPP2 and the relevant players in this discussion, you can guess). The issue is that integration of PANA with link layer technologies requires the support of the organizations that own those link layers. Without that link layer integration (for whatever reason) the scenarios can't be realized, at least in a mainstream way. It seems to me that one of the motivations for PANA is to *avoid* link layer dependencies in situations where link layer technology is inadequate/can't be deployed, and a forklift upgrade isn't in the budget. In those circumstances, integration with link layers or IPsec VPN technology is not under consideration -- because that would require a forklift upgrade. For example, the wireless hotspot case where something more sophisticated than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN deployment isn't a realistic alternative. Or the shared wired media case where network port authentication doesn't really work, and wholesale switch port replacements aren't affordable. In both of those cases, EAP over IP might provide a light weight, easily deployed solution. Yet, rather than focusing on the specific scenarios in which PANA might be compelling, the PANA framework document tries to cover a wide range of potential uses, trying to position PANA for use in scenarios where the case is less obvious. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
I have other security-related issues on NACP. My view is that secure enhancement of NACP will be equivalent to the EAP over UDP protocol the IETF is standardizing, PANA. Can you describe why the security of PANA is better than EAP over UDP (NACP)? I had thought that they were more or less equivalent, since neither approach mandates protection. But maybe I am missing something? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On Thu, May 25, 2006 at 09:24:03PM -0700, Bernard Aboba wrote: I have other security-related issues on NACP. My view is that secure enhancement of NACP will be equivalent to the EAP over UDP protocol the IETF is standardizing, PANA. Can you describe why the security of PANA is better than EAP over UDP (NACP)? I had thought that they were more or less equivalent, since neither approach mandates protection. NACP does not have its own integrity protection mechanism while PANA has. It is true that PANA AUTH AVP is optional, but the use of protection is mandatory when an EAP method that is capable of deriving keys is used. This is described in the PANA specification draft. We can discuss security aspects more, but what I would really like to say in this thread is that discussing usefulness of PANA or any other EAP transport without deep security analysis does not appear to be the right thing. Yoshihiro Ohba ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'SMTP Submission Service Extension for Future Message Release' to Proposed Standard (draft-vaudreuil-futuredelivery)
The IESG has received a request from an individual submitter to consider the following document: - 'SMTP Submission Service Extension for Future Message Release ' draft-vaudreuil-futuredelivery-03.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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-vaudreuil-futuredelivery-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: IETF Calendar 2008 - 2010 Ver 02
This is a Last Call for feedback on Version 02 proposed 2008 - 2010 IETF Meeting dates. The IAOC anticipates taking action to formally adopt dates on 1 June. These dates differ from the version 01 dates based upon community feedback, a review of meeting dates of those organizations on the Clash List and maintenance of a reasonably similar period between meetings. While every effort was made to avoid conflicts where known, it was not always possible with those organizations in the should avoid category and on many occasions the IETF meetings are back to back with the IEEE Plenaries. Future location decisions will take into consideration the location of other organization meetings with which the community interacts. Your feedback to [EMAIL PROTECTED] on conflicts with these dates would be appreciated. Proposed 2008 - 2010 meeting dates: 2008 IETF 71 Mar 23 - 28 IETF 72 Jul 27 - Aug 1 IETF 73 Nov 16 - 21 2009 IETF 74 Mar 22 - 27 IETF 75 Jul 26 - 31 IETF 76 Nov 8 - 13 2010 IETF 77 Mar 21 - 26 IETF 78 Jul 25 - 30 IETF 79 Nov 7 - 12 The schedules of other organization's meetings as known can be found at: http://www.ietf.org/meetings/events.cal.html. Thanks for your continuing assistance. Ray Pelletier IAD ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada
There are two (2) Internet-Draft cutoff dates for the 66th IETF Meeting in Montreal, Quebec, Canada: June 19th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, June 19th at 9:00 AM ET. As always, all initial submissions with a filename beginning with draft-ietf must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. June 26th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, June 26th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 10th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to [EMAIL PROTECTED] The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
