Re: [Emu] Bar Bof on Federated Authentication Thursday at 9 PM during IETF week
Sent from my iPhone, wherein trimming posts is a challenge. :-) On Mar 9, 2010, at 7:51 PM, Glen Zorn wrote: > Suddenly I'm nostalgic for the days when bar BOFs were impromptu > affairs that sprang up in, well, _bars_ & were of necessity free of > PowerPoint infestation... And replete with alcohol. ;-) > >> >> ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 standard?
David Harrington writes... > As part of declaring IPv6 a full standard, would we also declare IPv4 > obsolete or Historic? Given the sheer number of IPv4 nodes in active use in the Internet, that move would seem premature, at best. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Obnoxious license
> > Can a copyright even be valid for just five lines of code? > > I'm told that in some jurisdictions even one line of code is > sufficient. Wow. That seems patently silly. Am I too late to copyright all calls to malloc() and free()? :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC archival format, was: Re: More liberal draft formatting standards required
> "Naïve" is a perfectly valid English word. (If your mail reader doesn't > display this correctly: that's an i with two dots on top instead of one) > Likewise is "coup d'état" an English word (e with accent). All loan > words from French, but nontheless English words. Yes, but in importing such words into English, we're perfectly happy to strip off the "decorations" that you mention. For example, when I look up naïve in Webster's New Universal Unabridged Dictionary (a large book, not an online service) it lists both the decorated and undecorated versions, with the undecorated version appearing first, indicating the more common usage. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC archival format, was: Re: More liberal draft formatting standards required
> This is clearly correct but many of us feel that correct display > in a browser is of higher utility to a greater number of potential > spec users. This seems to follow the currently popular "all the world is a browser" philosophy. I actually prefer plain-text for lots of uses, including email. I haven't yet heard any *compelling* arguments against the use of plain-text (ASCII or UTF-8) as the default and normative representation format for RFCs. Arguments, yes; *compelling* arguments, no. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Iljitsch van Beijnum writes... > I'm very disappointed that the silent majority of draft authors > isn't speaking up. I can't imagine that the vast majority of > draft authors has absolutely no problems with XML2RFC. My personal experience with XML2RFC, as an I-D and RFC author has been largely positive. There does seem to be a bug in the latest pre-release version around the use of ">" and "<" characters in ASCII art figures (as arrow heads). Other than that, I find it easy to use. It's true that the documentation is merely adequate, especially in the area of document meta-data. I find it to be generally consistent with other open source documentation. > The problem with XML2RFC formatted drafts and RFCs is that you > can't display them reasonably without using XML2RFC... All you're saying is that XLM2RFC isn't WYSIWYG. True enough. Neither is nroff. > ...and although XML2RFC can run on many systems in theory, in > practice it's very difficult to install and run successfully because > it's written in TCL and many XML2RFC files depend on the local > availability of references. I rely on the on-line, web-based conversion service. I'll admit that I've never gotten a local install of XML2RFC to work. > What we need is the ability to write drafts with a standard > issue word processor. Why? I suppose if there were indeed a *standard* word processor, this might be feasible, but I think by "standard issue" you mean "commercially available". ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Transport directorate review of draft-ietf-isms-radius-usage-06
Hannes Tschofenig writes... > Subject: Transport directorate review of draft-ietf-isms-radius-usage-06 > > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. Thanks for your review and your comments. > Since I am familiar with the work on RADIUS I had already a clue about > the direction the document when I read the title. Still, a diagram would > help with the basic idea. In some sense your document is based on a > fairly obvious idea, namely to use the RADIUS backend infrastructure to > relay authentication and authorization for SSH. So, a figure like this > one could help: > > ++ > |RADIUS | > |Server | > ++ > ^ > RADIUS + | Back-End > Management-Transport-Protection | Protocol >Framed-Management-Protocol | Support > | > v > +-+ +---+ > | Admin's | SNMP|RADIUS Client /| > | Device |<>|Network Device | > +-+ SSH +---+ Another reviewer indicated that a diagram would have been helpful to him, so we should probably consider adding one. > Regarding the following statement: > >The RADIUS protocol [RFC2865] provides authentication and >authorization services for network access devices, usually referred >to as a Network Access Server (NAS). > > This is not the only usage of RADIUS. See, for example, > http://www.ietf.org/rfc/rfc5090.txt > > The interesting thing is that you are defining a RADIUS usage that is > conceptually extremely close to RFC 5090. My reading of RFC 5090 was that is adds another authentication method to RADIUS. I guess I'm missing the part where it changes the basic RADIUS model. :-) > Section 1.2 provides an overview of RADIUS. However, I don't think it is > appropriate to use RFC 2119 language in that section. Hmmm. I fear getting the reverse comment if we de-capitalize the keywords. > You write: > >RADIUS almost always involves user authentication as >prerequisite to authorization, and there is a user authentication >phase for each of these two use cases. > > Since you mention authorize only later you could refer to this aspect as > well. > The usage of "Authorize Only" http://www.ietf.org/rfc/rfc3576.txt allows > you todo authorization without running the authentication exchange even > though you bind the authorization step to a previously done > authentication exchange. We may end up using a two-step process involving "Authorize Only" when we take up the VACM-related work. There is no reason to mention such a mechanism in the scope of this document, however. > The following RADIUS attributes SHOULD be used, as hint attributes >included in the Access-Request message to signal use of SNMP over a >secure transport (i.e. authPriv) to the RADIUS server: > > Why don't you use a MUST here? The reason is that "hint" attributes are traditionally optional. > In the previous section you describe how > important it is for the AAA server to figure this information out and > here you have a SHOULD and do not explain what happens otherwise if > this information is not sent. Another reviewer mentioned this same point. We could consider making this a MUST, without unduly impacting interoperability with existing RADIUS servers as servers are always free to ignore such hints. >The following RADIUS attributes are used in an Access-Accept message >to provision SNMP over a secure transport which provides both >integrity and confidentiality (i.e. authPriv): > > I suspect that this should read as > " >The following RADIUS attributes MUST be used in an Access-Accept >message to provision SNMP over a secure transport which provides >both integrity and confidentiality (i.e. SNMP authPriv): > " I'm not sure that a keyword is required here, but if one were to be required is would be MUST. > In Table 2 I was only expecting to see the newly introduced RADIUS > attributes rather than the attributes that come via the base RADIUS > RFC. I wouldn't do that. I'm following the precedent of RFC 3580 which defines RADIUS usage for Layer 2 access control (IEEE 801.1X). > You excluded accounting from the document and I was wondering whether > logging isn't a useful feature (or event required) to ensure > accountability when it comes to the management of network equipment. Well, there was no discussion in the ISMS WG that accounting was an operator requirement. I agree there is a case to be made for it, but in some sense the work of ISMS is in response to operator's perceptions of deploymen
RE: Current mailbombing is instigated by FSF
Alessandro Vesely writes... > Using the Internet is not mandatory: it's free. Well, that's just plain silly. Does your ISP not charge for access? Mine, Comcast, charges me over $50 US per month. The Internet should be available to all, but it cannot be truly free, as the fabric of the Internet cost real money. I think that free software is a wonderful thing. I also think that if *all* software were free, then only hobbyists would be writing software and we wouldn't have so much high quality free software available. In order to keep the software craft going, some of us have to be able to make a living plying that craft. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ANNOUNCEMENT: The IETF Trustees invite your comments onrevised proposed legend text to work-around the Pre-5378 Problem
John C, Klensin writes... > The point is that different countries have different rules, > different names for the rules, and different criteria. Right. I should have said "fair use" or whatever the corresponding legal doctrine is called in your jurisdiction. Is there a generic, jurisdiction-independent term for this doctrine? > * The current and former policies focus on getting people to > give the IETF (and IETF Trust) whatever rights they need, not on > making would-be users of text spend energy trying to figure out > what they can and cannot appropriate without those rights. Sure. > * This debate, and the workaround, are really about what rights > I have to claim that I have, or have obtained, to give to the > IETF. I'm trying to figure out what specific guidance, in the form of a step-by-step procedure, I can give to my WG so that draft authors can identify whether or not they need to include the workaround boilerplate. I don't want each of them to have to understand all the nuances of this debate, nor contact personal / corporate counsel in the process. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ANNOUNCEMENT: The IETF Trustees invite your comments onrevised proposed legend text to work-around the Pre-5378 Problem
John C. Klensin writes ... > And, while IANAL, my understanding from what we've been told > repeatedly is that "fair use exemption" is a US concept, so your > sentence should stop after "significant re-use of material" So authors of scholarly papers in other countries can't lawfully quote and cite other such works? I am continually surprised by new knowledge -- that makes life interesting -- but I find this bit particularly surprising, not to say incredible. If "fair use" does not apply, then does "significant" need to be come "any"? One of the elements of fair use is the volume of quoted material -- so what now defines "significant"? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ANNOUNCEMENT: The IETF Trustees invite your comments onrevised proposed legend text to work-around the Pre-5378 Problem
Paul Hoffman writes... > Is the Trust OK with this being in essentially every single IETF > document for many years to come? Unfortunately, it seems to me that's exactly the corner into which we are painting yourselves, for any document that involves significant re-use of material, i.e. beyond the "fair use" exception. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
