Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
> "Charles" == Charles Clancy <[EMAIL PROTECTED]> writes: >>> to be an L2 identity. It can be any identity that's >>> meaningful to the parties involved, and can serve as the basis >>> for making authorization decisions. >> As long as it's cryptographically bound to the L2 channel and >> that channel provides suitable protection for the EAP method >> doing the EAP channel binding, THEN Sam's observation is >> correct: "EAP channel binding" uses what I termed "end-point >> channel binding" and "EAP cryptographic binding" uses what I >> termed "unique channel binding." Charles> I don't think I'm convinced that EAP channel bindings are Charles> doing this binding to the L2 channel. The identity used Charles> in an EAP channel binding must be bound to the AAA Charles> security association between the authenticator and the Charles> peer in order for everything to work, so it would be more I'm not sure I'd describe the association between the peer and authenticator as an AAA association. I agree with the rest. Charles> Charles> likely a NAS-ID than a MAC address. Are you sure that the binding happens between the mac address and NAS ID? I don't understand how the peer ever confirms the NAS ID at layer two unless it also happens to be a MAC address. I do agree with you though that EAP channel bindings include the peer's lower layer identity and the identity of the authenticator that the peer will later be able to verify. Charles> That's not to say there isn't an L2 binding happening -- Charles> but I think it's being performed by the L2 secure Charles> association phase that uses the EAP key to derive L2 Charles> keys. Then during that handshake, a MAC address may be Charles> involved, binding in an L2 identity. ANd if things are secure some L2 identity of the authenticator. Charles> I guess I see EAP channel bindings as an EAP<->AAA Charles> binding, and the L2 secure association protocol as the Charles> EAP<->L2 binding. The L2 secure association protocol cannot be an eap->anything binding: it does not typically use EAP level identifiers. Charles> -- t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> Charles> www.cs.umd.edu/~clancy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
> "Lakshminath" == Lakshminath Dondeti <[EMAIL PROTECTED]> writes: >> I think that having a single abstraction that can describe >> what went by multiple names in different areas can be very >> useful because it facilitates cross-area communication. And >> missing an opportunity to point out how two things are more >> similar than they look would help perpetuate a perception that >> those two things are more different than they actually are. Lakshminath> I can see your point of view. The other thing to Lakshminath> worry about is that the more we try to cover under a Lakshminath> single abstraction, the more watered down it might Lakshminath> become to satisfy all viewpoints of applicability to Lakshminath> all of the domains. In fact, I find the requirements Lakshminath> and recommendations in the draft troublesome. Lakshminath> As I thought about it, perhaps here is something that Lakshminath> might make sense: Lakshminath> Define channel binding so that we can cover all uses Lakshminath> of that term. Define properties and specify how one Lakshminath> can achieve those properties. Not sure this next one Lakshminath> needs to be done in the current draft, define which Lakshminath> properties apply to which protocol. Alternatively, Lakshminath> different protocol drafts may specify which of the Lakshminath> properties are required or recommended in each case. Lakshminath> Does that make sense? That makes sense; I think that is exactly what we're doing. I continue to believe, having read all the messages here that my original text is very close to correct in describing the EAP channel bindings problems. I'd love to talk to someone off-line to discuss this, because there is some obvious confusion somewhere. The more I read what you, Bernard and Charles say, the more I'm convinced that I agree with your description of EAP and that my text is correct. The more I talk, the more you're convinced that my text is wrong. We're talking past each other somehow. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68
Geopriv dropped because I'm asking a general question. >> AGENDA CHANGE >> >> The IETF process allows for agenda changes during meetings. At >> the outset of the meeting, the agenda was changed substantially >> from the published agenda. This change included removing the >> discussion of location signing and integrity and replacing it >> with an L7-LCP protocol consensus call. However, evidence has >> arisen that the the Area Directors, Cullen Jennings and Jon >> Peterson, met privately with some participants of the GEOPRIV >> working group to inform them of this agenda change. Cullen >> Jennings is the Area Advisor to GEOPRIV. >> >> If such meetings did occur, we believe them to be improper and >> to have potentially harmed the integrity and transparency of >> GEOPRIV and the IETF. It is not proper for officiates of a >> working group to plan working group agenda changes and >> privately inform only select group participants. Doing so >> disadvantages participants of the working group who have not >> been advised of this change. This is especially true for this >> particular meeting as the agenda change precipitated 15 hums >> during the meeting. >> I'm a bit concerned that I may regularly be doing something that the geopriv chairs feel is inappropriate. I'd lik e to discuss with the wider community so I can change my practices if needed. It's reasonably common that I will try to work with chairs and key participants in a working group to find ways to unstick a working group. for example I may suggest to a chair that some issue needs more time or ask why an issue that seems to be blocking the WG is not on the agenda. I think I've even solicited presentations (with the chair's cooperation) to help educate the working group in an attempt to unblock some issue. Generally these changes are discussed with the WG at the beginning of the meeting and if someone objected we would consider their objection. I can see cases where this would be an abuse. For example if I suggested giving proponents of one proposal time but not proponents of another proposal. Or if someone claimed they needed more time to prepare for a decision but were unable to have that time because of agenda changes, that might be very bad. However I do not see the problem with using hallway time to try and fine tune the agenda to actually allow working groups to make forward progress. Sam Hartman Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
> "John" == John C Klensin <[EMAIL PROTECTED]> writes: John> --On Tuesday, 15 May, 2007 11:27 -0700 Dave Crocker John> <[EMAIL PROTECTED]> wrote: >> Were we to deprecate every feature in IETF specifications that >> get mis-implemented a couple of times over 10 years, I suspect >> much of our technology would be deprecated... John> IMO, and at the risk of again agreeing with Dave, this is John> the issue for me. John> If we have inconsistent uses of terminology across documents John> that are supposed to be using the same, standardized, term, John> then that is a problem with our review process. If the term John> is explicitly standardized in one of the documents, that is John> the definition; things that use the term incorrectly should John> be candidates for fixing. I don't see why the standardized definition is the obvious right place to fix things. I thought we were committed to running code. To me, one implication of that commitment is that sometimes the right fix is for the spec to change rather than the implementations. In a terminology conflict, this often involves moving away from the term that has two conflicting uses to terms that are more clear. Ultimately cases like this should be evaluated based on whether the final result is more clear overall. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
> "John" == John C Klensin <[EMAIL PROTECTED]> writes: John> If we are going to standardize a definitional requirement or John> method -- whether it is ABNF or IPR boilerplate or something John> -- we need to get it right as a self-contained definition John> and then live with it. We should certainly revise and John> replace it if it turns out to be unworkable (as has happened John> with IPR work) or if the definition turns out to be John> inadequate to permit an unambiguous interpretation (that John> issue spills over into my second observation, below). But, John> once other specifications start to depend on the definitions John> that are there, and show those definitions to be adequate, John> we should not be talking about deprecating definitions John> unless we are prepared to "that was wrong, we need to start John> over (even though some of the older material may still be John> useful)". Again, please note the similarity to the IPR John> work. Right. Here, I don't think the definition is wrong, I just think the term being defined is wrong. We proposed a definition for a useful concept. The word we chose (LWSP) stuck in some places but not in others. IN fact other people used the same word for a different although related concept. sufficiently so that the definition we proposed in ABNF is not the most common definition in our standards. Clearly we should not invalidate existing uses of that term. Clearly we do need a definition for the term: it is being used usefully. I think that in this instance, the value of future clarity justifies coming up with a new term that will unambiguously mean what LWSP means in ABNF today. That term will have to start at proposed standard. LWSP will need to continue in ABNF. I see a desire to document our operational experience with the word: many people took this word and used it to mean something else. Perhaps to avoid confusion you should consider whether your use of the word is a good idea. I think there is significant harm in choosing not to document this operational experience when advancing standards. After all, we both agree that it is this experience with running code that gives the IETF value. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Harald, I'm happy to accept your interpretation of the problem. However it also leads me to the conclusion that documenting possible reasons not to use ABNF's LWSP concept, or documenting implications of that rule would be a good idea. I also believe that documenting experience with a spec in future versions of that spec as it advances is reasonable. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
> "Dave" == Dave Crocker <[EMAIL PROTECTED]> writes: Dave> Sam, >> Ultimately cases like this should be evaluated based on whether >> the final result is more clear overall. Dave> What about protecting the installed base for the existing Dave> spec? I think that is not a useful criteria when we are talking about an informative note. I think that criteria matters somewhat more when we are talking about depricating a feature but retaining it, although even then I think the bar would be reasonably low. The installed base will continue to work. I think that criterian is very important if we were talking about removing a rule. For that reason I do not favor removing the LWSP rule. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
I think redefining the rule would require recycling at proposed. I think it would be confusing and harmful to do so. I think removing the rule would is allowed by the process (and would require updates in referencing specs as they advance but would not break anything). I think doing so would be harmful and is not supported by consensus. I do not object to deprecating the rule although I'm not completely convinced doing so is a great idea.I think it is clearly allowed if there is consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes: Keith> it could be argued that the best thing to do is to remove Keith> ALL of the rules from the ABNF spec, leaving only the Keith> language definition and examples. (actually I think I did Keith> argue this sometime around 1996, but I'm too lazy to search Keith> through old email to find it. I think this would be too big of a change going from draft to full given our experience. If we had huge tracts of problems with the rules, it might be a different situation. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-hartman-webauth-phishing-03.txt
> "Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes: Eliot> Sam, I've reviewed draft-hartman-webauth-phishing-03.txt. Eliot> In general I agree with the tone of it in terms of how to Eliot> address these sorts of threats. However, I have a problem Eliot> with its scope. The problem you discuss extends well Eliot> beyond just HTTP already. I don't understand what you mean here. If you mean that other protocols besides http are vulnerable to phishing, I agree. However I do not believe it is desirable to generalize this document to the point where it talks about other protocols. Doing so would make this document harder to understand for those thinking about the web and would make an already incredibly complicated problem harder. Eliot> Furthermore, your assumption Eliot> that the computer is secure is a bad one. I think that some version of this assumption is necessary. Ultimately without some trusted computing base, you cannot trust your security. I don't think it is appropriate for the IETF to bite off the problem of browser design or host security. I do agree with you (and the document does say) host security needs to be considered as part of security analysis . Now, your trusted computing base can be a lot better designed than today's browsers. You may have secure OS components, possibly even assisted by hardware, thta are part of the security solution. But somewhere, whether it is on a smart card, in some trusted hardware, or in software that is somehow validated, you do actually need software that you can trust. Even one-time passwords have problems absent trusted software. In particular, you cannot tell whether you are giving the one time password to the right entity. Perhaps the requirement is unclear. I certainly don't mean that browser designs and their security architecture needs to stay the same. But ultimately your trust needs to be based in some software somewhere. Eliot> I'm not saying Eliot> that we should require smart cards, Note that requiring smart cards doesn't speak to this assumption one way or another. First, traditional smart cards are not enough that if the smart card is trusted and the rest of the system is not, you can get security against phishing. Once you've given your pin to the system, you have no idea what all it goes and uses your smart card to do. And to the extent that smart card would help, they are secure. If you allow the attacker to run software on your smart card, it destroys your security just as thoroughly as in a non-smart-card system where you let the attacker write browser extensions. Eliot> as a matter of threat analysis, you should allow for the Eliot> idea that the computer may not be secure, and hence allow Eliot> for approaches that address that problem. Perhaps it would help the discussion if you would describe such a solution. I think it might make it more clear what your real concern with this requirement is. Eliot> However, you need to consider your other requirements in Eliot> the context of such approaches. Again, I think examples would be useful here. Eliot> I also think Section 4.1 is unnecessary. Attempting to Eliot> simply repair passwords is one legitimate approach, but it Eliot> shouldn't be the only one. In fact, I would argue that you Eliot> are setting up users for very serious problems by Eliot> perpetuating an approach that requires them to either write Eliot> down their passwords or use the same one for multiple Eliot> sites. This section, IMHO represents a requirement for Eliot> poor modularity. I completely agree that approaches other than passwords should be supported. Section 4.1 says this today. However I do believe that support for things that have the same usability profile as passwords is an absolute requirement. In particular, I believe people need to go to a computer they have never used before and authenticate only with the information stored in their head. I'd rather follow this work up outside the IETF than lose this requirement. Eliot> Also, you have a number of editorial oddities. A "Google Eliot> paper" should be treated as any other reference, for Eliot> instance. Help with these is appreciated. Eliot> Finally, quite a number of your requirements are Eliot> unclear. Help adding clarity is always appreciated. Eliot> See for instance your first sentence in 4.1. The Eliot> second phrase is mystifying. I'll admit that it seems clear to me so your help in understanding the lack of clarity is greatly appreciated. Eliot> I would appreciate the opportunity to work with you on the Eliot> above issues, as well as improve your introduction, which I Eliot> believe warrants some additional effort (I am tempted to Eliot> ask that you include a glossary), I'm happy to work in the spirit of our rough consensus process with anyone who wants to
Re: draft-hartman-webauth-phishing-03.txt
I'm at an interop event this week, but I think I now get your concern with host security and section 4.1 and would like to propose fixes. Thanks for working with me to understand the concern. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
> "Andy" == Andy Bierman <[EMAIL PROTECTED]> writes: Andy> I think the inability of the IETF to make decisions in an Andy> open, deterministic, and verifiable manner is a major flaw. I for one do not wish for deterministic decision making in the IETF. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
> "Andy" == Andy Bierman <[EMAIL PROTECTED]> writes: Andy> This is not an alternative. If you are not willing to make Andy> your technical objections to a technical specification Andy> publicly, then they cannot be part of the IETF Andy> decision-making process. At one level I agree here. Andy> What's to prevent a WG Chair from "padding" the anonymous Andy> "votes"? If 5 people in public (WG meeting or mailing list) Andy> are for some proposal, and the Chair says, "I heard from 6 Andy> people who are against this, but don't want their identities Andy> known, so the proposal is rejected." Not acceptable. I think that would be unacceptable. I think that a WG chair going to people who expressed private concerns and saying something like "Hey, you need to express your concerns in public. They are shared; if all of the people who have these concerns bring them forward then we would have enough interest in dealing with this issue. You have a week," is entirely fine. I also think it is fine for a WG chair to look at private technical concerns, realize they are correct and raise them to the WG. "I received a private concern; that mail pointed out that the following trivial attack will break the security of this protocol. We are not moving forward until someone fixes this problem or someone explains why I'm misunderstanding the situation." It's probably even fine to say "I received a lot of private concerns. Are the people willing to make public comments firmly behind their support?" --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Withdrawing sponsorship of draft-housley-tls-authz-extns
Folks, after the various IPR disclosures were filed on draft-housley-tls-authz-extns, I asked for a second IETF last call to see if we had consensus to publish this document on the standards track given the IPR claims against it. That last call did not show the consensus I was looking for. So, we agreed we were going to send mail to the TLS working group and ask them for their comments on publishing the draft. We hoped that we'd see a consensus there. The chairs did ask for comments; see http://www1.ietf.org/mail-archive/web/tls/current/msg01688.html . Comments were provided, but there was not a consensus in favor of publication on the standards track either there or on the ietf list. I think there is a rough consensus against publication on the standards track. However it is quite clear that there is not a rough consensus in favor of publication on the standards track which would be required to do so. So, I am withdrawing my sponsorship of the draft and as far as the IETF process is concerned this draft is no longer under consideration for publication. One option that several people suggested is publication as an informational spec. I personally do not choose to sponsor this document for informational or experimental. often, it seems that we use informational as a way to publish things we cannot build a strong consensus behind. I think that process is generally problematic and would like to avoid it in this instance. Other ADs may consider sponsoring this document as an informational document; I would ask them to carefully consider whether that is the best use of the time they have to offer the IETF community. My conclusion is that for me personally, it is not. Publishing this document via the rfc editor independent submissions track is basically not an option because the IANA assignments require IETF consensus or standards action. That leaves the authors with several options: * Work with people to build consensus and try again later. Possibly working on discovering prior art or trying to revise the licensing terms. There should be a much higher bar for starting the process a second time, but perhaps that bar can be met. * Work on an alternative that does not have the IPR constraints. * Work on finding another AD to sponsor the document. I will not do so, and I'd advise my fellow ADs to think for a long time before taking on this draft, but I would not block another AD sponsoring the draft. * Rewrite this document as a sketch of what might be done rather than a protocol and go through the independent submissions track. * Drop the proposal. I'm sad that we have come to this point. I think this technology has significant value and wish we'd found a way to publish it. However we follow a consensus process for many valuable reasons and it is clear that the necessary consensus is not present in this case. Sam Hartman Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawing sponsorship of draft-housley-tls-authz-extns
> "p" == <[EMAIL PROTECTED]> writes:
p> Sam,
p> While it is at each AD's discretion not to sponsor some
p> document (and not initiate Standards Action), I don't think
p> this discretion should extend to having a veto at the IESG
p> table when the document and community input is considered ("if
p> you make changes I don't like, I'll withdraw my sponsorship").
p> It looks like our process rules don't really cover the case of
p> withdrawing sponsorship, but the existing IESG decision-making
p> process already allows an AD to object to publishing a
p> document, and I believe using a "sponsorship-withdrawal-veto"
p> instead is inappropriate.
The IESG internal process requires that anything going before the IESG
have a yes vote to be approved. I'm unwilling to vote yes on this
document nor am I willing to dedicate my time shepherding it through
the process. I believe that especially the allocation of my time for
individual submissions is entirely my decision to make.
I have left open the possibility that another AD would support this
work and choose to sponsor it.
But yes, I believe that the consensus of the IESG is that the sponsor
can remove their yes vote and that unless another sponsor steps
forward, that kills a document. We had a rather long discussion about
this and my understanding of the conclusion of that discussion is that
the IESG should not approve a document that no one on the IESG
affirmatively supports.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)
> "Lakshminath" == Lakshminath Dondeti <[EMAIL PROTECTED]> writes: Lakshminath> Folks, If you want the history of this thread, please Lakshminath> see the SAAG mailing list archive. Lakshminath> Thomas, To be clear I'm not sure that I* opinions have been given special treatment in this case. So, carry on with the discussion, but be aware that it may not actually have any binding to a specific incident in the IETF. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Role of IANA in approving assignments
> "Robert" == Robert Elz <[EMAIL PROTECTED]> writes: Robert> Date:Fri, 15 Jun 2007 09:28:29 -0400 Robert> From:Thomas Narten <[EMAIL PROTECTED]> Robert> Message-ID: <[EMAIL PROTECTED]> Robert> | Um, this train left the station a LONG time ago. RFC 2434 (and Robert> | existing practice) have given the role of approving assignments to the Robert> | technical/protocol experts that created that name space. That is why Robert> | we have IANA considerations sections. Robert> Of course - maybe my wording wasn't clear enough, but I didn't intend to Robert> replace that, merely to add the safety net "unusual case" mechanism in Robert> a different way than your proposal. Robert> This is just as the IESG approves the vast majority of new RFCs following Robert> the regular IETF process, but the RFC Editor can publish others if he Robert> feels inclined (after taking advice.) Robert> | But the buck has to stop somewhere, and in the IETF, that is the IESG. Robert> And in this case, this is exactly the point. IANA is the Robert> INTERNET Assigned Numbers Authority, not the IETF Assigned Numbers Robert> Authority - and the code points it assigns and the registries it Robert> maintains are used by the Internet as a whole, not just that part of Robert> it that participates in the IETF. For what it is worth, I completely disagree with this approach. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments
I'd like to draw the attention of the community to section 3 of draft-ietf-syslog-protocol-21.txt. This text contains text and a clarified model of the various layers in the syslog architecture and new terminology for the parties. I believe this is responsive to the ietf last call comments and I believe the changes have been discussed sufficiently in the WG. I am not asking for a new last call but I do want to make people aware of the text. If people believe a new last call is necessary please let me know now. Currently the document is scheduled on the Thursday, June 21 telechat. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-williams-on-channel-binding: IANA rules too complicated
Hi, folks. During IETF last call for Nico's channel binding draft, we added an IANA registry based on community feedback. ALexey's proposed registration rules involved an expert and a review list similar to how we handle MIME types or language tags. The IESG would like to push back on that registration process. We feel that in this instance, simple expert review is sufficient, and we don't need registrations to go to a review list. Unless there is strong support for the more complex registration process in the draft, we'd like to go to expert review. Sam Hartman Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-williams-on-channel-binding: IANA rules too complicated
>>>>> "Jeffrey" == Jeffrey Altman <[EMAIL PROTECTED]> writes: Jeffrey> Sam Hartman wrote: >> Unless there is strong support for the more complex >> registration process in the draft, we'd like to go to expert >> review. Jeffrey> The technical argument in favor of a review list, whether Jeffrey> a special list for this purpose or some pre-existing list Jeffrey> such as SecDir, is that it is not always easy to find Jeffrey> experts who are familiar with both of the protocols being Jeffrey> bound. As a result, having more reviewers is a safety Jeffrey> net. This is especially important for reviews of Jeffrey> security protocols. How would you feel about an optional review list? IESG experience has shown that mandatory review steps in previous registries tend to add frustration. There are cases where optional review lists do add value. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Updating the rules?
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes: >> Also from the draft: "At least for the strong security >> requirement of BCP 61 [RFC3365], the Security Area, with the >> support of the IESG, has insisted that all specifications >> include at least one mandatory-to-implement strong security >> mechanism to guarantee universal interoperability." >> >> I do not think this is a factual statement, at least when it >> comes to HTTP, which is where my interest lies. Keith> note that it is not necessary to have at least one Keith> mandatory-to-implement strong security mechanism to Keith> guarantee interoperability. consider, for example, a Keith> client-server protocol for which conforming servers are Keith> required to implement _two_ strong security methods and for Keith> which clients are required to implement _at least one_ of Keith> those two methods. this would ensure interoperability even Keith> though there were no single mandatory-to-implement for Keith> clients. The IESG has in fact noted that and brought it up as an option in some cases. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PKI is weakly secure
> "Masataka" == Masataka Ohta <[EMAIL PROTECTED]> writes: Masataka> Keith Moore wrote: >>> Also from the draft: "At least for the strong security >>> requirement of BCP 61 [RFC3365], the Security Area, with the >>> support of the IESG, has insisted that all specifications >>> include at least one mandatory-to-implement strong security >>> mechanism to guarantee universal interoperability." >>> >>> I do not think this is a factual statement, at least when it >>> comes to HTTP, which is where my interest lies. >> note that it is not necessary to have at least one >> mandatory-to-implement strong security mechanism to guarantee Masataka> What, do you mean, strong security? Masataka> Given that CAs of PKI can be compromised as easily as Masataka> ISPs of the Internet, PKI is merely weakly secure as Masataka> weakly as the plain Internet. I'd consider DH a fine strong security mechanism in a number of cases. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Updating the rules?
> "Bob" == Bob Braden <[EMAIL PROTECTED]> writes: Bob> At 08:38 AM 7/20/2007 -0700, Kurt Zeilenga wrote: >> No, an I-D is a Draft Standard. An RFC is a Standard. :-) >> >> -- Kurt Bob> No, and No. He just says that because under his rules he's probably published more draft standards than the IETF.:-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Action: RECHARTER: Kerberos (krb-wg)
Folks, it appears the IESG made an error in approving this charter. In particular, while we requested that the charter go out for external review and community comment, that appears to have never happened. The IESG is figuring out how we want to move forward. The obvious approach is to withdraw the new charter and request community input. It's certain that whatever we do we will seek community input and will treat the community input as if it had been received before the charter was sent out. At least we didn't accidentally close the WG; that's happened before too.:-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Requirements for Open IESG Positions
> "Soininen" == Soininen Jonne (NSN FI/Espoo) <[EMAIL PROTECTED]> writes: Soininen> Hi, I just happened to read this mail today. I don't Soininen> remember seeing such a mail during previous nomcom Soininen> rounds (they might have come, but I just didn't notice Soininen> them). I think this is a very good overview of the Soininen> requirements needed for the IESG positions and gives a Soininen> nice background to think about the people who would fit Soininen> the positions. Soininen> However, I think one of the areas is described a bit too Soininen> much in detail and perhaps give a wrong impression about Soininen> the job. The following extract is from the Security Soininen> Area: >> Specific expertise required for a Security AD includes strong >> knowledge of IETF security protocols. To complement Tim Polk, >> the person selected as Security AD should have a working >> understanding of Kerberos, GSS-API, SASL, and how these relate >> to security protocols and to their use in applications and >> other security protocols. A basic understanding of IPsec, IKE, >> TLS, PKI would also be useful. Soininen> I'm sure this is an oversight, but I think it is Soininen> generally not according the IETF process to specific Soininen> technologies and "hard coding" the division of work in Soininen> an area. To my understanding, the Ads in an area are Soininen> free to divide the work between themselves as they wish Soininen> according their strengths. So, if the a possible new Soininen> security AD would not be interested to look at these Soininen> technologies, perhaps Tim would look at them - according Soininen> the new division of work in the area. I tend to agree that this is not an ideal practice, but it has been going on for many years. The set of technologies listed there are things that I'm mostly doing these days with particular emphasis on things Tim doesn't have as much experience with. Last year, the description focused on areas Russ had the most experience in. It's kind of complicated to fix. If you stuck two security ads in with my experience or with Tim's experience it would not be ideal. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Requirements for Open IESG Positions
> "Jari" == Jari Arkko <[EMAIL PROTECTED]> writes: Jari> (I also thought that the SEC requirements were a bit too Jari> specific this year.) They are no more specific this year than they have been in the past. The only change is that they were at least specific in a direction that would actually compliment the sitting AD. I personally have never liked the way the security AD requirements were stated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures
> "Iljitsch" == Iljitsch van Beijnum <[EMAIL PROTECTED]> writes: Iljitsch> On 2-aug-2007, at 21:17, Dave Crocker wrote: >>> It was also interesting to open the Mac network control >>> pannel, enable my Airport (WLAN) interface, and see the IPv6 >>> global address appear almost instantaneously and in many case >>> having to wait many seconds to minutes for DHCP provided IPv4 >>> address to appear. >> Any chance this was merely due to a difference in scaling, with >> IPv4 DHCP usage being large-scale and IPv6 being small? >> I suppose the more constructive way to ask this is: Does anyone >> know why one worked better than the other? Iljitsch> I don't think there was any IPv6 DHCP, and if there was, Iljitsch> most hosts wouldn't have used it because they don't Iljitsch> implement it. The advantage of stateless autoconf over Iljitsch> DHCP is that with stateless autoconf, a singe router Iljitsch> advertisement multicast to all IPv6 hosts can provide an Iljitsch> unlimited number of hosts with address information (the Iljitsch> hosts still need to do duplicate address detection, but Iljitsch> since no reply means success it's hard to fail here) so Iljitsch> it's eminently more scalable than DHCP. Let's be clear here. The scaling properties of stateless autoconf are better than DHCP in cases where I want to give a uniform configuration to all nodes on the link and where all the configuration I want to hand out is supported by stateless autoconf. Issues such as giving hosts hostnames, dynamic dns updates, etc can change to the scalining properties of the entire IPV6 configuration experience to be different than the base scaling properties of stateless autoconf. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-shirey-secgloss-v2-08.txt
> "David" == David Harrington <[EMAIL PROTECTED]> writes: David> Hi, The issue was raised during ISMS WGLC that there is a David> difference between our use of the word authenticate and the David> glossary in RFC2828. Since ISMS extends SNMPv3, ISMS is David> using terminology consistent with the SNMPv3 standard, David> which reflects English usage. First, I'll only speak to 2828; 2828bis is not an IETF product and I disclaim all interest in it. David> I think re-defining the word authenticate is not a good David> idea. I think it will not help the IETF write clear and David> unambiguous specifications to redefine words for IETF usage David> that are already clearly defined in English. if we want new David> keywords, then the IETF should invent new terms, not David> redefine existing terms. It's my understanding that the definition of authenticate in 28282 is a subset of the English definition. If you don't think that is the case I'd like to hear your reasoning. David> I encourage the security community to provide an David> informational glossary. I recommend that if a document David> author wants to use terminology consistent with RFC2828bis, David> they should state that, and list the specific David> RFC28282bis-consistent terms used in their document in a David> "Terminology" section. Agreed. David> But I do not think the glossary terms should be required David> usage in the IETF, They are not required usage. However to the extent that they are agreed usage (and I think 2828 basically is), you need to have a good reason for using a different definition of the same word. "Please be consistent with the terminology we tend to be using elsewhere" is a reasonable (and often blocking) comment to make on a document. There are valid reasons to disagree with such a comment. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review of draft-hartman-webauth-phishing-05
Hi, Eric, responding as an individual. Obviously, I disagree with your basic claim that it is too early to write a document like this. I've asked the sponsoring AD to make a consensus call on whether we have sufficient support to be making this sort of statement. If not, then I'll be happy to take my document to the rfc editor. However I think it is completely pointless for us to argue about that particular issues: we're not going to agree. I disagree that the references need to be significantly expanded. I am familiar with the work you cited in your message. If you would like to propose specific text that improves the document and cites those references I'd like to consider your specific text suggestions. It seems you have read the document and think I favor ZKPP protocols. It's certainly true that in a world without patents I think they would be interesting to explore. However I wanted to discuss them mostly because I thought that the patent problem was important to turn out. It's certainly true that I have thought about what solutions I'd like to see. I think the solutions will likely be in the challenge response at the HTTP level or TLS-PSK space. I think the primary concern will be what we can manage to get deployed not protocol details. I've tried not to expose that too much in the document; I understand we disagree. I would like to make some changes based on your comments. First, I would like to make a pass to improve the separation between user interface and protocol. I doubt I'll get to a level you'll be happy with. Second, I'd like to address your comment about WPE and enrollment. Finally, I see no problem correcting areas where I was less precise than you wished I had been. Examples of this include conflating the TLS and HTTPS layer in the introduction. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Informational vs. Informational
>>>>> "Paul" == Paul Hoffman <[EMAIL PROTECTED]> writes:
Paul> On a thread about a specific document that is proposed to be
Paul> an Informational RFC coming through the IETF process:
Paul> At 1:12 PM -0400 8/20/07, Sam Hartman wrote:
>> I've asked the sponsoring AD to make a consensus call on
>> whether we have sufficient support to be making this sort of
>> statement. If not, then I'll be happy to take my document to
>> the rfc editor.
Paul> This is pointless. No one other than an expert at the IETF
Paul> process could differentiate between the two types of
Paul> Informational RFCs in RFC repository (and many IETF process
Paul> experts would not get it right on the first try). An
Paul> Informational RFC is an Informational RFC regardless of the
Paul> path that got it published.
The difference is the IESG note. I respect your belief that many
people would not understand that difference.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Informational vs. Informational
> "Eric" == Eric Rescorla <[EMAIL PROTECTED]> writes: Eric> Well, the difference is in part the IESG note. More Eric> importantly, the question is whether the IESG intends to Eric> hold future work to the requirements in this document. If Eric> they do, then this document needs significantly more review Eric> and a much stronger showing of consensus. Arguably, if they Eric> do it should be required to be PS or BCP. Obviously as an individual, I disagree that it would be necessary for significantly more review to take place. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes: >> Fourth, lots of folks (me included) happen to find it >> convenient to use NAT between my site/house/office and my >> upstream provider. Keith> do you also find it "convenient" that NAT has effectively Keith> thwarted the deployment of huge numbers of new Keith> applications, significantly raised the cost of deploying Keith> others, and harmed the reliability of all applications? I find the tradeoffs work in favor of NAT; I expect this to be true both for V4 and V6. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review of draft-hartman-webauth-phishing-05
>>>>> "Eric" == Eric Rescorla <[EMAIL PROTECTED]> writes: Eric> At Mon, 20 Aug 2007 13:12:51 -0400, Eric> Sam Hartman wrote: >> Hi, Eric, responding as an individual. >> >> Obviously, I disagree with your basic claim that it is too >> early to write a document like this. Eric> Not quite. My claim is that the IETF should not be Eric> publishing a document like this and then requiring that Eric> future work conform to it. I don't have a problem to it Eric> being published as basically a White Paper with a clear Eric> understanding that protocol proposals will not be held to Eric> this standard. Hence my suggestion for an IESG Note to Eric> formalize this understanding. I don't think it would be appropriate to publish this document as a BCP that future HTTP authentication work needs to be held to. I do hope that we have consensus these are good requirements, that it would be desirable to work on solutions that meet these requirements and that it would be a reasonable discussion to ask why particular work did not plan to meet these requirements or whether these requirements should be referenced in chartering work. I suspect you are not part of such a consensus if it exists. >> I disagree that the references need to be significantly >> expanded. I am familiar with the work you cited in your >> message. Eric> Yes, but the purpose of the references section isn't for Eric> you, but for consumers of the document. A document which Eric> does is neither an adequate guide to the state of the art Eric> (which this one is not) nor contains pointers to the Eric> literature does not serve the community well. I disagree that it is a goal of this document to serve as a guide to the state of the art nor is it necessary or desirable to contain pointers to the literature in this space. In general I've tried to cite sufficient sources to make the requirements clear , not to justify them. I believe this practice is consistent with a lot of IETF requirements documents. Obviously I will take direction from the proto shepherd or responsible AD if they believe I should be adopting different goals for when sources need to be cited. Eric> More Eric> importantly, if you're going to impose *requirements* on the Eric> community, they should be clearly informed by the existing Eric> state of the art. The only way to do so is to actually Eric> discuss that topic, not have the reader be forced to take on Eric> trust that the literature supports the author's position. I think we disagree in principle. However you mention a number of cases where the document would be improved by specific citations. I appreciate that feedback and will work on including citations. Eric> To give one concrete example, there is an emerging body of Eric> work (with the Shechter paper I cited being the best-known Eric> example) a variant of one of the techniques you specifically Eric> recommend in S 4.2 (a shared secret between the UI and the Eric> user, though in this case it was a shared secret with the Eric> bank with a similar UI metaphor) was shown to be of limited Eric> effectiveness. I will include discussion. Eric> To give another example: two of the other papers I cited Eric> (HWF05 and RJBMM05) describe UI-only mechanisms that provide Eric> for unique per-server passwords and a special UI with no Eric> modification whatsoever to the network protocol. I Eric> appreciate that you feel that other approaches are more Eric> promising, but the fact that this document but that doesn't Eric> mean that a document of this type should pretend that they Eric> don't exist. I'll take a look at where such a discussion could fit in and see if it makes sense. >> If you would like to propose specific text that improves the >> document and cites those references I'd like to consider your >> specific text suggestions. Eric> To be blunt, this is your job, not mine. We're talking about Eric> major rewriting, not a couple of paragraphs. We disagree about what the document should be trying to do. If there were someone interested in doing the work necessary to make the document cover the additional issues you'd like to see it cover, I think it would be a good idea to at least consider whether that is worth the delay. Absent such a volunteer, I think the main question before us is whether that work is necessary or whether we have a consensus that the current scope is OK. >> It seems you have read the document and think I favor ZKPP >> protocols. Eric> No, I think discussing o
Re: Review of draft-hartman-webauth-phishing-05
> "Paul" == Paul Hoffman <[EMAIL PROTECTED]> writes: >> I do hope that we have consensus these are good requirements, Paul> We absolutely do not have any such consensus. There was Paul> barely any discussion during IETF Last Call. There was not a Paul> mailing list for discussing the draft. Hmm. I actually think that as ad-sponsored informationals go this got a lot of constructive discussion in ietf last call. It was discussed on the dix and http-auth lists and at the WAE BOF. My perception of the room at WAE was that with the exception of the requirement about mutual authentication this was relatively non-controversial and that going forward with such a document would be useful. Now, we may actually be saying the same thing. I think this document has received review similar to other IETF informational documents. There's a lot of open question about what the status of such documents is; absent evidence such as an IESG note I assume such documents have rough consensus of the IETF. Others may not read things that way or may assume a different level of support behind informational documents for which we do an IETF last call. Ultimately though the issue of adequacy of review rests with Lisa and the IESG. I'm obviously recused from formal participation in that process. Paul> Speaking for myself, Paul> I didn't comment because I thought it was meant to be an Paul> Informational RFC saying what Sam Thinks About These Paul> Requirements. If I wanted to publish such a document I would have gone to the rfc editor. Paul> The IETF Last Call announcement said *nothing* Paul> suggesting that this was a consensus call. I thought all IETF last calls are consensus calls. Paul> It is inappropriate to change the intended use of this Paul> document after IETF Last Call. Here we agree. I'm not asking for treatment any different than any other AD-sponsored informational document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review of draft-hartman-webauth-phishing-05
Ah. I must admit that I find the whole concept of informational documents a heck of a lot less useful, but your reading of 2026 is of course correct. I'll probably still end up treating informational documents as close to ietf consensus statements (but not recommendations) in my head because honestly I cannot find any other way to think about it that makes any sense to me. I certainly view an informational docmuent that has gone through an ietf last call as a statement from the IETF. We'll add this to one of the many areas where I completely fail to get RFC 2026. I definitely don't want to block other work with this document. I think that to be particularly useful I'd like to get to a point where we can say that having authentication schemes that meet these requirements would be useful and that for some value of we significantly greater than me, we think that would be a useful step along the road to combatting phishing. I thought I was trying to have that discussion here; you at least seem to think that is not the case. At some future point we might charter work with the goal of doing something similar to those requirements; in such a case, we might decide to hold that work to these requirements. We're not discussing doing that today. If I believe there is a reasonable chance of success I'm willing to put in significant effort towards achieving my goal. Absent that belief I'm more interested in getting something out and working on running code. So, Here is a proposed IESG note that I think is consistent with my intent and RFC 2026: This document proposes requirements for HTTP authentication that are intended to help combat the problem of phishing. These requirements attempt to reduce the consequences of a user being tricked into using a server provided by an attacker instead of the server they intended to trust. These requirements have no normative force; publication of these requirements does not bind future work to follow them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review of draft-hartman-webauth-phishing-05
> "Henning" == Henning Schulzrinne <[EMAIL PROTECTED]> writes: Henning> Rather than an IESG note or in addition to, I think the Henning> author should clearly state, in the abstract, that this Henning> is a personal opinion only. I don't think my personal opinion would make a very useful document, but if that's all we can come away from this process with then that's all we will achieve. First, I'd rather try and build consensus and get more review. Failing that, I think we could come up with a way of describing the status of this document that does not give the impression that it has even less review than other documents that are of the same status. I.E. I think it would be an unfortunate outcome if we feel the need to add a bunch of warnings in this case simply because we've had a discussion and realized that we don't entirely agree on what our documents mean. I think making it clear that this is not normative is quite important. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review of draft-hartman-webauth-phishing-05
Hi. Both your and Eric's comments need a longer response. It was my intent to use strong and weak password equivelantsin the same way as the IAB document. We agree on what the IAB document defines the terms to mean. I'll go look through my text and clarify what needs clarification. I'm confused by your comments on 3.1. I agree with you that an attacker could take for example a login password in today's systems and use that to to gain the information necessary to spoof other UI. The primary goal of this document is to propose requirements that make it difficult for the attacker to capture such a password. What do you think I'm doing wrong in 3.1. Also in 3.1 you talk about on-path attacks. I guess this needs better wording because basically everyone who has read the document has commented on that phrase. So, examples of an on-path attack include mounting a MITM against TLS and hoping the user will click "accept this certificate" for the bogus cert you provide; DNS attacks; etc. I'm trying to say that attackers have these capabilities and that we need to evaluate both current and future systems against such attacks. How can I help clarify what I'm trying to say? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes: Keith> Hallam-Baker, Phillip wrote: >> If we can meet the needs of 80% of Internet users with some >> form of shared access there will be more addresses left for the >> 20% with greater needs. >> Keith> with 2**128 potential addresses, this is not only Keith> unnecessary, it's harmful. there's far greater benefit to Keith> be had by uniformity in address allocation, globally unique Keith> addresses, and consistent use of addresses end-to-end. I'll take ease in renumbering over application transparency for any large network. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
> "Chris" == Chris Drake <[EMAIL PROTECTED]> writes: Chris> Hi Alexey, >> And if you would like to suggest a better process for moving >> things forward, please share your opinion. Chris> Suggest: Properly document comments and reviews somewhere. Chris> Question: what's the best way to submit comments and Chris> reviews - can we just re-write the entire draft, annotating Chris> our changes, and submit that? You can. I'd find it more useful though if you simply sent in comments where appropriate. I.E. send a message to this list describing an issue with the draft and your comments on how to solve it. Specific new text is welcome but not required. However if you find that annotating the draft is the easiest way for you to get your point across do that. A new text version would be far more useful than an annotated pdf to me. Chris> Are professionals and Chris> experts even invited/allowed to comment? I think most of us consider ourselves computer security or web professionals. (I consider myself a computer security person more than a web person). we like to think that we have sufficient background to be qualified to make the statements we're making. So, yes, I think many of us consider ourselves experts in fields related to this work. I'm not sure anyone today can claim to be an expert in solving phishing as it's not particularly a solved problem.:-) But yes, comments from people who have subject matter expertise are greatly welcome. Chris> Is there a formal Chris> procedure for dealing with suggestions (eg: attributing, Chris> documenting, discussing, leading to an ultimate official Chris> public inclusion (or exclusion with reasoning). I don't know if we'll end up needing that level of formality; I'm hoping that mailing list discussion will be sufficient, but we can develop formality if we need it. If you're new to the IETF you may want to take a look at http://www.ietf.org/rfc/rfc4677.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-aboba-sg-experiment (Experiment in Study Group Formation within the Internet Engineering Task Force (IETF)) to Experimental RFC
I think we should explicitly say that SGs follow WG rules. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
> "Shumon" == Shumon Huque <[EMAIL PROTECTED]> writes: Shumon> And yes, I agree that a new properly designed version of Shumon> HTTP Digest authentication might be one way to help. As Shumon> well as the various zero knowledge protocols. I believe that http digest plus channel bindings does meet all the requirements that draft-hartman-webauth-phishing discusses for authentication systems. Clearly the protocol cannot define the UI issues. I'm not sure I prefer the approach of revising http digest, but I do believe it would meet the requirements of my draft. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Visa for South Korea
> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> writes: >>> What I'm really looking for is some form of official >>> government communication on the subject (unless of course the >>> hosts are the ones who are manning the passport control desks >>> at the airport). >>> >> So call the nearest Korean consulate/embassy. Answering this >> kind of question is part of their job. Ken> I actually already had put a call in to them; the relevant Ken> person was out of the office, but I left a message. We'll Ken> see what they say. I did as well and here is what I got. The phone was answered. I asked to speak to someone about Visa information. I was transferred to someone who answered in Korean; I did not understand the greeting. "Hi. I'm an American citizen traveling to Seoul in late February to attend a meeting of a professional society. Do I need a visa?" She asked again for my citizenship and then said that I did not need a visa. I chose to describe IETF as a professional society because saying standards development organization when referring to something non-ISO-based might confuse a government official. Similarly, I was concerned that conference might map to academic conference. I'd be interested in answers people get from other consulate/embassy staff both from locations other than Boston and with different phrasings of the question.
Re: [secdir] [New-work] WG Review: New IETF Standards Track (newtrk)
One item in the proposed charter concerns me greatly: The working group should also take into account other issues raised by the problem working group and during the newtrk BOF as needed. That does not sound narrowly scoped at all. It might be reasonable to take into account these items as they relate to the explicitly enumerated goals of the working group, but it does not seem reasonable to take into account issues that would create a new goal or expand the scope of the working group. --Sam
Proposed Standard and Perfection
Hi. For the past few plenary meetings, people have gotten up to the mic and complained that we've lost track of what proposed standard is all about. We take too long reviewing documents to make them perfect and would be better off just throwing them out earlier without so much review. I disagree. The point of proposed standard is not to throw a document out there and get comments, although of course we're always willing to listen to comments on our documents. The point of proposed standard is to throw things out there and get implementation experience. If specs are unclear, then we're not going to get implementation experience; we are going to waste time. I've had a lot of experience with a rather unclear spec with some significant problems that managed to make its way to proposed standard: For the past 10 years I have been dealing with problems in Kerberos (RFC 1510). IThis leads me to believe very strongly that catching problems before documents reach PS is worth a fairly high price in time. That said, I realize too much time can be spent on a review. When we're not sure we understand the implications of an issue well enough to know whether it will a be a problem, letting a document go to PS and getting implementation experience can be useful. Similarly, if the review process will never successfully conclude, then having the review early is good. ALso, I am simply saying that waiting for complete reviews is good and the pressure to get things out as PS faster with less review is dangerous. If there are ways to reduce time spent on the reviews without reducing quality, I recognize the value of these efforts.
Re: Proposed Standard and Perfection
> "Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes: Eliot> Sam, As the person who most recently complained, let me Eliot> elaborate on my comments. The problem I believe we all are Eliot> facing is that the distinction between Proposed, Draft, and Eliot> Internet Standard has been lost. Eliot> I agree with you 100% that... >> The point of proposed standard is to throw things out there and >> get implementation experience. Eliot> But when it comes to... >> If specs are unclear, then we're not going to get >> implementation experience; we are going to waste time. Eliot> We disagree (slightly). In my experience one needs to Eliot> actually get the implementation experience to recognize Eliot> when things are unclear. And my understanding is that this Eliot> is precisely why we have PS and DS. >> I've had a lot of experience with a rather unclear spec with >> some significant problems that managed to make its way to >> proposed standard: For the past 10 years I have been dealing >> with problems in Kerberos (RFC 1510). This leads me to believe >> very strongly that catching problems before documents reach PS >> is worth a fairly high price in time. Eliot> We come to different conclusions here. My conclusion is Eliot> that no standard should remain at proposed for more than 2 Eliot> years unless it's revised. Either it goes up, it goes Eliot> away, or it gets revised and goes around again. It's been under revision for all of that time. Eliot> Your fundamental problem with RFC 1510 is that it is too Eliot> painful for people to go and fix the text. And that's a Eliot> problem that should be addressed as well. nWell it certainly has been painful but because of a number of false steps and to some extent because of WG management issues, it has taken 10 years, not 2 years to revise RFC 1510. we might have gotten it down to 7 or 8 by fixing the WG management. Eliot> Thus, let the IESG have a bias towards approval for PS, and Eliot> let implementation experience guide them on DS and full Eliot> standard. But set a clock. It's in significant part because I think a lot of things may take more than 2 years to revise understand and fix that I believe this approach is wrong.
Re: Options for IETF administrative restructuring
Hi. First I'd like to start off by saying that I think Carl's document is a very good start for discussing these options. I support the recommendations made in section 3. I believe they are well justified and would be a great step in the right direction. Section 3 talks about clarifying the intellectual property ownership of the IETF's IP. One important area of IP ownership was not covered: the tools developed to perform the clerk function. I believe that the IETF should work to own these tools for several reasons. It will facilitate easier transitions from one vendor to another. It will facilitate accepting volunteer improvements to these tools. Finally, the IETF could make these tools available to other groups trying to solve similar problems. I suspect that these benefits would justify any additional expense involved in owning these tools rather than treating the clerk function purely as a service. Perhaps I'm wrong; I certainly feel that the IETF should explicitly understand what value it is getting if it decides to allow someone else to own tools developed to solve IETF needs. I do not think that recommendation 7 in scenario B is a good idea. I believe that plenary time is full enough without crowding it more. I'm concerned that the document doesn't really motivate Scenario C or D. It does describe them and it does list some of the disadvantages. However it doesn't really explain why they are on the table at all. I think they should be on the table; people have made arguments to that effect here. However the document doesn't do a sufficiently good job of capturing these arguments to explain why these options are sufficiently credible as to be worth examining. Where did the idea of forming a corporation come from; why would we want to do it again? Thanks for your consideration, --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Options for IETF administrative restructuring
>>>>> "Aaron" == Aaron Falk <[EMAIL PROTECTED]> writes: Aaron> On Sep 5, 2004, at 4:15 PM, Sam Hartman wrote: >> I do not think that recommendation 7 in scenario B is a good >> idea. I believe that plenary time is full enough without >> crowding it more. Aaron> What about a 'business meeting' that is scheduled in wg Aaron> slot or even on Sunday? If needed, this would be fine. I'm not convinced that open f2f time will be needed. However I think there is a simple test for whether the time is needed: can we come up with an agenda that fills a slot and meaningfully involves the community? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 62
Two things brought up in this thread disturb me. First, there seems to be the idea that we should be choosing where IETFs are held for political purposes--to make statements for or against certain governments. I'm not quite sure this was said or implied, but if it was, I'm made a bit uncomfortable by it. I certainly understand we should carefully consider situations that make people unable or unwilling to attend an IETF. Maximizing the number of active (and potentially active) participants who can make it to a meeting is a valid thing to consider. If the political policies of a country make it hard to get the people we need in that country then we should go there less frequently or not at all. Note that one way these policies can make it hard for us to get the people we need in a particular country is for these people to be unwilling to travel to that country. However in similar situations (not all of them within the IETF context) I've seen the desire to avoid a particular country go beyond what is justified by a desire to make the conference accessible. In some cases it seemed to venture into the realm of political statement. The conference seemed to want to say that they were taking a stand against the policies of a country. That is dangerous: getting involved in politics may compromise our ability to construct the best Internet we can. There may be some cases where we must get involved in politics; I'm skeptical that any involve conference venue selection. Even worse, it sometimes seems like the desire is to go beyond a statement and actually punish countries by not going that. That's just stupid; we end up punishing our own attendees from those countries, not the countries themselves. Again, I'm not sure I see this problem in this thread. It's not entirely clear what peoples' motivations are. I know that I feel more comfortable with the outcomes of discussions based on fair distribution of travel and convenience of participants than I do with the outcomes of discussions based on fingerprinting, rules and who is involved in a particular country's decision making process. This is true even when the discussions produce identical results; the process matters. Secondly, I'm concerned that people are proposing optimizing for pleasant climate and good vacation spots. I come to the IETF to get work done; I'd rather be at meetings where the other participants have the same goal. We should be somewhat careful of optimizing for enjoyable location. I'd rather see us optimize for who can attend and cost. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Scenario O Re: Upcoming: further thoughts on where from here
I'd like to express general support for scenario O. I probably will not have time to read the document in sufficient detail to agree with every point, but this looks like a good direction. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: My views on the Scenario O & C
> "Bob" == Bob Hinden <[EMAIL PROTECTED]> writes: Bob> The ISOC is certainly not perfect and has had serious Bob> problems in the past. These problems have been solved and as Bob> far as I can tell the ISOC is working well. I would note Bob> that the ISOC was initially set up by competent people with Bob> the best of intentions, but things did not work out as Bob> originally planned. Would you mind summarizing these problems for those of us who are relatively new to the process? Thanks, --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
> "scott" == scott bradner <[EMAIL PROTECTED]> writes: >> If you understand the open source position and disagree with >> it, then there's probably little more to say. scott> If the position is that the open source community can take scott> an IETF consensus-based standard, modify it and claim that scott> the new version is the "real" standard then I do disagree - scott> I think that standards must be developed and modified in scott> open consensus-based processes, not by individuals or scott> groups unrelated to the group that developed the standard. The open source community definitely wants to be able to guarantee to its users the ability to take text or code from an IETF standard and use that text or code in derivatives of that standard. Parts of the open source community want to be able to claim that that standard is the real unmodified thing. Other parts of the open source community would be happy changing the name of the work and clearly indicating what it is. Areas where a discussion might be useful would be to explain why the open source community wants to do this etc. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
> "scott" == scott bradner <[EMAIL PROTECTED]> writes: scott> seems to be a reliable way to ensure that there are scott> multiple understandings of what the standard actually is - scott> I find it hard to understand who that is good for Do you think that trying to describe a modified version of TCP without taking text from the original RFC is likely to lead to a better situation? Honestly I think the issue of whether derivative works can use text from the original is distinct from whether derivative works can be confused with the original. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
> "Margaret" == Margaret Wasserman <[EMAIL PROTECTED]> writes: >> Areas where a discussion might be useful would be to explain >> why the open source community wants to do this etc. Margaret> While it might be interesting to gain this insight into Margaret> the motivations open source community, I don't know that Margaret> it would be pertinent to the issue at hand. I've always found that understanding someone's position is an important and necessary step to determining if it is a good idea. I don't think a discussion of whether this is a good idea for the Internet would be useful without first understanding the positions of the people who think it is a good idea. But if you have a different way of building consensus feel free to pursue that way. Some questions I'd suggest you consider: * Have the IETF's current IPR practices actually limited any company's ability to embrace and extend Internet standards? * Have the current IETF's IPR practices limited the ability of any company to explain how it has extended Internet standards when it chooses to do so? * What problems are created if the IETF fails as an organization? Would a successor be able to take existing standards and produce standards based on them? How do the IETF's IPR processes make this easier or harder? --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes: Eric> You've had two direct warnings about this -- the ASF and Eric> Debian open letters. They interpreted IETF's passivity on Eric> the Sender-ID patent issue as damage and routed around it. Eric> If the IETF doesn't get its act together, that *will* happen Eric> again. The open-source community and its allies will have Eric> no choice but to increasingly route around IETF, and IETF Eric> will become increasingly irrelevant. I'm a bit confused here. As I understand things, Debian and ASF provided input to an IETF consensus call. They asked us not to approve a standard that depended on certain IPR. Based on that input and other input received by the working group, the chairs decided that they did not have consensus to advance a standard based on this IPR. I.E. The IETF did exactly what Debian and ASF asked us to do. That seems like a reasonable outcome under our process. It also seems directly consistent with what Debian and ASF asked the IETF to do. Could you help me understand your concern? --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: isoc's skills
> "Dave" == Dave Crocker <[EMAIL PROTECTED]> writes: Dave> My focus is on knowing what the details of the jobs are that Dave> we want done. Referring to the interface(s) is a convenient Dave> technique for trying to surface those details. Dave> Currently we do not have the details. What we are doing is Dave> like buying a building or a vehicle before we really Dave> understand what uses they are going to be put to. This Dave> leads to thinking that those details are trivial. They Dave> aren't. I think many of us agree with you that we do not know the details. I believe we also agree that we will eventually need to know the details. I don't seem to require the details you are asking for to feel like I'm making an informed decision between the two scenarios. I think thas' because I cannot imagine how the sorts of details you are talking about could influence my decision at this level. Could you perhaps come up with two possible parts of the answer for what we're trying to accomplish here that influence the decision between the two scenarios? If you could show one possible job we might want done that favors a corporation and another that favors working within the ISOC struture, you would go a long way to showing people that we need to discuss the kind of details you are asking for now instead of later. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
> "Brian" == Brian Rosen <[EMAIL PROTECTED]> writes: Brian> You guys don't have a problem with the "defensive Brian> suspension"/"no first use" clauses, do you? There is not consensus in the free software community on this issue. I believe the Open Source Initiative (opensource.org) is OK with such clauses. Debian (debian.org) is not although there are some of us within Debian who question this decision. I don't know what the FSF's stance is on this issue. This is one of the many reasons why I think the free software community needs to get together and decide what it wants *before* coming to the IETF. Again, I'm not proposing that the free software community can change the IETF's IPR policies We had that debate recently and it's clear there is not consensus to change it. I do think that some patent holders want to make their technology available to the free software community. I believe that if the free software community agreed on what it wanted, it would be reasonable for the IETF to pass that along to IPR holders as information to consider when drafting proposed licenses. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: CRAMing for last call
> "Lyndon" == Lyndon Nerenberg <[EMAIL PROTECTED]> writes: Lyndon> Finally, we need to address the issue of the MD5 "break." Lyndon> I have held off from commenting on this issue until the Lyndon> community has seen explicit evidence of the attack, and Lyndon> the implications of it. At this point, I don't know if the Lyndon> document deserves a writeup on the attack. Theory abounds, Lyndon> but I haven't yet seen a practical attack that works in Lyndon> the general case. We should at the least make mention of Lyndon> what has been discussed, and point to the literature, but Lyndon> I don't think the document deserves to discuss all the Lyndon> possible attacks. This doesn't mean to discourage anyone Lyndon> from contributing text to the Security Considerations Lyndon> section (please do). The security area seems to believe that hmac-md5 is still OK, at least for now. Especially since cram-md5 does not require much structure for the challenge, we should discuss the issue in the security considerations section. Will you need agenda time at the next meeting? If so, can you give an estimate of how much and what we want to cover? Thanks, --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Should IAB chair be a voting member of IAOC
> "Erik" == Erik Huizer <[EMAIL PROTECTED]> writes: Erik> My sense is that an IAB chair is probably very well informed Erik> and will have very good insight into all the issues Erik> surrounding the IASA. Therefore it makes sense to give the Erik> IAB chair a vote. The reason it would not make sense to do so seems to be (as I understand it) that doing so might allow the IAB chair to focus less energy on the IASA and more on Internet architecture. In my mind the question boils down to are IAB chairs likely to want a vote? IF so, we should give it to them. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Executive Director
> "Carl" == Carl Malamud <[EMAIL PROTECTED]> writes: Carl> It seems to me that one of the goals of the whole AdminRest Carl> exercise has been to move overall management responsibility Carl> for IETF admin. and support activities (IASA) from Carl> contractors to a "program manager", which is what this BCP Carl> is all about. As such, it seems that where documents refer Carl> to "IETF Executive Director" that should become (via a Carl> paragraph in this BCP) a pointer to the IAD or other Carl> appropriate position as further pointed to by the IAD. I think the IESG's concern here is that they, rather than the IAOC would like to designate who the executive director is. The executive director is very involved in making the IESG and process functions run smoothly. It seems like significant friction would be created if the executive director was not someone the IESG was comfortable with. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Finances and Accounting - principles
> "John" == John C Klensin <[EMAIL PROTECTED]> writes: John> Bert, _Far_ too much detail. See earlier note about the John> bank account material. I suspect that I speak for many John> members of the community when I say that I want to get this John> "admin" stuff fixed, and fixed as quickly and efficiently as John> possible, after which I Do Not want to have to revisit it at John> regular intervals, through Last Calls or otherwise. So, what level of detail do you think is appropriate? Is the community still interested in guaranteeing that the IASA is reasonably seperable from ISOC if necessary? How much detail is needed to allow the community to evaluate whether the IASA will in fact be seperable? Is it sufficient to simply state seperability as a goal or do we want to deal with specific details like the bank account? Personally, I do believe that stating some details would help me evaluate whether IASA is seperable and would require the IETF's consent in order to change the details. I do think that requiring IASA keep separate bank accounts is probably desirable at the BCP level. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Issue: Budgeting process and financial oversight
> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes: Harald> Quoting from section 3: >> The IASA will initially consist of a single full-time ISOC >> employee, the IETF Administrative Director (IAD), who will be >> an officer entitled to act on behalf of the IASA at the >> direction of the IAOC. The IAD is likely to draw on financial, >> legal and administrative support furnished by ISOC support >> staff or consultants. Allocation of costs for ISOC support >> staff and consultants will be based on an actual expenses or on >> some other allocation model determined by consultation between >> the IAOC and ISOC. Harald> I think that is the right division of labour (the IASA Harald> *does* the work, the IAOC *oversees* the work, and the Harald> IAOC is *not* part of IASA). So any power that implies Harald> *doing*, including chartering committes that help define Harald> or refine the support for the IETF, should be given to the Harald> IAD, not to the IAOC. Any committee that does *oversight* Harald> (for instance an audit committee) should be chartered by Harald> the IAOC. This makes sense to me. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
> "Michael" == Michael StJohns <[EMAIL PROTECTED]> writes: Michael> It seems to me that neither ID status nor RFC status are Michael> appropriate for these documents. The ID series is, by Michael> design, ephemeral and generally not citeable. The RFC Michael> series is stable and citeable, but the lead time for Michael> introducing an RFC is somewhat north of 30 days or more. Michael> I hate to open Pandora's box, but what I think we need is Michael> a citable, stable document series that has a production Michael> lead time similar to that of the IDs. I would probably Michael> limit this to the non-technical administrivia we've been Michael> recently inundated with. Michael> *sigh* Please provide some justification. You said that you needed these things but you didn't really say why. I also don't understand how this is any different than work that goes on in a lot of protocol working groups. I'm particularly confused about why we would have documents that we neither want to be long-lived but that we cannot be bothered to resubmit every six months. If we want the document to be long-lived, what is wrong with RFC publication? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: IASA BCP: Separability
> "Margaret" == Margaret Wasserman <[EMAIL PROTECTED]> writes: Margaret> At 3:41 PM +0100 12/1/04, Brian E Carpenter wrote: >> Yes, I've always assumed there will be an MOU between IETF and >> ISOC, both to recognize the BCP when we have it, and to make >> explicit some of these boundary conditions. Margaret> This is interesting, because I had not assumed that Margaret> there would be a separate MOU... I had sort of assumed this BCP would be the MOU to the extent that one existed. I don't object to other arrangements though. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5
> "Scott" == Scott Bradner <[EMAIL PROTECTED]> writes: Scott> but as I said before - I expect we will be close to failure Scott> if the IAD proceeds on the basis of a close vote in the Scott> IAOC. I'd rather that mininum vote required to proceed (in Scott> those cases where a vote is needed because of disagreement) Scott> be a majority plus one I disagree. One area consensus-based decision making deals very poorly with is the ability to make a decision between two close but both quite acceptable options. For example let's say the IAOC is deciding between two possible contracts and both contracts are acceptable to all the members. Some prefer one; some prefer the other. This actually comes up reasonably often and voting with majority wins is a fine solution. Presumably the IAOC will have flexibility to define super-majority requirements for classes of decisions that they believe might require these decisions. Also, if an unacceptable decision is made, it can be appealed. I think saying less is better than more in this instance and thus support the current text. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: section 5.3 B
> "Scott" == Scott Bradner <[EMAIL PROTECTED]> writes: Scott> section 5.3 goes on to say Designated monetary donations Scott> will be credited to the appropriate IASA account. Scott> a left over reference to a seperate account To me this doesn't imply bank accounts; internal accounting that tracked IASA items separately would seem to fit this requirement. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: created IPR
> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes: Harald> --On fredag, desember 03, 2004 10:19:23 +0100 Henrik Harald> Levkowetz Harald> <[EMAIL PROTECTED]> wrote: >> What about this text, (added to 2.2.6): >> >> "As a matter of principle the IAOC and IAD should ensure that >> any contracts for IASA clearly designate that any software, >> databases, and websites developed should be available to the >> IETF with no restriction by the contractor. Software should be >> open source and data should be made available to the IETF in >> machine-readable format, also in cases where it may be >> inadvisable to make the data openly available." >> Harald> this works for me (my only problem is stylistic - it's Harald> somewhat long for a principle, so may fit better in the Harald> "details" sections, if a place can be found for it). I like the spirit of this as well. I think it would be nice for the software developed with IETF money to be open source especially in situations where there is not a compelling reason to do otherwise. I think that data should generally be openly available, with exceptions for things like mailing list subscriptions, archives of private mailing lists, etc. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes: Harald> In some other argument in some alternate universe, I said Harald> about the appeals issue: >> I see three alternatives: >> >> - Individual decisions of the IAOC cannot be appealed/reviewed >> by anyone - We invent an entirely new process from scratch just >> for IAOC matters - We funnel appeals against IAOC into the >> existing appeals process >> >> I dislike the first and second choices (the first because it >> raises the risk that one will have to resort to the recall >> "control"; the second because inventing new process mechanism >> is *hard*), so by Hobson's choice, I like the third. Harald> A theory I agree. In decreasing order of preference: 1) Allow decisions to be appealed but allow the bodies to which appeals are made quickly decide not to accept an appeal and to establish procedures for avoiding being swamped with appeals. 2) Allow appeals to be made but set some bar for an appeal; perhaps appeals from IAOC members are always accepted, but appeals from the community require say 10 signatures. 3) Significantly limit appeals process; restrictions on only appealing process issues, appeals are advisory, etc. I'd rather end up having to revise the appeals process because it is a denial of service than to regret not having the mechanism when it is needed. We do probably want text in the document that makes it clear decisions cannot be overturned once steps like signing contracts or hiring people have happened. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: created IPR
> "Margaret" == Margaret Wasserman <[EMAIL PROTECTED]> writes: >>> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> >>> writes: Harald> this works for me (my only problem is stylistic - it's Harald> somewhat long for a principle, so may fit better in the Harald> "details" sections, if a place can be found for it). >> I like the spirit of this as well. I think it would be nice >> for the software developed with IETF money to be open source >> especially in situations where there is not a compelling reason >> to do otherwise. I think that data should generally be openly >> available, with exceptions for things like mailing list >> subscriptions, archives of private mailing lists, etc. Margaret> I generally agree with these things, too. However, I Margaret> think that trade-offs/decisions regarding the IP rights Margaret> associated with IT tools are decisions that the IAOC & Margaret> IAD should be entrusted to make. Agreed. I'm happy giving some guidance in the BCP. I'm also happy not doing so. I would not be happy placing requirements on the IAOC on this issue in the BCP. Margaret> I also think that the IAOC should structure our Margaret> contracts so that the IASA function has access to all of Margaret> the data associated with our operations (documents, Margaret> tracker state, e-mail archives, etc.). I don't Margaret> necessarily think that the IETF (the open community of Margaret> Internet folks) should have unrestricted access to all Margaret> that data, though. Completely agreed. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
> "avri" == avri <[EMAIL PROTECTED]> writes: avri> And I don't think we want to get into a situation where we avri> have one member of the IAOC appealing the actions of the avri> IAOC. I do. Or rather in cases where that happens, I'd treat the appeal very seriously. Being reasonable is one of the criteria we use for selecting our leadership. If that leadership still feels a decision is worth appealing even knowing the consequences and pain of such an appeal, then I'm very interested in what they have to say. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
> "avri" == avri <[EMAIL PROTECTED]> writes: avri> OK, I am open to the idea. And I suppose that the current avri> appeal mechanisms would allow it. avri> But in that case I do have a problem with making the barrier avri> higher for appeals originating from a non IOAC member. avri> While I can see arguments for not removing an IAOC's avri> member's right of appeal, I don't see any arguments that avri> should give them any greater right of appeal. I.e. I would avri> have difficulty supporting a mechanism that weighed 1 IAOC avri> member versus 10 non members as suggested in your original avri> message. The reason you want to require say 10 signatures is because you want to avoid a denial of service attack on the process. You don't want someone who lost a contract appealing unless there were significant process irregularities. My assumption is that if the members of the IAOC want to gum up the works with useless appeals, you might as well get the recall petition started. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus(2)? IPR rights and all that
> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes: Harald>6. The IETF, through the IASA, shall have a perpetual Harald> right to use, display, distribute, reproduce, modify and Harald> create derivatives of all data created in support of IETF Harald> activities. Harald> (Jorge liked "perpetual" better than "irrevocable Harald> permanent" - the stuff after "to" is a well known legal Harald> incantation). This works for me provided that the legalese gives us the right to sublicense these rights to others. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus(2)? IPR rights and all that
>>>>> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes: Harald> --On tirsdag, desember 07, 2004 04:49:36 -0500 Sam Hartman Harald> <[EMAIL PROTECTED]> wrote: >>>>>>> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> >>>>>>> writes: >> Harald> 6. The IETF, through the IASA, shall have a perpetual Harald> right to use, display, distribute, reproduce, modify and Harald> create derivatives of all data created in support of IETF Harald> activities. >> Harald> (Jorge liked "perpetual" better than "irrevocable Harald> permanent" - the stuff after "to" is a well known legal Harald> incantation). >> This works for me provided that the legalese gives us the >> right to sublicense these rights to others. Harald> That's more than we currently ask people to assign to the Harald> IETF when making submissions to the IETF (RFC 3667) - Harald> there, we ask only for permission to use it within the Harald> IETF process (which may mean some sublicensing, and may Harald> not). Not sure what we should write here - I wouldn't want Harald> to write something here that would require reopening RFC Harald> 3667 for consistency. well, I do happen to think 3667 is broken, but agree with you that we do not want to open that can of worms at this time. However if we change contractors, we need to have the necessary rights to give the new contractor the rights to use our data. I believe that is an absolute requirement. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
bcp-02: Section 3.4
I'm not very comfortable with the appeal text in section 3.4. There isn't a way to overturn decisions and there is no way to appeal decisions because the wrong decision was made. I understand why the current text is there. I understand there are significant concerns about having either of the things I'd like to see in an appeal system. I will try and think of constructive ways of getting better appealability without destroying the IASA's ability to do its job. I'm also not sure how uncomfortable I am with the current text. I know I don't like it, but it's hard to tell how strong that feeling is. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
> "Bruce" == Bruce Lilly <[EMAIL PROTECTED]> writes: >> Date: Sat, 11 Dec 2004 12:14:42 -0800 From: "Randy Presuhn" >> <[EMAIL PROTECTED]> Subject: Re: Ietf-languages >> Digest, Vol 24, Issue 5 To: <[EMAIL PROTECTED]>, >> <[EMAIL PROTECTED]> Message-ID: >> <[EMAIL PROTECTED]> >> >> Hi - >> >> > From: "Bruce Lilly" <[EMAIL PROTECTED]> > To: >> <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: >> Friday, December 10, 2004 4:54 PM > Subject: Re: Ietf-languages >> Digest, Vol 24, Issue 5 ... > Eliminating bilingual >> descriptions for the language, > country (and UN region) codes >> leaves implementors > in a quandary. ... >> >> Huh? These are language TAGS. If, for some reason, some >> implementor thought it made sense to display one of these in a >> localized form (rather than just using them to determine what >> locale, etc. should be used in rendering some text) there's no >> requirement that the English-language country names that appear >> in the registration be used. Bruce> That's not the point. The point is that under RFC 3066, the Bruce> bilingual ISO language and country code lists are Bruce> considered definitive. An implementor can (and has) Bruce> therefore use those lists for (e.g.) providing users with Bruce> menus (in either language) from which a language or country Bruce> code may be selected. By declaring the ISO lists no longer Bruce> definitive, and by providing only English descriptions of Bruce> the codes in the proposed revised registry which would be Bruce> used instead of the ISO lists, the draft proposal deprives Bruce> implementors of being able to provide that functionality Bruce> (viz. an official description in French of codes). Programming lore has the rule of zero, one or infinity; it goes by many other names but the concept is in part that by the time you need more than one of something, you'll probably need a lot of that thing. Language descriptions seem to fit this rule fairly well. By the time we need to support multilingual language descriptions, we'll need more than just English and French. That means implementers today already have to deal with the fact that they only have some of the language descriptions they need from definitive standards. They will already have to get descriptions for other languages. Since they are already using non-definitive language descriptions, implementers can feel free to take the French descriptions from the ISO standard for the many cases where the IANA registry and ISO standard overlap. Why is two definitive languages better than one definitive language and one set of descriptions from an ISO standard? --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: bcp-02: Section 3.4
I've been thinknig more about the issue of the appeal process. Here are some of the questions I have considered and the answers I've found. First, can I provide something I'd like better than the current text? The obvious candidate is the text in draft-ietf-iasa-bcp-00. This would be problematic for two reasons. First, I don't think we could get a consensus in support of that text. Second, several people pointed out a real potential for abuse of that process. The concern that the IASA would not be able to do its job because of various appeals is serious. Harald also pointed out that designing appeals processes are hard; we should not do so if we can avoid it. I do not believe I'm capable of designing a process that is not subject to abuse and that meets my concerns in the time available. Is the appeals process in iasa-bcp-02 a regression over the status quo? Currently there is no formal process for the IETF to appeal a decision of the secretary. In practice CNRI responds to concerns raised by the IETF chair. I'm aware of nothing that requires them to do so. As such, this process does not appear to be a regression. An important side note is that without an appeals process we seem to be doing moderately OK; it is likely that this process will not often be used. Do we have recourse if we find the appeals process in the BCP is inadequate? As others have pointed out we do have the option of a recall of some or all IAOC members. If that were all the choice we had, I would consider the current text unacceptable. However we also have the option of creating or revising a new appeals procedure. I'd hate to find ourselves in the position of doing that in response to a specific issue, but it is an option we have and an option appropriate to use if circumstances justify its use. Relying on this option is dangerous: if we feel that we are not in a position to design an appeal process now, how will we feel when faced with the urgency and division of a pressing process failure? In conclusion, I do not like the current text. However it seems like the best option available in the time we have. It is something I can live with. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
> "JFC" == JFC (Jefsey) Morfin <[EMAIL PROTECTED]> writes: JFC> Tax aspects on donations will, most probaly in many JFC> countries, call for donations to a legally incorporated JFC> entity. What is the IETF legal entity I am to write on the JFC> check and then claim for resulting tax benefits for JFC> supporting research. No tax controller will buy that ISOC is JFC> an R&D lab. jfc The IETF is an engineering organization, not a research lab. Most of the funding will not go to activities that would traditionally be described as research. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
> "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes: Simon> In general, I support your goal of permitting free software Simon> to fully use IETF standards. A few specific comments Simon> below, which should be taken as encouragement to continue Simon> and refine the terms, not criticism against the whole Simon> approach. Simon> "Lawrence Rosen" <[EMAIL PROTECTED]> writes: >> 1. Everyone is free to copy and distribute the official >> specification for an open standard under an open source >> license. Simon> I would include "modify" in this clause, or clarify exactly Simon> which license you are talking about (e.g., GNU Free Simon> Documentation License). We've been over this before. In my mind, there is not a consensus to revise this part of the IETF IPR policy at this time. I'm not the chair of the IPR working group; this is just my opinion. However by conflating issues where you could get support with issues where you cannot get support you frustrate everyone and cause a lot of us to want to ignore you. If the open source community cannot work within the IETF process in a spirit of compromise and consensus building then that community will not make significant progress within the IETF process. Simon, you've identified a real issue the free software community has using our standards. If you do the leg work or find others who are interested in doing the leg work, you have a good chance at getting the problem you've identified fixed. However if you tie fixing that problem to other much more controversial issues, I doubt you will succeed. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
> "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes: Simon> [EMAIL PROTECTED] (scott bradner) writes: >> For IDN, I want to be able to extract the tables from RFC 3454 >> and use them in my implementation. >> >> For Kerberos, I want to be able to use the ASN.1 schema in my >> implementation, and copy the terminology section into my >> manual. >> >> For SASL, I want to incorporate portions of the introduction >> section from the RFC into my manual, to make sure some >> terminology is explained correctly. >> >> For GSS-API, I want to be able to copy the C header file with >> function prototypes into my implementation. >> >> just so there is no misunderstanding - the intent of RFC 3668 >> was to permit such extractions and there was (and is) no desire >> to restrict such extractions >> >> I, as editor, state publicly that I think that RFC 3667 permits >> such extractions, we (or maybe I) may have not made that clear >> enough in RFC 3667, but I think that RFC 3667 supports these >> uses Simon> I have received preliminary feedback from IPR specialists Simon> that seem to indicate to me that neither the old RFC Simon> copying conditions, nor the new copying conditions in RFC Simon> 3667, would permit all of the above extractions into free Simon> software. Simon> I am working on getting them to explain their reasoning on Simon> the Free Software Foundation's web pages (presumably at Simon> [1]), which I believe would be useful input for the IPR Simon> working group, but the process has been slow. I hope I'm Simon> not putting words in their mouth by stating that my Simon> interpretation of what they said is that there is a Simon> problem. Simon> Do the IETF care about free software enough to work on Simon> modifying the copying conditions of future RFCs? Speaking as an individual, *not* as an AD, I'd love to see the free software community get together and give input to the IETF (possibly in the form of an informational RFC) on the following issues: 1) Extracting tables and code from IETF standards for use in free/open-source software. 2) What patent holders who would like to license software should do if they want to create a license that open-source/free software authors can use when licensing technology in Internet standards. Such input should explain what the requirements are and should give both legal and practical reasoning to justify them. Such input should avoid trying to criticize or demand changes in the IETF, but instead should focus on what the IETF would need to do if we need to make parts of our RFCs extractable or what patent holders would need to do to make licenses useful to the free software community. I would strongly recommend avoiding discussion of the general patent policies of the IETF; arguments that the IETF should not use patented technology will only serve to annoy people who might otherwise listen to what you have to say. I'd recommend that any such input accurately represent at least the following parties positions': 1) The Free Software Foundation 2) The Open Source Initiative 3) The Debian Project I believe all three of these parties have slightly incompatible views on the issues in question. It would be very frustrating to consider such input only to discover that some segment of the open source community still felt we had not addressed their concerns even though the input was represented as complete. If you do get free software people to talk to the IETF about IPR, please find people who can work well in the consensus process. People who are good at explaining and understanding are better than people who have firm convictions and are good at arguing. However when explaining the needs of external communities participants would need to actually accurately represent these needs. It would be unfortunate if we came to a compromise that was acceptable to everyone involved in the consensus process only to find that it was unacceptable to the external community. Good luck, --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 7 - Removability - BCP
> "Scott" == Scott Bradner <[EMAIL PROTECTED]> writes: Scott> open from last version >> I'd change "BCP publication" to "using its normal consensus >> processes" (BCP is no magic term and may not survive the newtrk >> process) Scott> I did not see anyone speak up to support the use of the Scott> term "BCP" yet the term (the meaning of which may change in Scott> the future) is still used I like the term BCP in this iinstance. I think it is more clear than Scott's text. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
> "Lynn" == Lynn St Amour <[EMAIL PROTECTED]> writes: Lynn> over 80% of ISOC's org. members donate less than $10K Lynn> annually and managing these in a 'restricted accounting Lynn> manner' requires more effort and overhead. Also, Lynn> organizations/donors expect recognition appropriate to their Lynn> contribution and that implies differing levels of value and Lynn> distinction. The text you are objecting to is added specifically because of IETF concerns that individuals and smaller donors cannot ear-mark donations for the IETF under the current ISOC process. If that is going to continue to be true it is worth calling out to the IETF community and confirming they can live with that reality. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
> "Bruce" == Bruce Lilly <[EMAIL PROTECTED]> writes: Bruce> If there really are only 24 items of less than 11 octets Bruce> each, a trivial solution is to simply list them (with the Bruce> usual ABNF syntax) as literal strings. That should take no Bruce> more than a half-dozen lines. Perhaps. I actually find a lot of ABNF specs are not as clear as they could be to humans because they are trying to describe the valid inputs as strictly as possible. In many cases I think the spec would be more clear if the ABNF were relaxed and other constraints were expressed at appropriate levels. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
> "John" == John C Klensin <[EMAIL PROTECTED]> writes: John> Harald, John> Sorry, but I've got a procedural problem with this. I-Ds John> can't obsolete anything, even I-Ds approved by the IESG. John> While "fiddle with the RFC Editor note in the John> announcement..." may be the usual reason for delay, we all John> know that documents sometimes change significantly between John> the last-published I-D and actual RFC publication. In John> theory, the announcement could be posted, the IDR WG John> membership could take a look at it and conclude the AD's RFC John> Editor note does not reflect WG consensus, and an appeal of John> the announcement could be filed. As far as I know, that has John> never happened, but the procedures clearly permit it and I John> can think of a case or two when maybe it should have. While John> we have safeguards to prevent it, it is even possible that a John> document inadvertently would change enough during the RFC John> editing process that the WG would no longer believe it was John> an appropriate replacement for the earlier document. I don't think everyone believes the procedures work this way. A while back, there was a discussion on wgchairs about when the timer started for a standard moving to draft standard. My interpretation of that discussion was that it was the protocol action message that established a new standard, not the publication of the RFC. Personally I don't care how it works. I see both the points you raise and the arguments in favor of the wgchairs discussion. To me, either way of doing things would be valid. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
> "William" == William Allen Simpson <[EMAIL PROTECTED]> writes: William> John C Klensin wrote: >> Then these need the "bad" designation, not just the "not really >> interesting any more" one. And that, presumably, requires a >> "1828/1829 considered harmful" document, or at least a >> paragraph and a place to put it. >> >> William> Well, gosh and golly gee, I wrote an "ISAKMP considered William> harmful" about 6 years ago, and the IESG -- for the first William> time in its history -- ordered it removed from the William> internet-drafts repository (saying the IETF wouldn't William> publish anything critical of the IETF process). I wasn't following things closely enough at the time to have an opinion on what happened then. However I do have an opinion on the current process. Things change and sometimes improve. I'd like to think the IETF and the security area in particular are more open to criticism and to the realization that we may be wrong. I believe I have some evidence for this belief. There might be some reasons why it would be appropriate to remove a document from the ID repository--most of the ons I can think of have to do with copyright issues--but I don't think a document being critical of the IETF, its processes or technology would be such a justification today. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: #720 and #725 - Appeals and IAD autonomy
I think your proposed three changes are a significant improvement over the current text. As I've said, I am willing to live with the current text but do not consider it ideal. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #718 Transparency - reports on decisions
> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes: Harald> I suggest resolving this by adding the following text to Harald> section 3.4 "IAOC decision making", after the first Harald> paragraph: Harald> All IAOC decisions are minuted. Minutes are published Harald> regularly. I like the intent but don't like the word minuted. How about all IAOC decisions are recorded in the minutes of the IAOC. These minutes are published regularly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: #720 and #725 - Appeals and IAD autonomy
> "John" == John C Klensin <[EMAIL PROTECTED]> writes: John> --On Thursday, 23 December, 2004 09:42 -0800 Carl Malamud John> <[EMAIL PROTECTED]> wrote: >> Hi John - >> >> Your note seems like an outlier. In particular, it takes a >> really *strong* stance on protecting people from each other >> because people *will* act badly. For example, the way I read >> your note, the IESG will micromanage and the IASA/IAD will >> order bagels flown in daily from New York. Appeals will be a >> daily happening and people will hire lawyers instead of working >> it out. John> No, my concern is that John> (i) the IESG, or the IESG's leadership, is likely to John> micromanage because it has tended to micromanage, or try to John> do so, many of the things it has touched in the last several John> years -- the secretariat, the content of various documents John> down to the editorial level, the RFC Editor, and so on (some John> of that has gotten better in recent months or years, but John> that isn't the point). Even you have made the claim that John> they (for some instance of "they") have tried to micromanage John> you in terms of the contents of your various reports and John> recommendations. And the discussion of why the IETF and IAB John> Chairs had to be on the IAOC had, to me, a strong ring of John> "so we can make sure that administrative entity does exactly John> what we want", which is close to an operational definition John> of intended micromanagement. So that one isn't a corner John> case, it is a simple extrapolation from behavior that has John> been observed in the community (and commented upon in the John> Problem Statement work, which makes it feel like I'm not John> alone in those impressions). Micro-management is not the same as management. I actually think the IESG and IAB have done a good job of stepping in, applying management and solving some real problems over the years. I realize that I'm now part of the IESG and thus part of the organization that you believe is doing too much micro-management. However I haven't been involved in many of the past decisions and so I think that this response is at least mostly untainted by my involvement in the IESG.p So, I do see the IESG and IAB continuing to try and set priorities for the parts of the secretariat that influence the standards process. Clearly these priorities will need to be evaluated in the entire budget context by the IASA just as they are now evaluated by Fortec. I'm not sure what specific issues you believe are micro-management. However I contend that this BCP is not the right forum for these concerns to be addressed. If you have concerns about how the IAB and IESG are conducting themselves, there are several approaches you could take. First, you can provide input to the IESG and IAB about how they have handled specific issues and how they are handling issues before them. In cases where you believe it is necessary to do so, you can even appeal decisions. You can also provide feedback to the nomcom if you believe that a different set of qualifications or outlook is required for IESG and IAB members. --Sam, speaking only for myself ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: #720 and #725 - Appeals and IAD autonomy
> "John" == John Leslie <[EMAIL PROTECTED]> writes: John>The whole idea here, I thought, was to set up a support John> structure which would just work -- so that it could be John> "invisible" to the IESG and never need to be discussed by John> that group. (The problem, I thought, was that shortcomings John> of the current Secretariat were entirely too visible; and John> the IESG was spinning its wheels discussing them.) No, the secretariat function will and should not be invisible to the IETF. The IESG and IAB are likely to be in the best position to set priorities for the clerk function. The IESG is probably the body that would make a decision if people felt that a particular meeting location did not meet our openness requirements. The IESG is involved in approving a lot of scheduling requests. However the IESG and IAB are only one of the customers of the administrative function. Today if the IESG asks for something there's not a good way to know if the request is reasonable nor how it is prioritized. Understandably, Foretec's priorities are not quite the same as the IETF's priorities.They are a for-profit corporation accountable to their shareholders. To the extent that they do what the IETF wants, it is because they choose to do so. factors like good will, demonstrating to other potential customers that they do a good job and just wanting to be helpful are probably all important. One goal of the IASA is to bring this accountability into the IETF. The IASA needs to balance priorities coming in from the IAB and IESG against other needs and against available money.The IESG is expected to continue discussing secretariat functions although we hope the spinning the wheels (to the extent that it does happen--I don't know yet how much that is)will stop. And, as I said, the issue I'm raising is a key management and management-relationships principle. Whether one agrees with it or not, characterizing it as a corner case seems to me like a stretch. John>Let's review what John Klensin asked for: " " * the IETF John> has got to keep its hands off the day-to-day " decisions, John> even when they seem wrong " " I don't strictly disagree with this although I'd prefer something less restrictive. The structure should reasonably represent the costs of reviewing decisions so that decisions are not reviewed more frequently than is appropriate. Some may argue that this goal is difficult to achieve and that simply never reviewing day-to-day decisions is a better approach. John> * the IESG and IAB need to be John> prohibited structurally " from micromanaging, or managing at John> all, beyond the " degree that the IAOC wants to permit. John> They supply " input, they make requests, but decisions rest John> on the " IAOC side of the wall and stay there, with the only John> " _real_ recourse being to fire the IAOC It all depends on what you mean here by managing. The BCP explicitly calls out the IESG and IAB as important customers of the IASA--or did at one point. If you are a services organization you certainly should not be invisible to your important customers. It also seems like at least in practice your important customers will be able to create significant pressure to meet their priorities or to explain why this cannot be done in the money available. On paper, though, I agree that the decision rests with the IASA. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #718 Transparency - reports on decisions
>>>>> "Brian" == Brian E Carpenter <[EMAIL PROTECTED]> writes: Brian> According to Merriam-Webster online: Main Entry: 2 minute Brian> Function: transitive verb Inflected Form(s): min?ut?ed; Brian> min?ut?ing : to make notes or a brief summary of Brian> Brian Brian> Sam Hartman wrote: >>>>>>> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> >>>>>>> writes: Harald> I suggest resolving this by adding the following text to Harald> section 3.4 "IAOC decision making", after the first Harald> paragraph: All IAOC decisions are minuted. Minutes are Harald> published regularly. >> I like the intent but don't like the word minuted. How about >> all IAOC decisions are recorded in the minutes of the IAOC. >> These minutes are published regularly. >> ___ Ietf mailing >> list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf >> I was complaining about style, not grammar. I'd argue that the verb form of minute has low familiarity compared to the plural noun form. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
> "Soininen" == Soininen Jonne (Nokia-NET/Helsinki) <[EMAIL PROTECTED]> > writes: Soininen> x.x IAOC members compensation for labor, travel, and Soininen> other costs Soininen> The IAOC membership is considered voluntary. Hence, the Soininen> costs sustained by the members to participate in the Soininen> IAOC are not be reimbursed by the IASA or the Soininen> ISOC. These costs include but are not limited to time Soininen> used to perform duties of IAOC, travel to face-to-face Soininen> meetings and accommodation during the meetings, and Soininen> long-distance calls to IAOC teleconferences. I don't know about IAB calls, but with some exceptions IESG members do not pay to participate in the telechats. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
> "Wijnen," == Wijnen, Bert (Bert) <[EMAIL PROTECTED]> writes: Wijnen,> The current text in section 3, 1st para states Wijnen,> The IAOC consists of volunteers, Wijnen,> does that not say enough? I think it does. I haven't seen an argument for why more text is needed in the BCP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-phillips-langtags-08, process, specifications, and extensions
> "Christian" == Christian Huitema <[EMAIL PROTECTED]> writes: Christian> Could you please pursue this rather technical Christian> discussion on a specialized list, rather than the main Christian> IETF list? There is sort of this problem that most of this traffic is last call comments on a document. Our procedures require that last call comments be sent to ietf@ietf.org or [EMAIL PROTECTED] iesg@ietf.org is not a public list; so if you want to make a last call comment that is visible to the world, not just the IESG, you do need to copy [EMAIL PROTECTED] That said, I think this discussion could benefit from discussion on the ietf-languages lists with agreed summaries at the end of the last call period. Sam, speaking as an individual. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-phillips-langtags-08, process, sp ecifications,
> "Peter" == Peter Constable <[EMAIL PROTECTED]> writes: >> From: Dave Crocker <[EMAIL PROTECTED]> It occurs to me that a >> Last Call for an independent submission has an Peter> added >> requirement to satisfy, namely that the community supports >> adoption of Peter> the work. >> We take a working group as a demonstration of community >> support. Peter> You say "the community", though surely a working group is Peter> only representative of "a community" or a portion of "the Peter> community". No. The entire community reviews the chartering of the working group. It's sort of complicated; community consensus does not appear to be required by 3418 in order to form a working group, although I would expect someone to appeal if a WG was formed and there was a rough consensus against the formation of that group. I do agree that individual submission last calls have greater latitude than WG last calls. I think that "Even though the WG supports this, the IETF does not and thus we will not publish," is a valid outcome of an IETF-wide last call. IN practice it's harder to get that result than "The IETF does not support this individual submission; we will not publish." Speaking only to general process and not to the issue at hand. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #770 Compensation for IAOC members
> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes: Harald> I think this line of thought has died down without any Harald> great disagreement the consensus seems to be that the Harald> following sentence: Harald> The IAOC members shall not receive any compensation Harald> (apart from exceptional reimbursement of expenses) for Harald> their services as members of the IAOC. Harald> belongs in the document. I think that placing it at the Harald> end of 4.0 makes for the most reasonable placement I don't think it belongs; I think ekr made a compelling argument that this is a matter of policy not BCP. That said, I could still support the document if this were added. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #770 Compensation for IAOC members
>>>>> "Sam" == Sam Hartman <[EMAIL PROTECTED]> writes: >>>>> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes: Harald> I think this line of thought has died down without any Harald> great disagreement the consensus seems to be that the Harald> following sentence: Harald> The IAOC members shall not receive any compensation (apart Harald> from exceptional reimbursement of expenses) for their Harald> services as members of the IAOC. Harald> belongs in the document. I think that placing it at the Harald> end of 4.0 makes for the most reasonable placement Sam> I don't think it belongs; I think ekr made a compelling Sam> argument that this is a matter of policy not BCP. OK, too many things conflated. I agree saying that IAOC members should not get paid for time is appropriate BCP material. I missed all the wordsmithing that lead to the current text, but it looks like there were a fair number of messages. I won't pretend to be able to do better and since we need to say something we should say this. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: individual submission Last Call -- default yes/no.
Dave, I think that the requirements for a successful last call depend on how much review and interest have been demonstrated before the last call. For example, I recently last called draft-housley-cms-fw-wrap. It received no last call comments. What should I do with the draft? Well, in that case, I knew the draft had been reviewed (and changed based on comments) by several people in the S/MIME and security community. I also knew there was work on implementations and specific customers who plan to use the standard if approved. In my judgement as an AD, that was sufficient to justify bringing the document to the IESG even given no support in last call. There might very well be cases wher I'd bring a document to last call wher I was skeptical of the utility of the standard. I'd actually suspect that other tools for judging sufficient support before bringing a document to last call might be better, but last call is certainly a tool for judging support. In such a case, I might conclude that no comments were insufficient support. In conclusion, it seems like the ADs sponsoring documents have significant latitude in this area and that is a reasonable way for things to work. The community can complain that a standard is useless during last call; you can even say things like "I don't see the point; if others don't chime in and say they would use this, please do not publish." In addition, the community has multiple ways of giving feedback if they believe that there are systemic problems in the criteria ADs are using. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: individual submission Last Call -- default yes/no.
> "Tom" == Tom Petch <[EMAIL PROTECTED]> writes: Tom> I believe any individual submission should have a publicly Tom> identified, publicly accessible mailing list, perhaps listed Tom> in the I-D announcement, so that we can raise issues, Tom> hopefully resolve them, before last call. I believe sending such comments to ietf@ietf.org is a reasonable thing for you to do. Certainly that is what I would do if I had a public comment about a pre-last-call individual draft for which I didn't explicitly know of a better place. I recommend copying authors on such comments. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
> "Vernon" == Vernon Schryver <[EMAIL PROTECTED]> writes: Vernon> If the advocates for this I-D were really trying to follow Vernon> the IETF's processes, they would have taken one of the Vernon> suggestions for the next step and temporarily (or Vernon> permanently) retired from the field. It is clear that Vernon> there is no consensus to advance this document. Even its Vernon> authors have admitted that by talking about a new version. No, currently this draft is in Ted's hands. It makes no sense for people to withdraw drafts or to make any hasty decisions at all. In a situation where you get a lot of last call comments it is best for the pinvolved parties to get together and decide what to do next. Correct action is more important than prompt action. Many people suggested ways of moving forward. Deciding which of these is best will require some time. The process will work much better if the authors help make this decision than if the unilaterally withdraw their draft or do something like that. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
>>>>> "Vernon" == Vernon Schryver <[EMAIL PROTECTED]> writes: >> From: Sam Hartman <[EMAIL PROTECTED]> No, currently this >> draft is in Ted's hands. It makes no sense for people to >> withdraw drafts or to make any hasty decisions at all. Vernon> That's fine, but does suggest some questions: Vernon> - Is the Last Call over? The answer to this question is clearly yes. You can see this for yourself in the ID tracker. What this means is a bit unclear. If someone brought up a new comment that pointed out a new critical defect in the specification, the IESG would almost certainly consider the comment even though it was received after the last call period. However it is probably not useful to continue existing discussions of the draft. Vernon> - If so, was its result "no supporting consensus"? That's hard to answer or put another way, things don't quite work in such a way that that question has an easy answer. Procedurally speaking the responsible AD (Ted in this case) decides what to do next. He can ask for revisions; he can talk to the authors; he can try to create a working group; he can tell the authors he will not sponsor the draft; he can issue a ballot and put the draft on the IESG agenda. Those options are intended to be a fairly exaustive list of what an AD could do after any last call and are not intended to express any opinion about the current document. So, at some level you will just have to wait to learn Ted's opinion of the situation; the rest of us are also waiting for the same thing. Note that there are procedural safeguards. If an AD brings a document to the IESG that is not ready, other IESG members can object. If the IESG approves a document that is not ready, the community can appeal the decision. If an AD proposes a new working group, the community, IAB and IESG get to review the proposed working group. I hope this helps you understand the process. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus search: #725 3.4b Appealing decisions
> "Brian" == Brian E Carpenter <[EMAIL PROTECTED]> writes: Brian> Avri said >> I think creating the procedure to avoid so called 'DOS attacks' >> is, in effect, fighting a problem we do not have. Brian> But we do not have a body responsible to the IETF community Brian> today that awards commercial contracts. As I understand the Brian> concern, it's that when we create this body, we expose it Brian> to a real risk of people/companies misusing its public Brian> responsibility for frankly commercial reasons. As in Brian> mailbombing with messages like "why did you award the Brian> contract to A, when I have been told that B's bid was ten I tend to agree with Avri that we're solving a problem we don't know we will have. I'd prefer to leave open the possibility of a DOS attack and to have a mechanism for reviewing decisions. We can go close the DOS problem when it actually becomes a real issue instead of a theoretical one. That said, like Avri, it looks like I'm in a minority. I can live with the current text. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Firing the IAOC (Re: Consensus search: #725 3.4b Appealing decisions)
> "John" == John C Klensin <[EMAIL PROTECTED]> writes: John> --On Monday, January 17, 2005 2:34 PM +0100 Harald Tveit John> Alvestrand John> <[EMAIL PROTECTED]> wrote: >> ... The one thing that I agree sticks out is that the language >> of 3777 talks about firing *one* person - in the case where the >> group is dysfunctional, it may be better to take the group out, >> as you say. ... John> I think this is the only significant issue. The IAOC is John> either going to meet the needs of the community _as a group_ John> or it isn't. And, if it isn't, we should have a procedure John> for removing the whole crew. Otherwise, we will find John> ourselves back in the position that the community has, sad John> to say, sometimes found itself in with the IESG: the John> disfunction is obvious, but it is extremely difficult to get John> sufficient information to blame and remove one person as the John> key to the issues. [. . . ] John> Basically, I think we have running code that this is an John> issue, and we need to develop a mechanism --other than John> recall and non-reappointment of individuals-- for dealing John> with it should it occur. In my experience this has not been an issue and I don't believe we have evidence of that fact. I do believe that group dynamics are important and believe that throwing out the entire group is going to be dangerous. Without a strong demonstrated need, I believe that the potential harm of such a procedure outweighs any potential good. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
