RE: [TLS] Review of draft-housley-tls-authz-extns-05
Russ,
I don't think this is good use of informative text. Other
standards bodies often mark some sections of a specification
as informative, but those sections are text that is helpful
for understanding the specification, but is not required to
implement it.
The KeyNote section is clearly part of the technical specification,
and required reading to get interoperable implementations of this
feature.
Also, my reading of RFC2026 is that the Proposed Standard status
applies to whole documents, and I found nothing there that would
support approving only some specific sections of a document as
Proposed Standard, while leaving other sections as Informational
or Experimental
Best regards,
Pasi
-Original Message-
From: ext Russ Housley [mailto:[EMAIL PROTECTED]
Sent: 23 May, 2006 19:59
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05
Pasi:
Steve Kent and Eric Rescorla made similar comments to your
third point:
3) The document is last called for Proposed Standard, but contains
a normative reference to Informational RFC (RFC 2704). I'd
suggest removing the KeyNote stuff from this document (if someone
really wants to do KeyNote, it can be a separate document).
I would like to propose a way forward on this point. It involves
three changes.
First, I suggest a different code point assignment:
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), keynote_assertion_list(64), (255)
} AuthzDataFormat;
Second, I propose the following text:
3.3.4. KeyNote Assertion List (Informative)
When KeyNoteAssertion List is used, the field contains an ASCII-
encoded list of signed KeyNote assertions, as described
in RFC 2704
[KEYNOTE]. The assertions are separated by two '\n' (newline)
characters. A KeyNote assertion is a structure similar
to a public
key certificate; the main difference is that instead of a binding
between a name and a public key, KeyNote assertions bind
public keys
to authorization rules that are evaluated by the peer
when the sender
later issues specific requests.
When making an authorization decision based on a list of KeyNote
assertions, proper linkage between the KeyNote assertions and the
public key certificate that is transferred in the TLS Certificate
message is needed. Receivers of a KeyNote assertion list should
initialize the ACTION_AUTHORIZER variable to be the
sender's public
key, which was used to authenticate the TLS exchange.
Third, I suggest making the [KEYNOTE] reference informational.
What do you think? Is this a reasonable compromise?
Russ
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: cApitalization
From: Bill Strahm [EMAIL PROTECTED] You think that is bad - try going by your legal Middle Name. Do you know how many systems require a first name and a middle initial... I once gave very serious consideration to legally changing my first name to J (just the one letter) so that I could mess with such systems, and the bureacrats who use them. It would have been such a delight... (Boy, it would have sent the INS people ballistic! :-) Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: cApitalization
Noel Chiappa wrote: I once gave very serious consideration to legally changing my first name to J (just the one letter) so that I could mess with such systems, and the bureacrats who use them. It would have been such a delight... (Boy, it would have sent the INS people ballistic! :-) Cue the Ronly Bonly Jones story. (Those who don't know, google.) -Dave -- Dave Aronson Specialization is for insects. -Heinlein Work: http://www.davearonson.com/ Play: http://www.davearonson.net/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC Author Count and IPR
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. In one of the working groups in the Security Area, there is a document with six authors on it. I asked the WG chairs to reduce the author count in the hope of avoiding a problem down the road. At that time, I was not aware of the copyright. Now, I think I gave the WG Chairs inappropriate directions. The IESG and the whole Internet Community needs clear direction on this issue. I suspect that the IPR WG will be a part of the process to resolve it. Also, the Tech Spec document, which is currently in Last Call, many need to include a requirement that the RFC Editor explicitly acknowledge copyright holders in some fashion. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[Sam Hartman] [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing
Hello. I'd like to draw your attention te the following BOF proposal. Please discuss on [EMAIL PROTECTED] I'd appreciate comments and indications of interest. I'd also like to draw your attention to two resources besides the BOF proposal: http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-May/000241.html contains a better describption of what I think the BOF presentations should cover. http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-00.txt contains my comments on anti-phishing requiremnts and I hope will be a starting point for what it means for web authentication to be resistant to phishing. I believe that similar requirements should apply to other proposals including things in the DIX space. ---BeginMessage--- [Sent to the ADs; comments very much appreciated.] BOF Description: At IETF 65, the DIX BOF demonstrated a consensus to work on a solution to the problem that there are two many passwords for the web. This BOF proposes to develop a authentication architecture for the web and other HTTP-based applications using existing technology with at most small changes necessary to improve deployability that addresses this problem. One of the critical challenges facing the web today is the problem of phishing, where users are directed to fraudulent websites that request confidential information. Any solution to the phishing problem will require UI changes in web browsers. However the HTTP authentication architecture needs to work with these UI changes and provide clear technical requirements for the security features required from the UI. Proposed Charter: Web Authentication Resistant to Phishing (WARP) Applications Area Director(s): Ted Hardie [EMAIL PROTECTED] Lisa Dusseault [EMAIL PROTECTED] Applications Area Advisor: Lisa Dusseault [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: In Body: subscribe Archive: http://www.imc.org/atom-syntax/mail-archive/ Description of Working Group: WARP is chartered to develop a method for using existing authentication technology to address two critical problems with authentication for the web and other HTTP-using applications. The first problem is that users must remember and maintain passwords for each HTTP service they use. The second problem is that of phishing. While browser UIs must change in order to combat the problem of phishing, WARP must work with these UI changes and must provide clear technical requirements for the security features needed from authentication UI. WARP will attack the problem of multiple passwords in two ways. First, it will be safe from a security standpoint to use the same password with multiple HTTP services.Second, WARP will support the concept of an identity provider, which is a service that clients can authenticate to and that can make assertions about their identity to third parties. Employers authenticating their employees to business partners, distributed communities that share a concept of identity and services like Microsoft's Passport service demonstrate the wide variety of identity providers. There will never be a single identity that a user can use on the web: many users would not choose to use the same identity in a work context that they use personally; similarly business relationships and policies will dictate what identities services can accept. However WARP will support the concept of identity providers so that when policies permit, users can minimize the number of identities they use. WARP must support identity providers associated with servers and should support identity providers that have relationships with users. WARP needs to support mobile users, including users that use HTTP services from computers they have never used before. WARP must not require per-service or per-identity-provider configuration.While WARP is focused on passwords as that is expected to be the primary means of authentication, WARP needs to support other credentials including smart cards, one-time passwords and zero-knowledge password protocols.It is desirable that WARP be able to carry assertions about identity such as Security Assertion Markup Language assertions. The WARP working group will first write a problem statement and a requirements draft describing what it means to produce an authentication solution that is resistant to phishing. Then WARP will choose a mandatory-to-implement authentication technology and protocol for the interaction between the identity provider and website. WARP will coordinate with W3C in working on the UI implications of phishing.WARP will not propose specific UI nor specific extensions to HTML, although WARP may recommend requirements for both as these requirements directly impact the security
Re: RFC Author Count and IPR
Dear Russ, the authors can either be individuals or WGs. The practice to quote authors for WG documents while they are a cooperative work seems a wrong practice to me. Copyrights' period take into consideration the date of the death of the last contributor. The name of all the members of a WG should be noted if the rights are not exclusively with the IETF. When a group of individuals wants to propose a document its members known the numerus clausus before (whatever the number). The missing possibility is for an entity to introduce a collective Draft. Only IAN, IESG, etc.can introduce a Draft under their name. IMHO WG2 and RD organisations should too. jfc At 18:37 24/05/2006, Russ Housley 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. In one of the working groups in the Security Area, there is a document with six authors on it. I asked the WG chairs to reduce the author count in the hope of avoiding a problem down the road. At that time, I was not aware of the copyright. Now, I think I gave the WG Chairs inappropriate directions. The IESG and the whole Internet Community needs clear direction on this issue. I suspect that the IPR WG will be a part of the process to resolve it. Also, the Tech Spec document, which is currently in Last Call, many need to include a requirement that the RFC Editor explicitly acknowledge copyright holders in some fashion. Russ ___ 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: RFC Author Count and IPR
Russ Housley 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. FYI, that is a violation of Article 6bis of Berne convention: (1) Independently of the author's economic rights, and even after the transfer of the said rights, the author shall have the right to claim authorship of the work and to object to any distortion, mutilation or other modification of, or other derogatory action in relation to, the said work, which would be prejudicial to his honor or reputation. That is, in most countries including US, no one can distort the real authorship (perhaps without spontaneous consent from the authors). Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Review of draft-housley-tls-authz-extns-05
Russ, I concur with Pasi's observations. I don't recall seeing a similar structure in an RFC, where a part is informative, in what is otherwise a standards track document. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: cApitalization
On Wed, May 24, 2006 at 08:50:04AM -0400, Noel Chiappa wrote: From: Bill Strahm [EMAIL PROTECTED] You think that is bad - try going by your legal Middle Name. Do you know how many systems require a first name and a middle initial... I once gave very serious consideration to legally changing my first name to J (just the one letter) so that I could mess with such systems, and the bureacrats who use them. It would have been such a delight... (Boy, it would have sent the INS people ballistic! :-) I know a fellow who goes by one name, like Bono or Cher. When he has to squeeze himself into such databases, he gives his first name as Mr. I believe even he has the sense to have the name the Gov't thinks he uses on his passport, etc., though I don't know. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpfo78FfBCb1.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: cApitalization
From: Bill Strahm [EMAIL PROTECTED] You think that is bad - try going by your legal Middle Name. Do you know how many systems require a first name and a middle initial... I once gave very serious consideration to legally changing my first name to J (just the one letter) so that I could mess with such systems, and the bureacrats who use them. It would have been such a delight... (Boy, it would have sent the INS people ballistic! :-) 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. Edwin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ I am concerned that the current RFC Editor practice that Russ limits the number of authors is in conflict with the IETF Russ IPR policies. The RFC Editor currently limits the author Russ count to five people. Recent IPR WG discussions make it Russ clear to me that authors retain significant copyright. [There is this concept in US copyright law called a joint work. I'm ignoring that concept for the moment basically because I don't understand how it applies to either software or text developed using an open process. As far as I can tell, no one else understands it either. Please be aware that this may be a huge gap in my advice.] So, here we have a conflicting definitions problem. The author of a work retains the copyright interest. That's true if if I'm listed as an author or not. If I write text and do not assign the copyright to someone, I retain copyright interest in that text. So the sixth person still owns the copyright interest in the text they write even if they are not listed. That means if you have unlisted authors who have contributed significant chunks of text, you still need to get their clearance to do anything interesting with that text. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On Wed, 24 May 2006, Sam Hartman wrote: 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. ... FWIW, I do not believe the current framework document as written is sufficiently clear in order to be able to evaluate where and under which conditions and assumptions the solution could be deployed. Therefore it is not feasible to evaluate the usefulness or applicability of the PANA protocol itself either. My review is here: http://www1.ietf.org/mail-archive/web/ietf/current/msg41231.html There has been some follow-up work to clarify and address these. Based on the discussion, I fear revision would take significant cycles, so the result remains to be seen. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Review of draft-housley-tls-authz-extns-05
Right. I am proposing the addition of (Informative) after the KeyNote section title. Also, I proposed assigning the KeyNote code point from the specification required set of numbers instead of the set that is associated with standards track documents. Russ At 11:07 AM 5/24/2006, Stephen Kent wrote: Russ, I concur with Pasi's observations. I don't recall seeing a similar structure in an RFC, where a part is informative, in what is otherwise a standards track document. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Sam: We need a way to track the people that have copyright interest. I had always assumed this was the author list. If we are going to continue to limit the author count to five people, then there needs to be a place where the people with copyright interest are listed in the document. This is the reason that I included the techspec mail list on my posting. Russ At 02:06 PM 5/24/2006, Sam Hartman wrote: Russ == Russ Housley [EMAIL PROTECTED] writes: Russ I am concerned that the current RFC Editor practice that Russ limits the number of authors is in conflict with the IETF Russ IPR policies. The RFC Editor currently limits the author Russ count to five people. Recent IPR WG discussions make it Russ clear to me that authors retain significant copyright. [There is this concept in US copyright law called a joint work. I'm ignoring that concept for the moment basically because I don't understand how it applies to either software or text developed using an open process. As far as I can tell, no one else understands it either. Please be aware that this may be a huge gap in my advice.] So, here we have a conflicting definitions problem. The author of a work retains the copyright interest. That's true if if I'm listed as an author or not. If I write text and do not assign the copyright to someone, I retain copyright interest in that text. So the sixth person still owns the copyright interest in the text they write even if they are not listed. That means if you have unlisted authors who have contributed significant chunks of text, you still need to get their clearance to do anything interesting with that text. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC Author Count and IPR
If I remember correctly, we only limit the number of suthors on the first page of the document. It is perfectly acceptable to list a longer set of names inside the document in an contributors section. I also have concerns about who should be listed as an author and have copyrights when a work is developed by a WG. The demand to do things with IETF documents beyond IETF standards work seems to be growing, so it will be an increasingly difficult problem if we do not identify all the people who contributed significant portions of a document (where significant is of course open to debate). dbh -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 2:06 PM To: Russ Housley Cc: rfc-editor@rfc-editor.org; ietf@ietf.org; techspec@ietf.org; ipr-wg@ietf.org Subject: Re: RFC Author Count and IPR Russ == Russ Housley [EMAIL PROTECTED] writes: Russ I am concerned that the current RFC Editor practice that Russ limits the number of authors is in conflict with the IETF Russ IPR policies. The RFC Editor currently limits the author Russ count to five people. Recent IPR WG discussions make it Russ clear to me that authors retain significant copyright. [There is this concept in US copyright law called a joint work. I'm ignoring that concept for the moment basically because I don't understand how it applies to either software or text developed using an open process. As far as I can tell, no one else understands it either. Please be aware that this may be a huge gap in my advice.] So, here we have a conflicting definitions problem. The author of a work retains the copyright interest. That's true if if I'm listed as an author or not. If I write text and do not assign the copyright to someone, I retain copyright interest in that text. So the sixth person still owns the copyright interest in the text they write even if they are not listed. That means if you have unlisted authors who have contributed significant chunks of text, you still need to get their clearance to do anything interesting with that text. ___ 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: RFC Author Count and IPR
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Sam: We need a way to track the people that have copyright Russ interest. I had always assumed this was the author list. Russ If we are going to continue to limit the author count to Russ five people, then there needs to be a place where the people Russ with copyright interest are listed in the document. This is Russ the reason that I included the techspec mail list on my Russ posting. I think that's probably authors?+contributors. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
* That means if you have unlisted authors who have contributed * significant chunks of text, you still need to get their clearance to * do anything interesting with that text. * Who decides what constitutes a significant chunk? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Sam: If the people with copyright interest are the combination of the authors plus the contributors, then we need to specify this in a BCP. Does the RFC Editor have to contact the members of both lists during Auth48? If so, I would suggest that the RFf Editor only needs a positive reply from the authors, but that the contributors only need to respond if they discover a change that is needed. Russ At 02:35 PM 5/24/2006, Sam Hartman wrote: Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Sam: We need a way to track the people that have copyright Russ interest. I had always assumed this was the author list. Russ If we are going to continue to limit the author count to Russ five people, then there needs to be a place where the people Russ with copyright interest are listed in the document. This is Russ the reason that I included the techspec mail list on my Russ posting. I think that's probably authors?+contributors. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Authorship discussions have a long history in the sciences. I'm not aware of any other scientific or technical publication that limits the number of authors. (Indeed, I have had to extend the maximum author count on a largish conference management system I run [edas.info] a few times.) The current limit of 5 seems to be motivated by formatting constraints and maybe by the notion that vanity publishing should be prevented. It is not clear to me that these motivations have legal standing and essentially, for practical purposes, force authors to give up their rights. In the past, I know that for some drafts, this limit has been extended when the AD made the right noises to the RFC editor, so it is not universally observed. My understanding is that contributors generally have inferior rights, not much different from those individuals acknowledged in the acknowledgment section of technical papers and RFCs. After some of the recent science scandals, there also seems to be a movement afoot (e.g., for Science and Nature) to force all authors to take responsibility for the paper and its content. That's a flip-side, also from an IPR perspective: If somebody can plausibly claim that they just got added to the author list without their consent, they could weasle out of the IPR disclosure rules. At least from my experience, it is not uncommon that I-D authors add others as a courtesy and, currently, nobody seems to check whether these authors consented to being an author... Henning Vijay Devarapallli wrote: On 5/24/06, Sam Hartman [EMAIL PROTECTED] wrote: That means if you have unlisted authors who have contributed significant chunks of text, you still need to get their clearance to do anything interesting with that text. typically the unlisted authors are ignored. also during the AUTH48 period, the RFC Editor contacts only the listed authors. Vijay ___ 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: RFC Author Count and IPR
Sam, et al, There are so many things tied up in this, that I am afraid it is bound to turn into a rat-hole. For one thing, I thought Russ was talking about the complication that arise from whether or not the BCP 78/79 stuff applies to people who made some contribution but are not listed as Authors. I may have missed his point, but this probably is an issue as there are other things in IPR than copyrights. For another, there is a clear distinction between attribution and being listed as an author. Most drafts I've seen acknowledge the people making contributions. Also, RFCs are not (at least usually) a compilation of related works by separate authors. An RFC typically requires some unification and typically this is performed by one or more editors. Because of churn-and-merge complexity, it is usually the case that there is only one editor at any given moment, and the list of token holders is both well defined and small - consequently is is quite reasonable to ask that a long list of authors be replaced by a shorter list of the people who actually took turns as editors. I think the biggest issue is that the RFC Editor has established guidelines that use a fixed number. This can lead to rather arbitrary decisions about who is an editor, author or contributor. Probably a better approach would be to explicitly define what the RFC Editor means by the terms contributor, author, editor and - perhaps - something even more specific that that (e.g. - final editor?) and then saying that some number of names MAY be listed on the first page and that the approach to determining what names should be included is to pick the category that has no more than that many in the list. I was pretty much under the impression that this is the informal approach used now. -- Eric -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, May 24, 2006 2:06 PM -- To: Russ Housley -- Cc: rfc-editor@rfc-editor.org; ietf@ietf.org; -- techspec@ietf.org; ipr-wg@ietf.org -- Subject: Re: RFC Author Count and IPR -- -- Russ == Russ Housley [EMAIL PROTECTED] writes: -- -- Russ I am concerned that the current RFC Editor practice that -- Russ limits the number of authors is in conflict with the IETF -- Russ IPR policies. The RFC Editor currently limits the author -- Russ count to five people. Recent IPR WG discussions make it -- Russ clear to me that authors retain significant copyright. -- -- [There is this concept in US copyright law called a joint work. I'm -- ignoring that concept for the moment basically because I don't -- understand how it applies to either software or text developed using -- an open process. As far as I can tell, no one else understands it -- either. Please be aware that this may be a huge gap in my advice.] -- -- So, here we have a conflicting definitions problem. -- -- The author of a work retains the copyright interest. That's true if -- if I'm listed as an author or not. -- -- If I write text and do not assign the copyright to someone, I retain -- copyright interest in that text. -- -- So the sixth person still owns the copyright interest in -- the text they -- write even if they are not listed. -- -- That means if you have unlisted authors who have contributed -- significant chunks of text, you still need to get their clearance to -- do anything interesting with that text. -- -- ___ -- 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: RFC Author Count and IPR
On 5/24/06, Bob Braden [EMAIL PROTECTED] wrote: * That means if you have unlisted authors who have contributed * significant chunks of text, you still need to get their clearance to * do anything interesting with that text. * Who decides what constitutes a significant chunk? the primary author (there is always one person who maintains the XML source) and the WG chairs? Vijay ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
* * 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. Five seemed like a reasonable limit. Do you like 6 better? We do tend to push back (via the WG chairs) a bit on more than 5 authors, since we knew that if there were many exceptions granted, everyone would discover they needed an exception, defeating the purpose of the limitation. We have found that almost everyone affected by the limit has understood the problem and been very cooperative in keeping to it. I do not recall the IPR issue raised before. Bob Braden for the RFC Editor ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
On May 24, 2006, at 14:42, Russ Housley wrote: If the people with copyright interest are the combination of the authors plus the contributors, then we need to specify this in a BCP. We might also want to suggest that the acknowledgment specifically indicate if someone contributed text, as a text-contributor may have rights that an idea-contributor does not. With the default assumption being that contributed, if not clarified, means contributed text and/or ideas. There's also the related issue of text taken from a previous RFC -- I would think it would suffice to acknowledge the source of the text, rather than merging contributor/author lists. (Though if the previous author list is small and the copied text is large, specific, explicit acknowledgment in the new document is probably the polite thing to do.) But either way, those authors may also retain copyright interest in the new document. Does the RFC Editor have to contact the members of both lists during Auth48? If so, I would suggest that the RFf Editor only needs a positive reply from the authors, but that the contributors only need to respond if they discover a change that is needed. I would think the RFC Editor probably does not need to; after all, isn't the short list also (a superset of) the people already acting as editors on behalf of the working group, other contributors, etc? Those people may choose to include various contributors in the Auth48 review, or not. Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC Author Count and IPR
Henning, IRT BCP 78/79 IPR statements, it's actually worse than you indicate. The issue is that (because of the Note Well) you can't effectively take back a contribution and (because of the need for proper attribution) you really cannot de-list someone who has made any significant contribution to the document. Because of the wording in current IPR BCPs, however, any author is not only agreeing to be responsible for IPR that he (or she) may have in their contribution, but also any IPR they may know of that relates to other contributions made in an RFC for which they are a listed author. One seriously detrimental effect of these considerations is that this actively discourages an RFC author (and possibly any other contributor) from trying to determine if his (or her) employer actually has any IPR in the technology about which they are writing - and, thus, encouraging a separation between those who do things and those who write about it... -- Eric -- -Original Message- -- From: Henning Schulzrinne [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, May 24, 2006 2:43 PM -- To: Vijay Devarapallli -- Cc: rfc-editor@rfc-editor.org; Sam Hartman; -- ipr-wg@ietf.org; techspec@ietf.org; ietf@ietf.org -- Subject: Re: RFC Author Count and IPR -- -- Authorship discussions have a long history in the sciences. I'm not -- aware of any other scientific or technical publication that -- limits the -- number of authors. (Indeed, I have had to extend the maximum author -- count on a largish conference management system I run -- [edas.info] a few -- times.) The current limit of 5 seems to be motivated by formatting -- constraints and maybe by the notion that vanity -- publishing should be -- prevented. It is not clear to me that these motivations have legal -- standing and essentially, for practical purposes, force -- authors to give -- up their rights. In the past, I know that for some drafts, -- this limit -- has been extended when the AD made the right noises to the -- RFC editor, -- so it is not universally observed. -- -- My understanding is that contributors generally have -- inferior rights, -- not much different from those individuals acknowledged in the -- acknowledgment section of technical papers and RFCs. -- -- After some of the recent science scandals, there also seems to be a -- movement afoot (e.g., for Science and Nature) to force all -- authors to -- take responsibility for the paper and its content. That's a -- flip-side, -- also from an IPR perspective: If somebody can plausibly -- claim that they -- just got added to the author list without their consent, they could -- weasle out of the IPR disclosure rules. At least from my -- experience, it -- is not uncommon that I-D authors add others as a courtesy and, -- currently, nobody seems to check whether these authors consented to -- being an author... -- -- Henning -- -- Vijay Devarapallli wrote: -- On 5/24/06, Sam Hartman [EMAIL PROTECTED] wrote: -- -- That means if you have unlisted authors who have contributed -- significant chunks of text, you still need to get their -- clearance to -- do anything interesting with that text. -- -- typically the unlisted authors are ignored. -- -- also during the AUTH48 period, the RFC Editor contacts -- only the listed -- authors. -- -- Vijay -- -- -- -- -- -- -- ___ -- 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 -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
The IETF does publish protocols that may or may not be viable in the real world. I think PANA, after a significant clean up, might belong in that category. I, for instance, have the following high-level issues: ** No real use cases out there, and no real hope either. 3GPP2 HRPD recently joined the growing list of L2 technologies that ruled out PANA. ** EAP over IKEv2 seems like a more viable alternative: apparently being proposed in 3G-WLAN interworking scenario as the access auth protocol. ** PANA's notions of EP placement seem vague the EPs' location can range from the first-hop router to other routers within the access network (I don't want to paste it all here, but it's Section 7.1 in the framework document). Its crucial for a protocol that sets out to authenticate clients to enforce access control, to get the EP placement right. ** PANA has a notion of binding PANA authentication to an existing secure channel. It is not clear whether it makes sense and the framework document does not have any convincing text. That notion introduces more problems than solving any, I think. Here are some excerpts: Networks where a secure channel is already available prior to running PANA. The presence of a secure channel before PANA exchange eliminates the need for executing a secure association protocol after PANA. I guess the notion is that the existing secure channel is authenticated but for a different reason and PANA authenticates the client again for network access and binds the result using filters to that secure channel. Pretty ad hoc operation, I must say and I think breaks the EAP model. I can provide a more detailed review, but that's not the purpose of this thread. My conclusion is -- stealing Bernard's words -- EAP/IKEv2 will do for what PANA is supposed to support. PANA is not needed really. But if after clarifications, the WG insists that the docs be published, I guess the IESG might publish them as experimental or even move them to historic (not sure how the latter would work). regards, Lakshminath At 11:27 AM 5/24/2006, Pekka Savola wrote: On Wed, 24 May 2006, Sam Hartman wrote: 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. ... FWIW, I do not believe the current framework document as written is sufficiently clear in order to be able to evaluate where and under which conditions and assumptions the solution could be deployed. Therefore it is not feasible to evaluate the usefulness or applicability of the PANA protocol itself either. My review is here: http://www1.ietf.org/mail-archive/web/ietf/current/msg41231.html There has been some follow-up work to clarify and address these. Based on the discussion, I fear revision would take significant cycles, so the result remains to be seen. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ 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?
Disclaimer - I do work in the INT area, but have not been involved in the PANA WG. When this work was chartered, I failed to understand its need and the deployment use cases. Subsequently, about 3 years ago, I recommended against the use of PANA for the needs of my ex-employer. More recently, I have been advocating against the use of PANA in 3gpp2. With that background, some high level confusions that I have about the use of PANA: 1. Reading the framework document, it is simply not clear to me as to why PANA would be useful for any type of network. Actually, even after reading some other PANA documents, this is not clear to me. It seems to have become this complex suite of protocols that aren't specifically buying anything. Why would I want to go through IP address acquisition, for one, if I had a link layer that carried EAP, particularly for link layer security? 2. Link layer agnostic approach has often been cited as a reason to use PANA. I must say that I don't understand how it is link layer agnostic, when it depends on 802.11i 4-way handshake or the like for the secure association protocol. In fact, I am not sure how this even works with the currently defined secure association protocols in lower layers. None of the documents have provided any clarity to me on this. The use of IPsec/IKE for this is even more confusing to me - in this case, why would PANA be used instead of EAP-in-IKEv2? 3. Statements like ...whereas it allows only limited type of traffic (e.g., PANA, DHCP, router discovery, etc.) for the authorized PaCs do not exactly provide a clear picture of port control - yet another reason IMO to leave the EAP lower layer where it belongs (at the link layer). There are many other such confusions in my mind arising from the PANA documents that I won't get into here. 4. The choices that are left to deployment while using PANA constitute a long list for one protocol! Security before/after the PANA run, global vs local PRPA, DHCP vs 3927 vs 2131 for IPv4 PRPA, dual-stack handling behavior, secure association protocol choice and what it takes to make it work with PANA, need for POPA and unconfiguring PRPA, PAA/EP location and choice of protocol between those entities, IKEv1 vs IKEv2 etc. - I am sure I've missed more choices here; but, complex enough, to say the least! Given all of this, publishing these documents in the current stage as proposed standard RFCs concerns me. Vidya -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;
Authors and Editors (was Re: RFC Author Count and IPR)
Dropping techspec and ipr-wg from this part of the thread The current limit of 5 seems to be motivated by formatting constraints and maybe by the notion that vanity publishing should be prevented. It is not clear to me that these motivations have legal standing and essentially, for practical purposes, force authors to give up their rights. In the past, I know that for some drafts, this limit has been extended when the AD made the right noises to the RFC editor, so it is not universally observed. People can tell me that I've been misleading WG chairs and editors, but what I've been saying in the WG Leadership tutorial is that the 5-author limit resulted from - the practice of contacting authors at AUTH48, only to find out that more authors increase the likelihood of job changes and/or e-mail bounces, plus - several dog-pile author lists on drafts with a huge number of authors, leading us to suspect that this was an effort to demonstrate support from a large group of vendors (so this should be a WG draft and WGLCed immediately), plus - text formatting software that broke when the author list wouldn't fit on one page because there were so many authors. I hear Russ's concern about tracking IPR sources, but hope this doesn't get conflated with author/editor tracking. I'm the draft editor for the Softwires problem statement, which would have seven authors (including me), except that we're trying to observe the five-author guideline. Since this causes some heartburn, what I've been thinking about proposing was - if you have individual authors, you do both the front page and the author section as we do them today - if you have an editor, you list the editor on the front page, but not the authors, and you list both editors and authors listed in the author section (as we do today) But I'm still thinking... Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Vijay == Vijay Devarapallli [EMAIL PROTECTED] writes: Vijay On 5/24/06, Bob Braden [EMAIL PROTECTED] wrote: * That means if you have unlisted authors who have contributed * significant chunks of text, you still need to get their clearance to * do anything interesting with that text. * Who decides what constitutes a significant chunk? Vijay the primary author (there is always one person who No, a court in case of copyright suit. Lazy evaluation is not lways your friend. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Sam: If the people with copyright interest are the Russ combination of the authors plus the contributors, then we Russ need to specify this in a BCP. The people with copyright interest are whoever the court decides have copyright interest. I.E. only available on lazy evaluation. I agree we may want to specify in our publishing practices that we keep track of who we think has copyright interest. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
In case anyone is unsure, the actual policy being followed by the RFC Editor will be found at: http://www.rfc-editor.org/policy.html#policy.authlist Bob Braden for the RFC Editor ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
David Harrington wrote: If I remember correctly, we only limit the number of suthors on the first page of the document. It is perfectly acceptable to list a longer set of names inside the document in an contributors section. It's not just the first page. It also affects the reference citation used in the RFC Index and all other RFCs. I believe the 5 author rule was used as justification to remove most of the original SNMPv2 authors from the author list and all further reference citations, when the RFC 1901-1909 series was advanced. I don't really understand what purpose this serves. I also have concerns about who should be listed as an author and have copyrights when a work is developed by a WG. The demand to do things with IETF documents beyond IETF standards work seems to be growing, so it will be an increasingly difficult problem if we do not identify all the people who contributed significant portions of a document (where significant is of course open to debate). There is a problem with companies piling on the authors for I-D proposals to make it look like lots of people worked really hard on it and all agree on the contents. (This is hardly ever the case.) Then when you go to WG draft, there are already 5 or 7 names as authors, and the WG wants to add more. I think then, you have to pick a real Editor (responsible for all edits all the way through AUTH48) and just list that person as Editor on the first page and citations, and put everybody in the Authors section in the back. IMO, this is different than removing the author(s) of a previous version of an RFC. I object to that practice. dbh Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Andy, For what it's worth, I agree with you. Having a single editor simplifies many things, but having a authors list allows full credit to all parties. John - original message - Subject:Re: RFC Author Count and IPR From: Andy Bierman [EMAIL PROTECTED] Date: 05/24/2006 7:19 pm David Harrington wrote: If I remember correctly, we only limit the number of suthors on the first page of the document. It is perfectly acceptable to list a longer set of names inside the document in an contributors section. It's not just the first page. It also affects the reference citation used in the RFC Index and all other RFCs. I believe the 5 author rule was used as justification to remove most of the original SNMPv2 authors from the author list and all further reference citations, when the RFC 1901-1909 series was advanced. I don't really understand what purpose this serves. I also have concerns about who should be listed as an author and have copyrights when a work is developed by a WG. The demand to do things with IETF documents beyond IETF standards work seems to be growing, so it will be an increasingly difficult problem if we do not identify all the people who contributed significant portions of a document (where significant is of course open to debate). There is a problem with companies piling on the authors for I-D proposals to make it look like lots of people worked really hard on it and all agree on the contents. (This is hardly ever the case.) Then when you go to WG draft, there are already 5 or 7 names as authors, and the WG wants to add more. I think then, you have to pick a real Editor (responsible for all edits all the way through AUTH48) and just list that person as Editor on the first page and citations, and put everybody in the Authors section in the back. IMO, this is different than removing the author(s) of a previous version of an RFC. I object to that practice. dbh Andy ___ 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?
On Wed, 24 May 2006, Sam Hartman wrote: 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. Sam - I don't know if PANA will be useful, but I do know why some folks are interested... Have you taken a look at the I2 NetAuth work: http://security.internet2.edu/netauth/ These academic networks are interested in both PANA and NEA as part of their ubiquitous sign-on to RE networks agenda. I'm equally confused, but from another direction. - lel 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 -- 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
On Wed, 24 May 2006, 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. Five seemed like a reasonable limit. Do you like 6 better? We do tend to push back (via the WG chairs) a bit on more than 5 authors, since we knew that if there were many exceptions granted, everyone would discover they needed an exception, defeating the purpose of the limitation. We have found that almost everyone affected by the limit has understood the problem and been very cooperative in keeping to it. I do not recall the IPR issue raised before. a little history: 28 authors! http://www.arkko.com/tools/rfcstats/authdistr.html 20 authors! http://www.arkko.com/tools/stats/authdistr.html Bob - I think the 5 author rule applies to the listing in the ID/RFC header and not to the authors listed under Author Information - is that correct? - lel Bob Braden for the RFC Editor ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- 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: Authors and Editors (was Re: RFC Author Count and IPR)
* From [EMAIL PROTECTED] Wed May 24 12:46:43 2006 * X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham Spencer Dawkins wrote: * People can tell me that I've been misleading WG chairs and editors, but what * I've been saying in the WG Leadership tutorial is that the 5-author limit * resulted from * * - the practice of contacting authors at AUTH48, only to find out that more * authors increase the likelihood of job changes and/or e-mail bounces, plus * No. The practice of contacting all authors was a RESULT of the author limitation and the desire to prevent vanity publishing. * - several dog-pile author lists on drafts with a huge number of authors, * leading us to suspect that this was an effort to demonstrate support from * a large group of vendors (so this should be a WG draft and WGLCed * immediately), plus * YES! This was the major motivation. Augmented by the concept that the IETF is about individuals, not about corporations. * - text formatting software that broke when the author list wouldn't fit on * one page because there were so many authors. * No. What is true is that the historical format of the first page gets kinda ugly with a large list of authors. This was certainly not the gating concern, however. Bob Braden * But I'm still thinking... * * Thanks, * * Spencer * * * * ___ * 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: [Techspec] RFC Author Count and IPR
Lucy Lynch wrote: * a little history: * * 28 authors! * http://www.arkko.com/tools/rfcstats/authdistr.html * * 20 authors! * http://www.arkko.com/tools/stats/authdistr.html * * Bob - * * I think the 5 author rule applies to the listing in the ID/RFC header * and not to the authors listed under Author Information - is that * correct? * * - lel * Lucy, Please see the URL I posted earlier; the policy was carefully crafted. I would avoid calling it a rule. We think of it as a guideline, a threshold below which no discussion is necessary. Bob Braden * Bob Braden for the RFC Editor * * * * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * * * -- * Lucy E. Lynch Academic User Services * Computing Center University of Oregon * llynch @darkwing.uoregon.edu (541) 346-1774 * ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On 24 May 2006, at 20:52, Lucy E. Lynch wrote: I don't know if PANA will be useful, but I do know why some folks are interested... Have you taken a look at the I2 NetAuth work: http://security.internet2.edu/netauth/ These academic networks are interested in both PANA and NEA as part of their ubiquitous sign-on to RE networks agenda. While I can't comment on NetAuth, I've been engaged in the Europe's equivalent project for HEFE, Eduroam, for the last couple of years and to my knowledge we've never discussed PANA (even though at least a few of us have been aware of its gestation). FWIW I've personally never understood what niche(s) PANA was expecting to fill, but I assumed it was me being dim. josh. Josh Howlett, Networking Specialist, University of Bristol. email: [EMAIL PROTECTED] | phone: +44 (0)7867 907076 | interal: 7850 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
* Bob - * * I think the 5 author rule applies to the listing in the ID/RFC header * and not to the authors listed under Author Information - is that * correct? * * - lel * Lucy, I neglected to answer your question directly. The authors are, by definition, the people listed on the first page. There is no such section as Author Information; probably you mean Authors' Addresses. The rules are spelled out in RFC2223bis, section 2.12. At present Authors' Addreses section lists only authors, i.e., those listed on the first page. The rules say that a Contributors section can list additional contact information. Bob Braden * Bob Braden for the RFC Editor * * * * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * * * -- * Lucy E. Lynch Academic User Services * Computing Center University 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
On Wed, 24 May 2006, Bob Braden wrote: * Bob - * * I think the 5 author rule applies to the listing in the ID/RFC header * and not to the authors listed under Author Information - is that * correct? * * - lel * Lucy, I neglected to answer your question directly. The authors are, by definition, the people listed on the first page. There is no such section as Author Information; probably you mean Authors' Addresses. The rules are spelled out in RFC2223bis, section 2.12. At present Authors' Addreses section lists only authors, i.e., those listed on the first page. The rules say that a Contributors section can list additional contact information. Bob - Following Jari's link to the document (ID) with 20 authors I found: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-00.txt which lists 3 editors on the front page and includes a section (17) titled Author Information which includes 20 addresses. The RFC with 28 authors is Criteria for Evaluating AAA Protocols for Network Access and all 28 and included on the front page. I'm just looking at current practice and trying to understand how address listings relate to authorship and IPR. Not arguing with you, just confused. - lel Bob Braden * Bob Braden for the RFC Editor * * * * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * * * -- * Lucy E. LynchAcademic User Services * Computing Center University of Oregon * llynch @darkwing.uoregon.edu(541) 346-1774 * -- 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
* * Bob - * * Following Jari's link to the document (ID) with 20 authors I found: * * http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-00.txt * * which lists 3 editors on the front page and includes a section (17) * titled Author Information which includes 20 addresses. Lucy, You are suggesting that the definition of author is determined by some tool that produces the pretty graph. I don't think so. In all documentation related to the RFC Editor, an author is a person listed on the first page. I cannot explain what was in the mind of the person writing the tool. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Techspec] RFC Author Count and IPR
On Wed, 24 May 2006, Bob Braden wrote: * * Bob - * * Following Jari's link to the document (ID) with 20 authors I found: * * http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-00.txt * * which lists 3 editors on the front page and includes a section (17) * titled Author Information which includes 20 addresses. Lucy, You are suggesting that the definition of author is determined by some tool that produces the pretty graph. I don't think so. In all documentation related to the RFC Editor, an author is a person listed on the first page. I cannot explain what was in the mind of the person writing the tool. Bob - This is exactly the question I'm trying to get clarity on. Russ's initial email implied that there may be a submerged IPR issue if we limit the number of authors listed on the front page AND hold that document authors continue to hold IP rights. I don't know enough about the history of IP ownership vs acknowledged authorship to be able to tell how serious an issue this may be. 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? - lel Bob Braden -- 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
On Wed, 24 May 2006, Bob Braden 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? * * - lel * * Lucy, It sounds like you need a lawyer. Scary. I was afraid you'd say that. - lel Bob Braden -- 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: [TLS] Review of draft-housley-tls-authz-extns-05
On Wednesday, May 24, 2006 02:57:21 PM -0400 Russ Housley [EMAIL PROTECTED] wrote: Right. I am proposing the addition of (Informative) after the KeyNote section title. Also, I proposed assigning the KeyNote code point from the specification required set of numbers instead of the set that is associated with standards track documents. Then I think you should do it in a separate document. Labelling a section as informative does not make it true. The proposed text describes how to implement a feature, and as Pasi points out, it is impossible to produce interoperable implementations of that feature without reading that section. Thus, the section is not informative in nature; it is a normative description of an optional feature. The same applies to the reference. What you really want to do is be able to declare that part of the document to be informational. Thus there would be no downreference, and a year or ten from now when you want to advance the document to draft, it won't be held back due to the lack of independent interoperable implementations of the optional feature. Of course, then you'd end up with the number allocation being a normative downreference from the standards-track portion of the document to the informational portion, but that can be resolved easily enough, since it's really just prepopulating a registry. Unfortunately, our process doesn't have any mechanism for documents which have both a standards-track part and an informational part. While I think what you're trying to do here is reasonable in its intent, I also think that it's likely to create trouble down the road, not because of the normative downref to RFC2704, but because of confusion about the status of the non-standards-track portion of the document. Not to mention the precedent it sets for the next time when someone wants to do the same sort of thing, but with bad intent and undesirable results. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Disclaimer - I wasn't even aware of this document before reading this thread. However, I have now read it, so feel prepared to comment. On Wednesday, May 24, 2006 03:11:29 PM +0200 Eliot Lear [EMAIL PROTECTED] wrote: Yes, the distinction between well known ports and just assigned ports is outdated. The overarching theme of the document is that the IANA should be treated as a group of adults and that they should use some discretion with oversight only where needed. Careful here... (1) The IANA is a group of adults, but it is no longer a group of protocol subject matter experts. IMHO there is probably no need for IESG oversight of port number allocation, especially if we are eliminating the (artificial) scarcity of so-called well-known ports. (2) As I understand it, for ports above 1024, the IANA does _not_ assign values - it just registers uses claimed by others. Eliminating well-known ports eliminates any assignment role, and leaves us with just a registry of what people have claimed. Note that this means there is no mechanism which prevents the same number from being registered by more than one registry. That said, I support the elimination of well-known ports and transformation of the port number registry into a flat registry in which all ports are basically considered equal. I do _not_ support the introduction of a charging model, for a couple of reasons. First, I don't want to see port numbers become a politicized commodity, like IP address space and domain names have. Second, I believe that having a complete, accurate registry of port numbers is highly valuable. If there is a charge to register a port, and a recurring charge to maintain a registration, then no one will register their ports for private or vendor-specific use and/or minor protocols. That means that they won't be known to network administrators or network traffic analysis tools, and people looking for an unused port - even if they intend to register and pay for it - will have a difficult time finding one that is actually free. It also means that registrations will tend to disappear over time, such that valuable historical information is lost. A charging model works for domain names because they have to appear in a central registry or they don't work. It works for IP addresses, mostly(*), because if two unrelated networks publish routes for the same address space, each of them loses some of the time, and no one wants to lose. It won't work for port numbers because only very widely-deployed protocols need port numbers that aren't in use by _anything_ else. (*) Some years ago, there was a period of time lasting several months when users of a particular large network provider were unable to communicate with CMU, because that provider had usurped 128.2/16 for some private use within its network. We were Not Amused(tm), and had quite a time getting it fixed. And that was in the days when you could usually look up a network in the internic whois server, then pick up the phone and reach someone who actually understood something about his network. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ARPAnet's Problems Persist Unsolved Today
I am told during the last IETF's Social Event, Dave Clark made a presentation that again observed that all of the ARPAnet's historicly unsolved networking problems persist in the Internet today. I wasn't there, but I am seeking a paper that I could reference that makes that very point. Did Dave point to a paper during his speech? If not, can anybody point me to a published paper dealing with this topic? Thanks. --Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
--On Wednesday, 24 May, 2006 19:06 -0400 Jeffrey Hutzelman [EMAIL PROTECTED] wrote: Disclaimer - I wasn't even aware of this document before reading this thread. However, I have now read it, so feel prepared to comment. ... (2) As I understand it, for ports above 1024, the IANA does _not_ assign values - it just registers uses claimed by others. Eliminating well-known ports eliminates any assignment role, and leaves us with just a registry of what people have claimed. Note that this means there is no mechanism which prevents the same number from being registered by more than one registry. This is not correct. They do, indeed, assign values. They also apply some minimal rules in doing so. Squatting on unassigned values, while it does happen, is considered to be in bad taste. Second, I believe that having a complete, accurate registry of port numbers is highly valuable. If there is a charge to register a port, and a recurring charge to maintain a registration, then no one will register their ports for private or vendor-specific use and/or minor protocols. That means that they won't be known to network administrators or network traffic analysis tools, and people looking for an unused port - even if they intend to register and pay for it - will have a difficult time finding one that is actually free. It also means that registrations will tend to disappear over time, such that valuable historical information is lost. ... FWIW, I tend to agree. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Hi, On May 24, 2006, at 4:06 PM, Jeffrey Hutzelman wrote: On Wednesday, May 24, 2006 03:11:29 PM +0200 Eliot Lear [EMAIL PROTECTED] wrote: Yes, the distinction between well known ports and just assigned ports is outdated. The overarching theme of the document is that the IANA should be treated as a group of adults Heh. :-) and that they should use some discretion with oversight only where needed. Careful here... (1) The IANA is a group of adults, but it is no longer a group of protocol subject matter experts. IMHO there is probably no need for IESG oversight of port number allocation, especially if we are eliminating the (artificial) scarcity of so-called well-known ports. The scarcity of ports is not artificial. There are only 16 bits of port space and changing the number of bits in ports will be ... interesting. (2) As I understand it, for ports above 1024, the IANA does _not_ assign values - it just registers uses claimed by others. This is not accurate. The IESG has been explicit in that IANA assigns port numbers (both well known and user), it does not register use. Second, I believe that having a complete, accurate registry of port numbers is highly valuable. As do I. It does not currently exist. That means that they won't be known to network administrators or network traffic analysis tools, Of course, the port registry does nothing to stop any protocol using any port. It might be useful to figure out what function folks expect the IANA port registry to perform. Rgds, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Hi, On May 24, 2006, at 6:16 PM, John C Klensin wrote: This is not correct. They do, indeed, assign values. Yes. They also apply some minimal rules in doing so. IANA does a basic sanity check and if there is any question as to whether a port should be allocated, we pass the request to an IESG Designated Expert who says yes or no. Squatting on unassigned values, while it does happen, is considered to be in bad taste. It is often disappointing to folks who have gone to the trouble to obtain a port to find out that nothing stops someone else from using the same port for a different protocol. Rgds, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'IANA Considerations for PPP over Ethernet (PPPoE)' to BCP (draft-arberg-pppoe-iana)
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for PPP over Ethernet (PPPoE) ' draft-arberg-pppoe-iana-01.txt as a BCP 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-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4498 on The Managed Object Aggregation MIB
A new Request for Comments is now available in online RFC libraries. RFC 4498 Title: The Managed Object Aggregation MIB Author: G. Keeni Status: Experimental Date: May 2006 Mailbox:[EMAIL PROTECTED] Pages: 29 Characters: 59214 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-glenn-mo-aggr-mib-08.txt URL:http://www.rfc-editor.org/rfc/rfc4498.txt This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances. This memo defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4504 on SIP Telephony Device Requirements and Configuration
A new Request for Comments is now available in online RFC libraries. RFC 4504 Title: SIP Telephony Device Requirements and Configuration Author: H. Sinnreich, Ed., S. Lass, C. Stredicke Status: Informational Date: May 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 37 Characters: 84849 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-sinnreich-sipdev-req-08.txt URL:http://www.rfc-editor.org/rfc/rfc4504.txt This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones. We present a glossary of the most common settings and some of the more widely used values for some settings. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
