Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher
On Fri, 2013-08-16 at 13:16 -0700, Sandy Ginoza wrote: 2) In the following, we suggest that ASN.1 (and particularly MIBs and MIB-related details) be updated to reflect MIBs. Although MIB modules are written using a subset of ASN.1, the RPC does not check all ASN.1, we only check MIBs. This change will reflect what is done in practice. If the intent is to actually require the RPC to check all ASN.1, please let us know and we will discuss checking tools with the RSE and IAD. Current: 1.3. Validation of formal languages The RPC should validate the syntax of sections of documents containing formal languages. In particular ASN.1 (and particularly MIBs and MIB-related details), YANG, ABNF, and XML should be verified using one or more tools as approved by the RSE. I was a participant in and co-chair of a WG (Kerberos) which produced a lot of documents containing ASN.1 other than in MIBs. Before considering a document ready for publication, we generally required verification that its ASN.1 module compiles. Usually this was done by one or more implementors, who already had handy the tools and dependencies required to perform such a check. While I have no objection in principle to the RPC doing this check, it seems likely that the burden of doing so would be significant and, at least for IETF-stream documents, not worthwhile for the relatively small gains realized. This sort of check should be done before a document is ever submitted to the IESG, let alone the RPC. -- Jeff
Re: stability of iana.org URLs
On Thu, 2013-08-01 at 01:10 -0700, Amanda Baber wrote: Hi, The link in RFC3315 is actually incorrect -- it should have been http://www.iana.org/assignments/enterprise-numbers, without the file extension, and there's an erratum about this. HTML was generally (if not exclusively) reserved for files that needed to include links to registration forms . Nonetheless, it's an existing URL in an immutable published RFC. Once such a thing has been published, right or wrong, best practice is to make sure it remains valid.
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
On Wed, 2012-05-23 at 19:12 -0400, Samuel Weiler wrote: With that said, there are some things that need clarification, and the doc sorely needs an editorial pass. As-is, the doc is not ready for publication. I will be happy to review the doc again once it's been thoroughly edited. It does need copy-editing. As far as I know, the IETF does not have a team of volunteer copy-editors, and multiple attempts to get help from within the working group have met with only limited success (most notably in the form of help from Stephen, who did quite a bit of work on this before starting on his AD review). If anyone wants to volunteer to spend some time on helping to clean up this document, let me know. Otherwise, I think our only options are either to ask the paid editors at the RFC production center to take a stab, or block an otherwise completed document on cycles that may never appear. Section 7 uses the term TGT without expansion. In the Kerberos world I can't imagine someone not knowing what this is, but it's not clear to the layman. It probably needs to be expanded. It does; I somehow missed that in my review. The algorithm in section 4.1 needs work. The obvious thing is to read it linearly. Doing that, one would prefer DHCP over DNS SVR info (per step 2), which is not what step 6 and the graphic say. The algorithm is fine, but the description requires careful reading. Step 2 kicks in only if you get a DHCP response containing Kerberos configuration but no nameservers. Saying no answer from the DNS server is probably not the desired semantic. There are only two branches here. Either you get a response containing one or more relevant SRV RRs, or you don't. The latter is phrased as no answer from the DNS server, but is meant to also include errors and empty responses. A suggestion for how to word this better would be welcome. In 3.4, the option-len field is ambiguous. It says 24-octet + the length of the realm-name field in octets. But it looks to me like this option is 27 octets + length of realm name. Perhaps it would be better to just count the length of the realm name? Yes, the description is wrong; the correct length is _23_ plus the length of the realm. The 16-bit option code and length are part of the DHCPv6 protocol; unless I'm misremembering, the length is the length of the option payload (that is, excluding the two header fields). Thanks for taking the time to review this. -- Jeff
Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery
On Thu, 2012-02-23 at 17:00 -0500, Kim Kinnear wrote: This says MAY leave open. That's not the complement to SHOULD close. We don't really care if you keep it open or not. Really. If you think that you will be happier, keep it open. If you think it is simpler to close it (as I do), then close it. Different people (different authors even!) have different ideas about how they would structure the code for this. That's ok. The point about all of this open/closed/multiple-operations stuff it to leave it up to the implementor. Period. We are not trying to tell them exactly how to implement this. We are trying to focus on the protocol aspects, and leave understood. That's not what SHOULD means. An RFC2119 SHOULD is very strong; if the spec doesn't care what an implementation does, don't use SHOULD. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
On Thu, 2011-03-10 at 11:31 -0800, Paul Hoffman wrote: for changes that need to change the system's semantics, you change the certificates in a way that relying parties that don't understand the change won't accept the certificate. Sure. The way to do that is to issue a certificate with a critical extension. An RP encountering a certificate with a critical extension it doesn't understand will not accept the certificate. What the profile does as written is require RP's to treat all extensions as critical, even if they are not so marked. That reduces flexibility without gaining anything in return. In particular, we don't gain the ability to make a change that will prevent certificates from being accpted by RPs that don't understand them, because we already had that. Steve noted a desire to limit the liability of entities acting as CAs in the RPKI. I agree that goal is desirable, and restrictions on what certificates issued by those CAs can contain help to do that (provided the CAs actually comply). However, requiring compliant RPs to treat all extensions as critical does _not_ help, because an RP which incorrectly accepts an over-broad RPKI certificate for some other purpose is probably not an implementation of this profile and thus not bound by the restriction. --Jeff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-groves-eccsi-00.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an identity-based encryption algorithm, using elliptic-curve crypto, based in part on the design of ECDSA. In the system described, each participant has a well-known identifier and a public/private key pair generated by a central keying authority, which itself has a well-known public key. Each participant's public key is a function of that participant's identifer, the keying authority's well-known public key, and a long-term validation token which is initially provided the keying authority, and then transmitted by that participant along with each of its signatures. This system shares the usual security considerations of any public key cryptosystem, of ECC in general, and of ECDSA in particular; the security considerations section seems to do a reasonable job of calling these out. Recommendations are made for selecting an appropriate group size based on the desired symmetric-equivalent strength, but no information is given as to the derivation of this advice. I suggest a reference to RFC3766, or perhaps some more recent document which pays particular attention to ECC algorithms. Naturally, the security of the system depends on secure delivery of the agreed-upon group parameters, the keying authority's public key, and the generated keying material to each participant. This document calls out the need for suitable protection, but considers protocols or mechanisms for delivering this data to be out of scope. No explicit mechanism is provided for revocation or expiration of keys. However, identifiers are free-form, and could easily be extended to include timestamps, as discussed in the security considerations section. This is one of the most serious concerns I have with any identity-based crypto scheme, and I'm glad to see it called out and addressed. This document is unusual for the IETF, in that it defines a new cryptographic algorithm, which we normally don't do. While there is no particular reason not to publish it here, I would be wary of using this algorithm in any IETF protocol until it has seen extensive review by the cryptographic community. It looks to me like it should work, but I am not a cryptographer and may well have missed an obvious flaw. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09
--On Wednesday, September 22, 2010 12:34:50 PM -0400 Barry Leiba barryleiba.mailing.li...@gmail.com wrote: There's a distinction, here, between a protocol and a user interface for configuration. My mother doesn't know whom to trust, except that she knows that she (at least kinda-sorta) trusts the mail program she's decided to use, and an entity she calls gmail (not google.com, not gmail.com, but just gmail). She's relying to the mail program's easy configuration feature to sort this out. The text I reviewed appeared to be saying normative things about what client software MUST and MUST NOT do with regard to this sort of configuration situation, which goes well beyond what the client software is doing on the wire. Unless I'm mis-reading it, it's explicitly saying that my client software is not allowed to do something like this, for example: 1. Ask the user, What email service do you use? 2. Receive the answer gmail from the user. 3. Auto-configure itself for the known gmail servers based only on that user input. I think that's reasonable behavior _if_ the mail client knows that gmail is mail.google.com. What's _not_ reasonable is for it to arbitrarily transform gmail into a domain by adding .com, then look up gmail.com and see that it is an alias for mail.google.com and not only follow the (insecure) alias to mail.google.com but also use it to decide that mail.google.com is an appropriate name to find in a certificate. If your mother's mail client does that, then all I have to do to steal her password is convince said client that gmail.com is actually an alias for stealgmailpassword.attacker.org. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-lawrence-sipforum-user-agent-config-01
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a process by which a SIP User Agent can obtain configuration from a Configuration Service (CS) with a minimum of user interaction. This is particularly important since SIP UA's may be included in devices such as telephone adapters which are installed by end users and have little or no provision for user interface. The process described is relatively straightforward: - use LDDP-MED to get layer 2 up - use DHCP to get layer 3 up, and discover a local domain name - use U-NAPTR to turn the configuration service name (either the local domain name or a manually-entered name) into a set of one or more base configuration URL's - add some query parameters identifying the client, and use HTTPS GET Section 2.4.1 discusses authentication. The client is required to use the TLS server_name extension; however, the server name it is required to request is the name taken from the host part of the URL(s) obtained from U-NAPTR, rather than the Configuration Service Name (i.e. the local domain name or a manually-configured name). The latter should be used, so that the DNS-based indirection facilities are not required to be secure for the system to work. While DHCP is almost universally not secured, eliminating the need for pre-secured DNS still provides a substantial improvement. First, it is relatively easy for a deployment to require a user to enter a configuration service name rather than relying on one obtained from DNS. In fact, it may even be necessary to do so; for example, a telephone service provider offering SIP phone service to users via their existing home network cannot rely on being able to provide a particular domain name in the DHCP responses provided by an ISP or by the user's consumer-grade router/NAT box. Second, the resolution of the CS name to a base URL may require DNS queries to the internet at large, outside the user's network. Again, consider the case of a telephone service provider offering service via the user's existing network. This section says the UA SHOULD validate server certificates if possible, and otherwise MAY use SSH-style leap-of-faith. This seems reasonable for this application, where the use is provisioning a new device which, by definition, usually cannot have previously-provisioned trust anchors. Clients are REQUIRED to send a certificate if they have one, but are not required to have one. A CS SHOULD validate the client's certificate, and otherwise MAY do leap-of-faith caching, provided that HTTP authentication succeeds on this connection. However, it is unclear what, if anything, the client certificate identity is used for. If this identity is not used, then use of client certificates is pointless. Further, since HTTP authentication is not cryptographically bound to the TLS layer, successful HTTP auth does not demonstrate anything about the validity of the client certificate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [AFS3-std] Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard
--On Wednesday, February 03, 2010 03:27:01 PM -0800 Russ Allbery r...@stanford.edu wrote: SM s...@resistor.net writes: At 17:03 01-02-10, Russ Allbery wrote: Ah, thank you. Changed to SHOULD on the assumption that the (pre-2119) language in RFC 1034 was intended to have roughly the same meaning. SHOULD as a requirement first appeared in RFC 1122. It does not necessarily apply to RFCs published before RFC 2119. I guess I'm not clear on what you think the correct fix is. I'm hesitant to use a lowercase should in a document that explicitly references RFC 2119, since then it's ambiguous what that is supposed to mean in terms of a standard requirement. Agree. I think we want to elevate this to SHOULD in this case, even if the original 1034 requirement was not that strong. Clients failing to operate this way presents real operational problems for AFS cell administrators. I would suggest a slight rewording, so that the present text cannot be read to imply that 1034 says SHOULD in the 2119 sense, when in fact it is somewhat more ambiguous. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [AFS3-std] Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard
--On Thursday, February 04, 2010 01:59:36 PM -0500 Jeffrey Altman jalt...@secure-endpoints.com wrote: On 2/4/2010 12:02 PM, Jeffrey Hutzelman wrote: --On Wednesday, February 03, 2010 03:27:01 PM -0800 Russ Allbery r...@stanford.edu wrote: SM s...@resistor.net writes: At 17:03 01-02-10, Russ Allbery wrote: Ah, thank you. Changed to SHOULD on the assumption that the (pre-2119) language in RFC 1034 was intended to have roughly the same meaning. SHOULD as a requirement first appeared in RFC 1122. It does not necessarily apply to RFCs published before RFC 2119. I guess I'm not clear on what you think the correct fix is. I'm hesitant to use a lowercase should in a document that explicitly references RFC 2119, since then it's ambiguous what that is supposed to mean in terms of a standard requirement. Agree. I think we want to elevate this to SHOULD in this case, even if the original 1034 requirement was not that strong. Clients failing to operate this way presents real operational problems for AFS cell administrators. I would suggest a slight rewording, so that the present text cannot be read to imply that 1034 says SHOULD in the 2119 sense, when in fact it is somewhat more ambiguous. -- Jeff How about? AFS clients MAY remember which targets are inaccessible by that client and ignore those targets when determining which server to contact first. As is common practice, clients which do this SHOULD have a mechanism to retry targets which were previously inaccessible and reconsider them according to their priority and weight if they become accessible again. That's not the text we're talking about. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [AFS3-std] Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard
--On Thursday, February 04, 2010 02:20:27 PM -0500 Jeffrey Altman jalt...@secure-endpoints.com wrote: On 2/4/2010 2:05 PM, Jeffrey Hutzelman wrote: That's not the text we're talking about. Sure. Context was lost in the thread as the message-ids are not consistent. The text I think is being discussed is not actually in the draft, it is proposed text that Russ put forward on 1 Feb 2010. DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record information is no longer valid. As specified in [RFC1034], DNS RRs SHOULD be discarded after their TTL, and the DNS query repeated. This applies to DNS SRV RRs for AFS as to any other DNS RR. Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired. How about: DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record information is no longer valid. As implied by [RFC1034], DNS RRs SHOULD be expired after their TTL, and the DNS query repeated. This applies to DNS SRV RRs for AFS as well as any otherDNS RR. Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired. How about Consistent with [RFC1034]...? The problem I have with your text that it could be interpreted as merely descriptive of 1034, rather than as prescribing a requirement that applies to AFS SRV RR's regardless of how you choose to read 1034. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard
--On Friday, January 08, 2010 07:28:51 AM -0800 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS SRV Resource Records for AFS ' draft-allbery-afs-srv-records-03.txt as a Proposed Standard I support publication of this document. It meets a need which is currently not fulfilled in any other way, and IMHO is long overdue. I also believe there is consensus within the AFS community in support of this document. -- Jeffrey T. Hutzelman (N3NHS) jhu...@cmu.edu Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF
On Mon, 5 Oct 2009, Cullen Jennings wrote: On Oct 5, 2009, at 11:45 AM, Dave CROCKER wrote: At its base, your exercise seems to be an effort at doing the IAOC's job for it. It's their job to research venue details and make choices and to ensure the logistics for productive IETF meetings. The IETF as a body is not likely to become experts in the details of holding a meeting in China. Well it sounds like we both agree that it is the IAOC job to make sure they have answers to the questions I am raising before making a decision. I asked about legalities of discussing crypto a few years ago when this China meeting was raised to IESG. I did not get an answer. I asked about it around the time of the Stockholm meeting and got no answer. I am asking publicly on the IETF list when the topic finally got brought to a public list. I think it is a reasonable question. So do I. While it is certainly the IAOC's job to reserach possible venues and select a meeting location, many of us have jobs which require knowing the answers to some of the questions you've raised. For example... I co-chair a working group which is responsible for a cryptographic authentication protocol. If it is not legal to discuss and develop cryptographic algorithms and protocols in the PRC, or to export the results of such work, then my working group cannot usefully meet there, regardless of what the IAOC decides about the IETF as a whole being able to meet. I also normally organize PGP key-signing sessions at IETF meetings. If the operation of a CA or other cryptographic signing service requires a license in the PRC, then we may not be able to hold such a session, or it may require a special license. I consider it entirely appropriate for me in my role as a working group chair, or Cullen in his role as an AD, to ask that the IAOC obtain answers to these questions from competent experts, such as legal counsel familiar with PRC law. Finally, I would note that I am all for appointing people to positions of responsibility, putting appropriate checks and appeal and recall mechanisms in place, and them letting them go about doing their jobs. However, in this instance, the IAOC _asked_ for community input, so it seems silly to object to someone providing such input on the grounds that they are doing the IAOC's job for it. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [sasl] Last Call: draft-ietf-sasl-scram
--On Tuesday, September 15, 2009 12:16:44 PM -0400 John C Klensin john-i...@jck.com wrote: I really don't think (3) is a good idea, but an unqualified MUST ... UTF8, SHOULD SASLprep strikes me as a terrible idea simply because the same character, coded in different ways through no fault of the user, may not compare equal. The difference between (1) and (2) is less significant in practice because, while there are many important exceptions (with those East Asian width variants probably heading the list), the vast majority of compatibility characters are very hard to type in most environments. And that was really the point I was trying to make. There's another important point to make here... For something like a username, or passwords in PLAIN, the server has the original value, and can compensate for a client which under-normalizes. For such fields, an entirely appropriate policy would be MUST UTF-8; server SHOULD SASLprep, or at least NFC; clients... MAY SASLprep, or NFC, or nothing. But in SCRAM, passwords are not sent to the server. They are used to derive cryptographic keying material by way of a one-way hash function. This means that the client and the server (or, whatever handled the password setting function for the server) MUST use _the same_ normalization operation, or they will fail to interoperate. Further, the failure will be subtle -- some clients will fail to work with some servers, depending on what characters are in the user's password. Do we really want to create a situation where, to debug an interoperability problem, a system administrator must understand Unicode normalization _and_ ask the user to reveal his password? -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [sasl] Last Call: draft-ietf-sasl-scram
--On Tuesday, September 15, 2009 02:55:54 PM -0500 Nicolas Williams nicolas.willi...@sun.com wrote: I think the right answer is to leave _query_ strings unnormalized and require that _storage_ strings be normalized (see my separate reply on that general topic, with a different Subject:, just now). Or at least, leave query strings unnormalized until just before the query happens, and then normalize them in the same way as the storage string. More generally, what you want is normalization-insensitive comparison, and normalization of storage strings when they are stored is just an optimization for that. Except in cases like SCRAM, where strings are used to derive cryptographic keys or in other ways where it matters whether they're the same, but you don't get to compare them directly. Then you need to insure that the same input string is always transformed in the same way, or things break. Unfortunately, for SCRAM passwords, it's the client that has to do that transformation on every transaction, so we must insure that all clients do so in the same way. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [74attendees] [75attendees] IETF74 T-Shirt Art Donated to IETF Trust
--On Saturday, August 08, 2009 10:14:33 AM -0400 Phil Shafer p...@juniper.net wrote: Randy Bush writes: now we know where the ipr is. and we have lengthy discussion of who, how, why, and black helicopters. Can we GPL/CCL the artwork? Or would this mean that I have to give a t-shirt to anyone who asks where I got mine? ;^) You do, but you can charge a nominal fee for the media. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
--On Thursday, January 08, 2009 02:49:16 PM -0800 Fred Baker f...@cisco.com wrote: From my perspective, the best approach involves keeping the general case simple. The documents that have been transferred outside the IETF in the past five years is a single digit number, a tenth of a percent of all RFCs if not a smaller fraction. From my perspective, the simplest solution to the transfer issue is to ask the people relevant to a document for which transfer has been suggested whether they have an issue with transferring it, rather than asking every document author his or her opinion on the vast majority of documents, which will never be transferred. Remember that this boilerplate affects internet drafts, but most internet drafts are discussion documents - a fraction of internet drafts even become RFCs, and a small fraction of RFCs are transferred elsewhere. The difficulty with this approach is that it allows authors to decide whether to grant us the rights we require until the point at which we wish to exercise them, rather than requiring that they grant those rights before we take their contribution and turn it into a widely-deployed Internet standard. I don't believe we need to go back and ask every author of every published RFC and I-D to grant the additional rights, and I don't believe we need to have a system that blocks the submission and/or progress of current documents solely because they are built on earlier documents which were published before the new rules came into effect. However, I do think if we want the additional rights required by RFC5378, we need to require they be granted at the time that a document is submitted. It sounds to me like the trustees' proposal does a reasonable job of balancing the conflicting goals and achieving something useful. -- Jeff As to the other issues that 5378 addresses, I suspect that a better approach will be to fall back to 3978/4748/2026 temporarily and move to 5378-bis when it comes rather than to use this very general workaround to 5378's issues until 5378-bis is resolved. 3978 etc worked just fine for most purposes... If we reach consensus that the solution to the problem is to change 5378, rather than to semi-permanently adopt a workaround such as the trustees have proposed, then I would not object to falling back to the older rules until the issue is resolved. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 Trademarks (was where to send RFC 5378 license forms)
--On Tuesday, December 30, 2008 10:32:12 AM -0500 Contreras, Jorge jorge.contre...@wilmerhale.com wrote: For background, the trademark license was included in RFC 3978 because someone was concerned about Contributors who submitted documents to IETF for standards-track use and included trademarked product names in them. The IETF wanted to ensure that the IETF process would not be hindered by the Contributor, and also wanted to ensure that the trademarks were identified so that implementers would not be surprised by the trademark owner's claim after a standard was adopted. To be clear, this was not idle paranoia. Like many (not all) of the poor behaviors our processes attempt to protect against, this is something that working groups have actually seen happen. -- Jeffrey T. Hutzelman (N3NHS) jhu...@cmu.edu Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
--On Sunday, December 07, 2008 12:18:37 PM -0700 Cullen Jennings [EMAIL PROTECTED] wrote: I find the claim that attacks are easier to do with VoIP Configuration Server Address than the TFTP Server Name to be pretty dubious. Me too. That said, I think this security discussion is going the wrong direction. What is common practice, and what I think this should suggest, is that DHCP can be spoofed in some cases. The correct thing to do is to secure the object that is retrieved via tftp. I'm inclined to agree with this, in principle. In practice, that requires either preconfiguration, which sort of defeats the point of using DHCP, or a closed system like firmware updates signed by a device manufacturer, where not only the network but also the user and DHCP server operator are untrusted. If we're talking about an option which will only ever be used to tell phones where to download new firmware, then this is fine. If we're talking about an option which will be used by network operators to provide configuration to phones (in order to avoid manual configuration), or in general to provide a TFTP server address for whatever is the next step in the boot process, then secure the object sounds like good advice but IMHO is less practical than configure your network to prevent DHCP spoofing. There are ways to mitigate DHCP spoofing but discussion of those is outside scope of this draft. I agree that discussion of how to mitigate DHCP spoofing is out of scope. However, I think recommending that operators do so is appropriate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
--On Wednesday, November 26, 2008 02:58:25 AM -0500 Samuel Weiler [EMAIL PROTECTED] wrote: The security considerations section cites rogue DHCP servers as attack vectors, but doesn't do enough to encourage the use of DHCP Auth. In many deployments, DHCP is used by devices which have no prior configuration, or at least no prior association with the network operator. In such scenarios, DHCP auth is frequently impractical. Instead, network operators take other measures to insure that only replies from legitimate DHCP servers ever reach clients. For example, they may configure switches to monitor and filter DHCP traffic such that responses can only come from a small set of trusted ports. I'm somewhat surprised that the document does not mention this approach, as it is fairly common. I believe there may also be some confusion as to the meaning of option 66. This option has exactly the same semantics as the 'sname' field in the bootp packet, and is used in the event that field is overloaded to carry additional options. See RFC2132 sections 9.3, 9.4, 9.5, and the description of the option overload option starting at the bottom of page 23 of RFC2131. So, putting a name in option 66 has exactly the same effect as putting it in the 'sname' field, which is well-defined for BOOTP requests, but not so well defined for DHCP replies (in fact, so far as I've been able to tell, neither BOOTP nor DHCP has anything to say on the semantics of this field other than that it's a server host name, and calling option 66 TFTP server name is really misleading, because sname didn't actually mean that(*). In any case, the comment in the present document's security considerations that use of a name rather than an address is more secure is flawed in several ways. First, the DHCP server operator has no control over what options an attacker sends; if an attacker prefers to send and address, he can do so. Secondly, if a name is used, the attacker need only send a name in a zone which he controls; there is no need to subvert any part of the DNS. I share Sam's confusion as to why a code point is needed here at all. What purpose does this option serve that is not served by the siaddr field? -- Jeff (*) In fact, I've seen at least one widespread client implementation that assumed that sname was the name of the server identified in the siaddr field, and updated /etc/hosts so that sname would resolve to siaddr. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
--On Tuesday, December 02, 2008 03:53:58 PM -0500 John C Klensin [EMAIL PROTECTED] wrote: --On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms [EMAIL PROTECTED] wrote: Sam - I think most of the issues in your review of draft-raj-dhc-tftp-addr-option-04 can be resolved by reviewing the purposes of RFC 3942 and publishing Informational RFCs describing DHCP option codes. Fundamentally, the reason to publish RFCs under the process described in RFC 3942 is to document existing uses of option codes in the range of option codes reclaimed for assignment to new DHCP options. The concern is to avoid conflicts between new options and those grandfathered (hijacked) option codes. As such, these RFCs (usually Informational) simply document the already ... Responding to some of your specific points: At the very least, I suggest mandating the use of DHCP Auth and removing the suggestion to use option 66 to enhance security. And, in the absence of a more data about how widely used this option is, I suggest not publishing this document at all. The consensus of the dhc WG, to which I concur, is to publish the document as Informational. The text in the Security Considerations section about option 66 might be removed. ... To reiterate, it's not so much a question of whether a new code point is needed; rather, according to the procedures described in RFC 3942, this document gives a description of an existing use of option code 150. That option code is in use ... Ralph, It seems to me that there is a middle ground here. One can stick with Informational publication as the WG intends, but still modify the Security Considerations section, not only to remove the reference to option 66 (if there is consensus that is appropriate) but to add some explanation about why the use of this option without authentication might be problematic. Put differently, your objection to Sam's suggestion seems to hinge on just describe the existing practice, don't try to change it in this document. Given RFC 3492, that is entirely reasonable. But, if there are relatively obvious difficulties with that practice, it seems to me that documenting them would be helpful (indeed that not doing so borders on irresponsible). I'm inclined to agree with John here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
I support adoption of these proposed guidelines, but have a couple of minor comments... After an erratum is reported, a report will be sent to the authors and Area Directors (ADs) of the WG in which it originated. If the WG has closed or the document was not associated with a WG, then the report will be sent to the ADs for the Area most closely associated to the subject matter. If the document was produced by a WG that is not closed, the report should be copied to the WG chairs as well. 5. Ugly typos that are clearly bogus typos but would not cause any confusions to implementation or deployments should be Archived. The intent here is reasonable, but IMHO it's kind of poorly expressed. I'd suggest Clear typographical errors which would not cause -- Jeff ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
LC comments on draft-klensin-net-utf8-07.txt
The following sentence appears near the beginning of section 4: In retrospect, one of the advantages of ASCII [X3.4-1978] when it was chosen was that the code space was full when the Standard was first published. There was no practical way to add characters or change code point assignments without being obviously incompatible. I don't think I've seen this observation made in writing before, and it is interesting. However, I see a couple of problems. Particularly, the fact that there was no way to change code point assignments without being obviously incompatible did not in fact prevent such changes. While that change is little more than a footnote today (few people have documents lying around whose meaning depends on the left-arrow and up-arrow and are destroyed by using underscore and caret instead), a similar change today to either ASCII or Unicode could be disastrous, depending on the code points changed. Secondly, the reference tag [X3.4-1978] is wrong, as the target of the reference is actually X3.4-1968 (and in fact the references section uses the wrong tag, but the correct citation). -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] Review of draft-ietf-l2vpn-oam-req-frmk-09
--On Monday, December 17, 2007 05:00:46 PM +0100 Tobias Gondrom [EMAIL PROTECTED] wrote: DM Please note that the document explicitly states the requirements which are called out as Rxx. There requirements are meant to be coherent with RFC-2119 language and these are indeed covered as such. The text prior to the individual requirements is meant to provide context, justification as to why the requirement is needed. Therefore the authors feel that no changes are needed since the requirements' text is coherent with RFC-2119. Please let us know if this satisfies your comment. Hm, an interesting point of view on RFC-2119-usage. I can agree with your explanation as all important information is covered in RFC-2119 language and only redundant statements were made in non-RFC-2119. Personal note: my fear was that the fact of two equivalent statements in the text (one time in RFC-2119 (in the Rxx) and one not using RFC-2119 might lead to confusion in the interpretation. Especially as the explanaition you just gave in this email may not be obvious from the text of the draft. (e.g. I misread this as well.) However, this is only a minor disagreement and so does not absolutely need mitigation. While I think a better job could be done of pointing this out (for example, in the introduction, or even under Conventions Used in This Document), it seems clear enough that this document consists of both normative text (the numbered requirements) and non-normative text (the explanatory text associated with each requirement, as well as whole sections of explanatory text). In such situations, it seems appropriate for the normative text to use RFC2119 requirements language while the non-normative text, which by its nature does not contain requirements, to avoid RFC2119 language. Note that personally, my preference is for documents which refer to RFC2119 to use the words must, shall, should, may, required, and recommended _only_ when the RFC2119 sense is intended, and to use different wording in other situations to avoid confusion. However, not everyone shares this opinion, and in some cases alternate wording is awkward enough to be worse than the potential confusion. 5. Question: as the draft is heavily based on RFC4664 and 4665, I wonder whether they should not better be normative references instead of informative ones? DM The authors are open to moving the two references to normative section, however, the rationale had been that both 4664 and 4665 are informational therefore could well be in either of the two locations. Please let us know if you feel strongly about this editorial change in this document. I do not feel strongly about this. This was just a suggestion, which I would have also given as advice to authors in my own WG as well. Please bear in mind that the fact that a referenced document has status Informational (which has to do with its (lack of) standards status) does not mean that a reference to such a document is not normative. A normative reference is one which affects the meaning of the document, or at least of its normative parts, such that if the content of the normative reference changed, it would change the meaning of your specification. This determination is (or should be) an objective one, not a matter of opinion. For example, if the requirements you specify use terms that are described in a referenced document, that reference is normative. The same applies if you import whole requirements by reference. If you have a protocol specification which uses MD5 (don't do that) and refers to RFC1321 for its definition, then that reference is normative even though RFC1321 is an informational document. On the other hand, if you refer to a document in a way that does not affect your specification (for example, see RFC4459 for an explanation of why implementations of this protocol MUST NOT send larger-than-MTU packets), then the reference is non-normative. In the present case, I haven't examined the reference in question and am not making an argument for either answer. I _am_ making an argument for the authors and/or chairs to examine the way in which the reference is used and place it into the appropriate section. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-v6ops-scanning-implications-03
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document discusses implications of IPv6's larger address space and larger typical subnet size for traditional network address range scanning techniques often used to identify nodes. It discusses other methods which may be used by attackers to discover IPv6 notes, approaches that can be used by network administrators to counter them, and techniques by which adminstrators can take advantage of IPv6's large address apace to make it harder to identify potential targets for attack. This document provides a lot of good advice on how to make node addresses on an IPv6 network difficult to discover. That is, it discusses ways to obscure addresses. According to traditional wisdom, security through obscurity is worse than no security at all. Put another way, obscuring addresses can be a useful tool in building a defense-in-depth, but relying solely on obscurity of node addresses is asking for trouble. I would like this point stressed in the security considerations for this document, possibly including references to other sources on techniques that can be used to secure hosts, communication between hosts, and/or network access. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Monday, October 01, 2007 10:34:37 AM -0600 Danny McPherson [EMAIL PROTECTED] wrote: Note that in real deployments just this behavior has broken things on occasion, as many firewall and other such policy application points assume things like DNS resolution will only be UDP/53 transactions. Yeah; I'm getting a little tired of having our protocols redefined based on the incorrect assumptions of people who don't understand them. The DNS sometimes uses TCP, UDP flows can last more than one round trip, and ICMP unreachable messages are an essential part of IP; vendors and operators who assume otherwise should be made to fix their assumptions, instead of everyone else having to cripple their applications and networks to make the assumptions true. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews [EMAIL PROTECTED] wrote: The Introduction seems a bit defensive in stating that the DOS attacks are not due to any flaw in the design of DNS or its implementations. While the blame for the attacks lies with the attackers, some aspects of nameserver configuration, behavior, and even protocol design make the systems vulnerable to these attacks. I suggest that the defensive language be removed. No, the blame lies with the parties not implementing BCP 38. A rogue end site should not be able to inject spoofed packets. No; the blame for an attack _always_ lies with the attacker, not the victim. While I certainly wish more network providers would implement BCP 38, those who fail to do so are not to blame for the bad acts of others. FWIW, I believe the defensive language in question is neither necessary nor particularly problematic, so I take no position on whether it should be removed. Finally, I wonder whether other more fundamental techniques for addressing the problem have been explored. For instance, if DNS clients were required to perform a simple handshake before a DNS server sent a long response, fake requests would provide little amplification. For example, requests that elicit long responses could prompt a shift to TCP. The DNS already does this. The DNS is optimised so that the normal responses go via UDP and the exceptional responses via TCP. It does, but normally only responses which are too long for UDP require the use of TCP. A recursive nameserver could mitigate this type of attack by lowering the maximum response size it is willing to send via UDP, forcing the use of TCP and thus a three-way handshake for larger responses. The tricky part is that setting the threshold too low can have serious performance impact. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
On Saturday, September 08, 2007 01:53:36 PM -0700 Eric Rescorla [EMAIL PROTECTED] wrote: Alexey wrote: This message is trying to summarize recent discussions on draft-hartman-webauth-phishing-05.txt. Several people voiced their support for the document (on IETF mailing list and in various other off-list discussions). Ekr doesn't think that the document should be published in the current form and he has some good technical points that need to be addressed. At least one more revision is needed to addressed recent comments from Ekr and SecDir review. It is quite clear that some people got confused about intended status of this document and whether it represents IETF consensus. Sam has clarified what was his intention, but another consensus call is needed to make sure people agree with Sam. Subsequent discussions and consensus calls on the document would happen on [EMAIL PROTECTED]. Alexey, in my capacity of shepherd for draft-hartman-webauth-phishing I object to this procedure. shep This document has already had an IETF Last Call, where it failed to achieve consensus. At this point, it doesn't need additional last calls to make sure that people agree with Sam, but rather to go back to the authors to try to build support in the community. Not liking the result of the previous Last Call is not a sufficient basis for issuing another one. At some point in the future, it may be appropriate to issue another consensus call, but since this is not a WG mailing list--indeed, the IESG has twice declined to charter a WG in this area--nor are you the chair, it doesn't seem to me that you have standing to do that. When that time comes, I would expect the IESG to designate an appropriate time and place. I think you're overreacting, possibly due to a misinterpretation of what Alexey said and/or of the current state of the document. My reading of the IESG evaluation record suggests that there are indeed some issues that the community feels need to be addressed before the document can move forward. Its current state is IESG Evaluation::Revised ID Needed, which, along with the evaluation record, suggests that the responsible AD has asked the author and shepherd to get these issues resolved and submit a new document. I don't know what will happen once this is done, but unless the IESG feels we already have _rough_ consensus to publish the document _and_ there are no major changes, I would expect to see a new last call on the revised document. Of course, that last call may see renewed objections from the same individuals, or from others; that does not necessarily mean the last call failed -- remember, we operate on _rough_ consensus. Now, given that the responsible AD has asked for a new document, it seems to me that Alexey, as the shepherd of an individual submission, has quite a bit of latitude in how to get there and what it will take before he is willing to take the document back to the IESG. Given that this document is a group effort, it's entirely reasonable for Alexey to want to know that people contributing to the work agree with any changes Sam makes, and to issue consensus cals in an appropriate forum to do this. No one is laboring under the impression that such a call would serve to override the failed IETF LC. Instead, when Alexey in his role as shepherd believes the document is ready to go back to the IESG, he will inform Lisa of that fact, and the IESG will decide what to do next. -- Jeff -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On Saturday, June 30, 2007 10:56:59 PM -0400 Fred Baker [EMAIL PROTECTED] wrote: On Jun 30, 2007, at 9:49 PM, Bob Hinden wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings good luck. Until the ISPs and our corporate networks deploy it, we can't go there. ... and this point may be lost on some people, but most IETF participants do not operate their ISP's or corporate networks, and have no ability to change them. Most of us come to IETF meetings to get work done, not to spend the week fighting to get connectivity to home because someone wants to use the IETF network to encourage someone to deploy IPv6 or any other new technology. Every time I come to an IETF meeting, I lose a week or more of time on my regular job. What makes that acceptable is that I can get significant amounts of IETF work done in that week. Take that away, and IETf meeting attendance suddenly becomes counter-productive for individuals, and then for the organization as a whole. The IETF network is not, and never has been, for experimentation, showing off new technology, or making political statements. Please keep it that way. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
On Monday, July 02, 2007 07:01:28 AM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: And from a security point I want to see as much NAT as possible. Whereas I want my applications to work, and people to stop conflating NAT and firewalls. You don't want to see as much NAT as possible; you want to see as much blocking of inbound connections to consumers as possible, and for some reason you seem to think that a firewall which does that must necessarily also be a NAT. In fact, it does not; it's perfectly reasonable to build a box that can be sold for $50 which sits between a subscriber's computer and the Internet and provides a basic firewall. Such a thing could be combined in the same box as an ethernet switch, wireless AP, maybe a basic router, DNS cache, and so on. In fact, plenty of such boxes are sold today, except they all come with NAT turned on by default. That is _not_ because NAT makes the network more secure - it doesn't. It's because most of the people buying those boxes need NAT because their ISP's won't give them more than one address, or at least won't do so for a reasonable price. Fix _that_ problem, and you'll start seeing boxes that provide security and flexibility without needing NAT. Frankly, Phill, I'm surprised and disappointed that you are not only making such a basic mistake, but spreading FUD about it. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On the IETF Consensus process
On Wednesday, May 23, 2007 06:56:10 PM -0700 Lakshminath Dondeti [EMAIL PROTECTED] wrote: Hi Jeff, On a first scan of your email I thought to myself, I agree with most of it and so pondered about the problem that I was trying to put forth in front of the community. The conclusion was that indeed if everyone follows the rules and if the checks and balances work as they are supposed to, perhaps there are no problems. Unfortunately though, our system of checks and balances is that people need to object, as you put it; often people at the losing end of an argument may object and thus may be dismissed. This is a difficult problem. I'm sure there are many cases where people should speak up and don't. There are also a number of cases where someone who has legitimately lost refuses to accept that. Unfortunately, the latter are usually much more easily observed. If we could find a way to drastically cut down on either category without growing the other, we'd be able to make substantial improvements, both to the IETF and, if the solution scales, to society as a whole. Unfortunately, it's a hard problem. Consider what happens if a WG chair or an AD's decisions are skewed, either intentionally or because they are naturally biased towards a particular philosophy? Often people tend to try and live with it or adjust to it. There is not really a viable avenue to provide feedback about the AD. Appealing (happens rarely) or recalling (never happened?) are drastic measures. Yes, they are, and no, the recall procedure has never been used. I'm sort of torn on this - most every decision is appealable, and if an AD is making bad decisions and won't listen to reason, they should be appealed. However, if everyone appealed every decision they didn't like, we'd never get anything done. Next, I agree that all the decisions are public, but I will note that not many people have the bandwidth to know what all is going on (there are ADs who don't monitor WG mailing lists on a regular basis). There is also the tendency to be silent hoping that other people will raise the issue. True. For instance, I had started thinking more clearly about BoF processes and how a small set of people can derail a BoF process after I started this thread. A few vocal people at the mic and secret reports from IAB members (conflicts of interest seem to go unnoticed) can undo months worth of work and the proponents have to wait 4 more months to do anything. There is no reason it needs to be that way. Sorry; I really want to answer this part, but I'm out of time for now. Perhaps I'll come back to it next week. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On the IETF Consensus process
On Wednesday, May 23, 2007 12:40:43 PM -0700 Lakshminath Dondeti [EMAIL PROTECTED] wrote: Brian, Scott, Many thanks for your responses, but here are some followup notes. The problem I see is that WG chairs and ADs have a lot of latitude in running WGs or areas. This is not a problem; it's a feature. The possibility for abuse is tremendous Not really. The decisions that chairs and AD's make are all public, and nearly all of the input to those decisions is also public. There is plenty of opportunity to review what they are doing and speak up if you see something problematic. There is also generally lots of opportunity to resolve issues informally before the formal appeals process becomes necessary. they get to read consensus however they like Well, no. The job of a chair or WG is to judge for what there is or is not a (rough) consensus. There are a lot of tools available for use in making those judgements, but ultimately the nature of a consensus is that if you claim there is one and it isn't so, then people will object. and may advance or block a particular document or work item based on personal preferences. Certainly not. Chairs or AD's may _express_ preferences like any other participant, but are expected to judge consensus on the basis of consensus, and not personal preference. As I mentioned above, when this doesn't happen, people object. Note, however, that both chairs and AD's are also expected to exercise technical judgement. If a WG tries to advance a document that is clearly underspecified, or fails to meet basic requirements that the IETF has established, or that is otherwise not ready, then it is his job _not_ to forward that document until it is ready -- otherwise, he is wasting the time of the IESG and of the IETF as a whole. Of course, it is possible to have a situation in which a technical decision must be made and the chair is in the rough; in such a sitution the chair is expected to forward the document anyway, possible with comments if he feels strongly that the decision in question is a mistake. The inconsistent behavior goes either unquestioned or explained away as being within the rules. The recourse is the appeals process which to most people looks like a hammer and thus seldom used. Well, quite a lot of inconsistent behavior _is_ perfectly legitimate. Different people have different management styles, and different groups operate in different ways. Nothing says everything has to work exactly the same every time -- this is an organization of people, not computers. Our process gives chairs and AD's a lot of latitude, because it must in order for the organization to function. However, it also includes a lot of checks against abuse, both intentional and otherwise. The appeals process is actually used fairly regularly, and it should be noted that the only appeals that come to the attention of this list are generally those that reach the level of appeals to the IESG as a whole. Things that get resolved at the WG chair or AD level are likely to completely escape your notice if you're not involved. As, of course, are issues that are resolved informally. Nothing wrong with it, unless of course, the WG gets used to that mode of operation and demands that everything be decided based on WG consensus (which on spurious issues could mean that a vocal minority gets to decide how things work). A vocal minority only gets to decide if the majority consents, or the chair is asleep at the switch. Being loud does not make one part of a consensus. Reopening the discussion when there is substantial new information is one thing, but revisiting past decisions every time someone has some free time leads to endless delays. All I am saying is that we need to have some determinism in the process. A good chair will prevent that from happening. And while a certain amount of determinism is useful, a completely deterministic process is neither required nor necessarily good. Our process involves groups of humans attempting to reach agreement; often this requires mediation by a human exercising good judgement in order to be successful. But they must always add to be confirmed on the list and must always do so - if they don't, it's a clear process violation and can be appealed. This is one of the things I am trying to get a clear sense of. How is this supposed to work in case of BoFs? BOF's are not working groups, and in most cases, they don't get to make consensus decisions. In particular, they do _not_ get to decide whether a working group will be formed or what its charter will say (though this seems to be a common misconception). Those decisions rest with the sponsoring AD(s) and the IESG; the purpose of a BOF is to guage interest and provide a forum for community input. -- Jeff ___ Ietf mailing list Ietf@ietf.org
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On Sunday, May 20, 2007 01:41:29 PM -0700 Eric Rescorla [EMAIL PROTECTED] wrote: I agree that these specs should explicitly specify which TLS version to support. As a practical matter, this is either 1.0 or 1.1, since 1.2 is not yet finished. Unfortunately, which one to require isn't really something that can be decided on technical grounds: the protocols are very slightly different and (at least in theory) backward compatible. TLS 1.1 is slightly more secure and TLS 1.0 is quite a bit more widely deployed. On balance, I think this probably turns into a MUST for 1.0 and a SHOULD for 1.1, but I could certainly see this argued another way. It seems to me that specs should _not_ explicitly specify which TLS version to support, and should instead refer to an STD number. Applications don't generally specify which verisons of IP or TCP to use, and TLS is at a similar level of abstraction -- except that the situation is not as painful, because using a different version of IP means you have to use completely different names, whereas using a different version of TLS does not. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wednesday, April 11, 2007 11:16:30 AM +0200 Simon Josefsson [EMAIL PROTECTED] wrote: The assumption is false: the goal of free software is not to make the Internet work better. The assumption is not false. The goal of the IETF is to make the Internet work better. I assume Brian chose those words with care; they are taken directly from the IETF's mission statement, RFC3935. The IETF has the goal of making the Internet work better. Thus, the IETF has to accept the license reality, both proprietary and free software, and do whatever leads to a better Internet. That does not always mean discarding technologies because the people who developed them want to protect their legal right to benefit from their invention, or to protect themselves from liability. The reality is that the law is not going away, patents are not going away, and both the IETF and the free software community (to the extent that such a thing exists) need to learn to deal with that. Disclaimer: I am not a lawyer; this message is not legal advice. For the record, I think your concerns about this particular license are overstated. Neither this patent license nor the open-source software licenses you quote are as buggy as you seem to think they are. For example, the patent license contains the following text, which you quoted: This general use license granted to manufacturers also flows down to sublicensees and users. This would appear to have the effect that only the original implementor of the patented technology would need to obtain a license from RedPhone; he would then simply include in the software license a recursive sublicense for the patent. The field-of-use restriction is annoying, of course, but I don't think it's actually fatal in this case. The GPL does indeed prohibit you; that is, the GPL licensee, from imposing futher restrictions on recipients exercise of rights granted within the GPL. However, it does not prevent such restrictions from already existing; the GPL does not prevent you from adding support to GPL'd software for patented crypto technology and then distributing the result, provided the patent license does not require you do place additional restrictions on the activities of people you distribute to. In fact, the most common problem I've heard of with GPL incompatibility as it relates to patents is that the GPL prevents adding a restriction that requires preparers of derivative works to license any relevant IPR that they own. The text you referenced in the Mozilla and Apache licenses are examples of such requirements, and make those licenses GPL-incompatible. The Mozilla license covers this explicitly, again in the text you quote: The Initial Developer hereby grants... subject to third party intellectual property claims. Of course, that's not really the important part, since most people are not the Initial Developer. What you really want is section 2.2, Subject to third party intellectual property claims, each Contributor hereby grants In either case, what is going on here is that anyone who contributes code to software covered by that license must grant licenses to any relevant IPR that he owns; it explicitly excludes IPR owned by someone else. Thus, it is possible to include patented crypto in software covered by the Mozilla license, even if the patent holder requires every user to pay a large fee to use the patented technology. The section you refer to from the Apache license is similar - it consists of a license grant by each contributor of rights held _by that contributor_. The grant does not cover IPR not held by the distributor. In any case, the text you quote from the Mozilla and Apache licenses has nothing to do with the argument you are trying to make; it has no effect on the ability to create and distribute software under these licenses which implements technology patented by someone other than the contributor. What makes these clauses problematic is that they cause the licenses that contain them to be GPL-incompatible (but not necessarily non-free). -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wednesday, April 11, 2007 11:34:42 AM -0400 Jeffrey Hutzelman [EMAIL PROTECTED] wrote: For the record, I think your concerns about this particular license are overstated. Neither this patent license nor the open-source software licenses you quote are as buggy as you seem to think they are. For example, the patent license contains the following text, which you quoted: This general use license granted to manufacturers also flows down to sublicensees and users. This would appear to have the effect that only the original implementor of the patented technology would need to obtain a license from RedPhone; he would then simply include in the software license a recursive sublicense for the patent. Hm. Unfortunately, it seems there is other text that is problematic... This... The Protected Assurance System Functions listed below (the PAS Functions) define a set of functionality that Manufacturers under this General Use License (e.g. manufacturers of receiver / server components) must ensure is NOT implemented or provided to its users. ... would indeed appear to require anyone distributing an implementation to impose additional restrictions, which is a problem. Also, this is very bad: In the event that a Manufacturer has (a) only been granted a General Use License and (b) implemented and released to end users any PAS Functions, such events shall cause the General Use License of that Manufacturer to be immediately revoked, and any license rights conferred to any users of the system that has implemented any PAS Functions (above) shall be likewise revoked. This appears to say that if someone violates the license terms, then anyone who received a sublicense from them, directly or indirectly, is also screwed, even if the user has not violated the terms of the license. This is extremely unfriendly, not just to open source but to users in general. Finally, schedule B requires that specific text be unambiguously displayed at time of system installation. This requirement is impractical and in any case impossible for open-source implementors to enforce. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-williams-on-channel-binding (On the Use ofChannel Bindings to Secure Channels) to Proposed Standard
On Wednesday, April 11, 2007 12:09:24 PM -0700 Randy Presuhn [EMAIL PROTECTED] wrote: Hi - From: Tom.Petch [EMAIL PROTECTED] To: ietf ietf@ietf.org Sent: Wednesday, April 11, 2007 10:43 AM Subject: Re: Last Call: draft-williams-on-channel-binding (On the Use ofChannel Bindings to Secure Channels) to Proposed Standard ... Otherwise those who would benefit from it - isms, netconf, syslog, ... ? - will not understand what they might do. I appreciate that something of this ilk has been around for a while (eg as when Ira McDonald pointed the isms list at draft-puthenkulam-eap-binding-04.txt) but I think that it got no traction because of its impenetrability. ... In the isms WG, we were told that we could not use EAP. http://www1.ietf.org/mail-archive/web/isms/current/msg00464.html That's right; isms is outside of EAP's field of applicability. But draft-williams-on-channel-bindings is not specifically about EAP, but rather about a general class of problems that arises when protected communications channels are established independently of authentication, and an approach and method for solving those problems, particularly within the context of various authentication frameworks. As it turns out, ISMS doesn't need to work about this class of problems because the approach we chose uses SSH, which provides both authentication and a protected channel in an integrated manner. Now, if SSH for some reason wanted to make use of a protected channel provided by TLS or, more likely, IPsec, then it would need to worry about this class of problems, and the solutions might well involve exposing new interfaces to ISMS and other applications built on SSH. But for the moment, that's not really an issue. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Friday, March 30, 2007 10:12:14 AM -0700 Paul Hoffman [EMAIL PROTECTED] wrote: At 11:50 AM -0500 3/29/07, Mark Brown wrote: I have experienced some surprises when mixing law and Internet standards. To try to avoid surprises, I have hired IPR attorneys at two different firms to review my draft which proposes a royalty-free license grant. I expect any resulting license will be conditioned upon IETF acceptance of TLS authz as a standard. I hope to have concluded these services next week. You may feel that this is an offer, but it is in fact a form of bargaining. If you put this on standards track, then we will (or might) give a royalty-free license. That is a poor bargain for the IETF, and the IETF should not consider the offer when it decides whether or not to make the protocol a standard. I think there is a significant exception which may apply in this case. If the IPR issues are the sole remaining factor in the IETF's decision as to whether to make a protocol a standard, then I think it is entirely reasonable for the IETF to consider an offer which would eliminate or at least mitigate those issues if the protocol were to become a standard. I see nothing wrong with saying I'm willing to grant a reasonable license if my technology becomes a standard, but reserve the right to make money otherwise, as long as the IETF does not allow such an offer to result in adoption as a standard of something it would not have standardized otherwise. As for informational vs an independent submission, I think there is a factor to be considered. It seems to me that an informational IETF document is a fine way to say this is a good idea, and we think this is the right way to do FOO, but we can't actually recommend it (for whatever reason). For example, we have at least one document that defines the use of elliptic curve cryptography with one of our protocols, which is informational because the working group that produced it didn't feel they could recommend it as a standard due to the hairy IPR issues surrounding that technology. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Identifying meeting attendees
On Friday, March 30, 2007 02:59:51 PM -0400 Marshall Eubanks [EMAIL PROTECTED] wrote: Only if there are multiple, independent, interoperable implementations. On the contrary, this is one case where we must be careful _not_ to allow interoperability. If the robots could interoperate, they might take over the world. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Remote participation (re: identifying yourself at the mic)
On Tuesday, March 27, 2007 02:39:49 PM -0500 Nicolas Williams [EMAIL PROTECTED] wrote: It'd be nice if there was a way for remote participants who are able to speak to do so. We tried ad-hoc VOIP + MP3 feed at IETF67 in the KITTEN WG, but the round-trip latency was awful -- we need a better solution. It's worth noting that in that particular experiment, the round trip time was dominated by the latency of the multicast audio feed which we were using for one half of the link. If we were to try this again, we'd use the VOIP link for both directions to the remote speaker, to avoid annoying latency issues. Given such a facility we'll end up with a mutual need by participants in the room and remote participants to identify each other, which will nicely solve the problem :) -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Remote participation (re: identifying yourself at the mic)
On Tuesday, March 27, 2007 01:10:25 PM -0700 Joel Jaeggli [EMAIL PROTECTED] wrote: Nicolas Williams wrote: It'd be nice if there was a way for remote participants who are able to speak to do so. We tried ad-hoc VOIP + MP3 feed at IETF67 in the KITTEN WG, but the round-trip latency was awful -- we need a better solution. Given such a facility we'll end up with a mutual need by participants in the room and remote participants to identify each other, which will nicely solve the problem :) echo cancellation in a room full of live microphones is problematic. there's hardware that can help, but what you really need is floor control in the form of person who controls who can speak via mixing. I've seen that to be the case even with only the local microphones. Several groups I participate in regularly have taken to having each speaker turn the mic on when they speak and off when they are done, which unfortunately adds a bit of latency with wireless mics that require a couple of seconds to warm up. I've also had at least one occasion where I was using the mute buttons on the mixing board for floor control, but that's fairly primitive and it's nearly impossible to run a meeting and mix it at the same time. Maybe we need another team of volunteers to mix the meetings(*), instead of assuming that static settings will be good enough. This could have the added benefit of relieving the chair of the burden of telling people over and over to speak their names (*) At most half-serious, though if someone showed up to run the mixer in my next meeting, I wouldn't complain. :-) -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Remote participation (re: identifying yourself at the mic)
On Tuesday, March 27, 2007 03:46:27 PM -0500 Nicolas Williams [EMAIL PROTECTED] wrote: On Tue, Mar 27, 2007 at 04:42:33PM -0400, Jeffrey Hutzelman wrote: On Tuesday, March 27, 2007 02:39:49 PM -0500 Nicolas Williams [EMAIL PROTECTED] wrote: It'd be nice if there was a way for remote participants who are able to speak to do so. We tried ad-hoc VOIP + MP3 feed at IETF67 in the KITTEN WG, but the round-trip latency was awful -- we need a better solution. It's worth noting that in that particular experiment, the round trip time was dominated by the latency of the multicast audio feed which we were using for one half of the link. If we were to try this again, we'd use the VOIP link for both directions to the remote speaker, to avoid annoying latency issues. Which should deal with the echo cancellation issues, provided a conference bridge, say. That should work for remote presenters. For other remote participants a VOIP teleconference system would be great. We do this all the time at Sun internally for large meetings, so it should work. (The IETF might have to charge remote participants a conference call fee, if it uses a third party provider, say.) Perhaps Sun would like to volunteer its system for an experiment? -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Remote participation (re: identifying yourself at the mic)
On Tuesday, March 27, 2007 03:59:45 PM -0500 Nicolas Williams [EMAIL PROTECTED] wrote: On Tue, Mar 27, 2007 at 04:51:05PM -0400, Jeffrey Hutzelman wrote: Perhaps Sun would like to volunteer its system for an experiment? It isn't ours. As best I can tell we use some high-end conference bridging + ATT concall services along with traditional room PA systems. Oh; I thought we were talking about a VOIP-based service, rather than a traditional conference-bridge service. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFID (was: identifying yourself at the mic)
On Tuesday, March 27, 2007 02:42:19 PM -0700 Andy Bierman [EMAIL PROTECTED] wrote: There are so many Process Wonks in the IETF who feel it is their sworn duty to yell State your name please! I think it's unfair to call people who do that process wonks or any other derogatory term. Most of them are people who want to know who is speaking. Some of them are people who assume the rest of the room want to know who is speaking, probably don't, and probably don't feel comfortable speaking up and saying so. that said... I don't think we need to introduce expensive technology into the mix. I very much agree with this. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFID
On Tuesday, March 27, 2007 03:51:56 PM -0700 Andy Bierman [EMAIL PROTECTED] wrote: http://en.wikipedia.org/wiki/Wonk_%28slang%29 According to wikipedia, a policy wonk is someone knowledgeable about and fascinated by details of government policy and programs If that is derogatory then I'm sorry. It carries a derogatory connotation. IMO it is accurate to say there are many people in the IETF that fit this description. And I don't dispute that. I just don't think it's appropriate to apply that description to people who say XXX, tell us your name! the third time someone gets up to the mic without saying their name. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: identifying yourself at the mic
On Monday, March 19, 2007 11:56:07 AM -0400 Steve Silverman [EMAIL PROTECTED] wrote: It would be simpler, cheaper, and more reliable to have one guy with a whistle in each meeting who could blow the whistle and ask for the speaker's name when appropriate. That guy is called the chair. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: NATs as firewalls
On Wednesday, March 07, 2007 04:23:20 PM -0800 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: We do need to revise the architecture description. Using IP addresses as implicit signalling You keep using that word. I do not think it means what you think it means. Another instance that hit me today is the fact that existing SSL implementations use the server IPv4 address to select which server certificate to present to a client. No; existing SSL server implementations assume that only one certificate is relevant for any given transport endpoint. Which, for the vast majority of uses, would not be that big a deal except that a certain vendor which dominates the well-known-CA market(*) sees a revenue opportunity in wildcard certificates, much as ISP's see a revenue opportunity in residential customers who need multiple non-NAT'd addresses. (*) To be fair, pretty much _every_ vendor does this. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
On Wednesday, February 28, 2007 03:56:44 PM -0500 Eric Rosen [EMAIL PROTECTED] wrote: In many cases (probably the vast majority) where a document is advancing despite a downward normative reference, the referenced document (and the technology described therein) is no less stable than the referencing document, and no caution is required. It's great to be able to make a downward reference and move on, but we should not be required to tell lies and spread FUD. Inflammatory language aside, I agree. Another alternative, probably a better one, is simply to annotate each reference with its standards status, and make no editorial comment about it at all. This sounds like a fine approach to me, for cases where in fact no special caution is required. For the remaining cases, someone can always object to approving the document on the basis of an unstable downref and/or ask that a warning be inserted. On the other hand, I don't think any change to the document is needed to achieve this. The next two paragraphs after the one you quote say: The IESG may, at its discretion, specify the exact text to be used, establish procedures regarding the text to use, or give guidance on this text. When establishing procedures the IESG should seek appropriate community review. These annotations are part of the source document. If members of the community consider either the downward reference or the annotation text to be inappropriate, those issues can be raised at any time in the document life cycle, just as with any other text in the document. There is no separate review on these references. Also, while I don't think the document necessarily needs to be changed to REQUIRE this, I think it would be good if last call announcements continued to call out normative downrefs, for two reasons: (1) To make it easier to catch potentially problematic downrefs (2) To encourage the advancement of frequently-referenced documents along the standards track. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About Gen-ART reviews
On Tuesday, February 13, 2007 08:33:44 PM + Adrian Farrel [EMAIL PROTECTED] wrote: The main IETF mailing list is a compromise, but not particularly good as it may obscure the other traffic on the list. Oh, yes; it would be a shame if discussion of documents in IETF Last Call caused someone to miss the latest flamefest. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP [WAS: Gen-art review of draft-heard-rfc4181-update-00.txt]
On Monday, February 12, 2007 10:26:13 AM -0800 C. M. Heard [EMAIL PROTECTED] wrote: The title of the draft could be more explicit. Now it mentions RFC 4181. It could also indicate that it is an update to the Guidelines for Authors and Reviewers of MIB Documents. I disagree with this comment -- I believe that doing as it suggests would make the title unnecessarily long. Note that the Abstract already spells out the full title of RFC 4181. A document title should be meaningful enough that by reading a citation or an rfc-index entry, you can tell what the document is about, at least at a high level. Normally, I'd say that means _not_ naming an updated document only by its RFC number, since that effectively forms a citation within a citation that can be more work to track down than it should be. In this case, I think the essential part is there -- it's an update to recognize the IETF Trust. The last document of this type that I reviewed was RFC4748, and its title is constructed in exactly the same way. I didn't have a problem with it then, and I don't now, either. Acronyms (e.g., MIB) should be expanded on their first use. I have to agree fully with Mike here - MIB is a well-known acronym; in fact, I'd argue that it's so well-known that more people know what it means than know what it stands for. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
On Wednesday, February 07, 2007 10:20:54 AM -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC This document looks good to me. However, I am compelled to ask why it should be published as an Informational RFC instead of as an ION. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-hip-mm-04.txt
On Tuesday, January 30, 2007 08:26:01 PM +0100 Christian Vogt
[EMAIL PROTECTED] wrote:
This should probably be rephrased to:
This UPDATE packet is acknowledged by the peer. For reliability in
the presence of packet loss, the UPDATE packet is retransmitted in
case
no acknowledgment is received within the period of a retransmission
timeout.
Ah, OK. Yes, that makes sense.
=
Section 3.3.2: Credit-Based Authorization
2. An attacker can always cause unamplified flooding by sending
packets to its victim directly.
This is frequently untrue. The network may be configured such that the
attacker does not have direct connectivity to a victim, such as when the
victim is inside a firewall and the attack is carried out via a host
within within a DMZ.
I assume that you mean the attacker itself is located somewhere in the
Internet, the correspondent node being tricked into sending flooding
packets sits inside the DMZ, and the flooding packets are directed to a
victim in the internal network -- is this correct?
Yes.
In this case, wouldn't the flooding packets be dropped by the firewall
between the DMZ and the internal network because a node in the DMZ is not
allowed to contact a node in the intranet?
firewall firewall
| |
intranet | DMZ | Internet
| ~~~ |
| |
victim|X-- correspondent - attacker
| node |
No. In one common configuration, the difference between the DMZ and the
internet at large is that nodes in the DMZ _are_ allowed to contact nodes
in the intranet.
On the other hand, if no firewall exists between the correspondent node
and the victim, then the attacker could trick the correspondent node into
flooding the victim with unrequested packets. Yet in this case,
unamplified flooding would also be possible for the attacker without HIP
because the attacker could send flooding packets with an IPv6 Routing
header, directing the packets to the correspondent node first, and from
there to the victim. To prevent this attack, the firewall would have to
look into the flooding packets' extension headers since the IPv6 header
would (legitimately) include the correspondent node's IP address.
Hrm. That assumes the correspondent node is willing to route the traffic,
and that the firewall doesn't inspect extension headers. I don't know how
realistic those assumptions are, but I'm not sure it matters. The key
thing is that avenues for unamplified flooding are common enough that
adding one more isn't going to make much difference.
In any case, the above statement from the draft, which you are referring
to, should be rephrased to the following:
2. An attacker can always cause unamplified flooding by sending
itself packets to its victim, either directly addressing the
victim in the packets, or guiding the packets along a specific
path by means of an IPv6 Routing header.
s/can always/can often/ ?
=
Section 4.2: Locator Type and Locator
Are locator types critical? What happens when a host tries to add or
move to a locator which is not supported by its peer?
We chose to limit this protocol specification to locators of type 1 (ESP
SPI plus IPv6 or IPv4-in-IPv6 address) at this point, and to leave
locators of type 0 for further study. This is briefly mentioned at the
end of section 5.2, but I think you are right that this should also be
mentioned at a more prominent position. I suggest adding the following
text to the end of section 4.2:
This protocol specification limits the use of locators to those with
Locator Type 1. Future extensions to this protocol may specify the
use of locators with Locator Type 0. One example where locators with
Locator Type 0 would be useful is the inclusion of a LOCATOR parameter
in an R1 packet. This requires the use of type-0 locators since no
ESP
SAs are set up at that point.
Ok, but what actually happens if someone tells you they are moving to a
locator with type 2, which you can't handle? If you drop the update on the
floor, they will just keep retransmitting it (BTW, I assume HIP specifies
exponential backoff).
=
Section 5.2: Sending LOCATORs
The announcement of link-local addresses is a policy decision; such
addresses used as Preferred locators will create reachability
problems when the host moves to another link.
In fact, even a host which is not mobile should be careful to avoid
advertising link-local addresses to peers not on the same link.
Yes, that's true. We could extend the above sentence to the following:
Link-local addresses MAY be announced to peers that are known to be
neighbors on the same link, for example, when the IP destination
address of a peer is link-local, too. The announcement of link-local
Re: secdir review of draft-ietf-hip-mm-04.txt
On Tuesday, January 30, 2007 11:04:37 PM +0100 Christian Vogt [EMAIL PROTECTED] wrote: Given that the protocol right now only allows type-1 locators, do you think that the handling of different locator types could be left to those protocol extensions that specify them? I think you need to specify what happens if you see a type you don't understand, so that when you do specify a new locator type, existing implementations will have a behavior you can depend on. Otherwise, you're painting yourself into a corner with respect to protocol updates. After all, a mobile node using a locator of a type other than 1 would not comply to the current protocol specification, and hence it would be legitimate for the peer to drop the mobile node's UPDATEs. Sure, but the question is whether you _want_ that to be legitimate behavior. If you allow this, then hosts using a new locator type will be unable to probe to discover whether other hosts also support that type, because a negative response is indistinguishable from a dropped packet. I had trouble last week designing a negotiation mechanism for another (non-IETF) protocol with exactly this problem. I recommend against it, but I won't push. On the other hand, the draft could certainly state in section 5.3 (Handling Received Locators) that A host MUST drop any received UPDATE packets that include a locator with a Locator Type other than 1. I think even that is preferable to leaving the behavior unspecified. Section 5.2: Sending LOCATORs The announcement of link-local addresses is a policy decision; such addresses used as Preferred locators will create reachability problems when the host moves to another link. In fact, even a host which is not mobile should be careful to avoid advertising link-local addresses to peers not on the same link. Yes, that's true. We could extend the above sentence to the following: Link-local addresses MAY be announced to peers that are known to be neighbors on the same link, for example, when the IP destination address of a peer is link-local, too. The announcement of link-local addresses in this case is a policy decision; link-local addresses used as Preferred locators will create reachability problems when the host moves to another link. In any case, link-local addresses MUST NOT be announced to a peer unless that peer is known to be on the same link. I think that would be a good change. But maybe there are people reading this thread with more layer-3 expertise than I who can comment... A mobile node could inspect its IPv6 Neighbor Cache to find whether a particular peer is on-link, even if that peer is known by a global IP address. The mobile node would de-register the link-local address with the peer when movement detection indicates that the mobile node has moved to a different link. The mobile node could further rely on Neighbor Unreachability Detection to find out when that neighbor has moved away. Yes, those all sound reasonable to me. But I am not an IPv6 expert. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-hip-mm-04.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I found this document to be fairly straightforward and easy to understand, even without a deep background in HIP. It does introduce new security considerations associated with the ability to cause traffic destined for a host to be redirected to a new location. However, these are discussed and, provided HIP itself behaves as advertised, they are adequately addressed. I have a few comments and questions, but nothing to indicate this document should not be published as Experimental. Section 3.1.2: Mobility Overview This UPDATE packet is acknowledged by the peer, and is protected by retransmission. What does protected by retransmission mean here? = Section 3.3.2: Credit-Based Authorization 2. An attacker can always cause unamplified flooding by sending packets to its victim directly. This is frequently untrue. The network may be configured such that the attacker does not have direct connectivity to a victim, such as when the victim is inside a firewall and the attack is carried out via a host within within a DMZ. Or, an attacker may attempt to create congestion on the link between two victims, where the attacher has better connectivity to both victims than they do to each other. IMHO this is not a show-stopper -- the hypothesis quoted above is true in a large number of cases, and it does appear to me that the credit-based authorization scheme described here will have a positive erffect in those cases without otherwise being harmful. However, it is worth pointing out that this is not a cure-all. = Section 4.2: Locator Type and Locator Are locator types critical? What happens when a host tries to add or move to a locator which is not supported by its peer? = Section 5.2: Sending LOCATORs The announcement of link-local addresses is a policy decision; such addresses used as Preferred locators will create reachability problems when the host moves to another link. In fact, even a host which is not mobile should be careful to avoid advertising link-local addresses to peers not on the same link. = 6. Security Considerations The HIP mobility mechanism provides a secure means of updating a host's IP address via HIP UPDATE packets. Upon receipt, a HIP host cryptographically verifies the sender of an UPDATE, so forging or replaying a HIP UPDATE packet is very difficult (see [2]). Therefore, security issues reside in other attack domains. I believe this is an accurate assessment. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-lemonade-deployments (Deployment Considerations for lemonade-compliant Mobile Email) to BCP
On Wednesday, January 17, 2007 04:31:37 PM -0800 Randall Gellens [EMAIL PROTECTED] wrote: s/exist a large number/exists a large number/ in 8 (?) I think you're right, but it sounds funny to my ear, so I'd prefer there are a large number. This is getting into the realm of trivial editorial items that don't affect the readability of the document and can be handled by the RFC-Editor. That said, the original text is correct; the sentence is about the existence of (a large number of) approaches; it is the _approaches_ which are said to exist here, not the number. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
On Friday, January 12, 2007 04:04:08 PM -0500 Sam Hartman [EMAIL PROTECTED] wrote: Let me ask a silly question here: Why do we want to distinguish proto shepherds from chairs? I at least hope all my WGs will produce documents. That means most of my chairs will be proto shepherds. Does the difference matter? I guess that depends on how much you want to depend on access controls vs people not doing things they're not supposed to. I believe the process admits the occasional shepherd who is not a chair or AD; if nothing else, I could imagine a chair who steps down but continues to shepherd his documents which are already partway through the process. Certainly not every chair will shepherd every document produced by his WG. So, a WG chair has certain rights with respect to documents in his WG. And a shepherd has certain rights with respect to documents he shepherds. The question is, is the difference great enough that we can't simply give all of those people the same powers, at least with respect to any given WG? Note that even if we just give all the shepherding powers to chairs, we still may need the concept of a shepherd who is not a chair, because I presume the tracker will inherit its idea of who is chair of what from other sources. It may be desirable, both here and in other cases, to be able to give someone some of the bits that go along with a role without actually publishing their name as a point of contact. Having that ability encourages people to delegate authorization instead of giving away their credentials. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria
On Wednesday, January 03, 2007 10:49:33 PM + Dave Crocker [EMAIL PROTECTED] wrote: C. PROCEDURAL BREAKAGE --- * IETF process related to document advancement was not carried out; e.g., there are unresolved and substantive Last Call comments which the document does not address... IMHO, this particular situation is more than just procedural breakage. If a document reaches this point with outstanding last call comments, then there is a more basic failure. Such a document should not have reached the point where a DISCUSS is required to keep it from progressing long enough for the comment to be addressed. D. CONSTITUENCY MISMATCH - * The IETF as a whole does not have consensus on the technical approachor document. There are cases where individual working groups or areas have forged rough consensus around a technical approach which does not garner IETF consensus. An AD may DISCUSS a document where she or he believes this to be the case. While the Area Director should describe the technical area where consensus is flawed, the focus of the DISCUSS and its resolution shouldbe on how to forge a cross-IETF consensus. Presumably, the working group has been populated by people interested in using the specification in the near-term. If no such people are active in the working group, then why has a standards effort been pursued? The above criterion says that these motivated participants' concerns are not sufficient, when weighed against the more detached desires of the active IETF community. Asserting this criterion seems to represent an IETF failure at so many different levels, that it raises fundamental questions about the nature and purpose of the IETF. By implication, it says that we do not care as much about the people who are going to depend upon the protocol, as we do about those who won't. Not necessarily. It may say that the members of the working group have consensus to break the Internet in order to sell more of their product. The people who invented a thing, developed it, and depend on its acceptance in the marketplace for their livelyhood may be tempted to overlook any number of significant problems. Part of the job of the IESG is to prevent such people from using the IETF to make the Internet worse instead of better. Now, I'll agree that an objection on this basis indicates a failure. But the failure is often the working group's in not understanding the bigger picture, not asking for help in doing so, or not caring about it. Sometimes, the failure is not that help was not requested, but that it was not given, or not useful. However... The IETF process is a cooperative process toward a common goal, not an adversarial process. Our common goal is to make the Internet better; if your goal is to rubber-stamp your pet proposal or market your product whether it makes the Internet better or not, you don't belong here. Arguments like no one warned my about this issue before, so it wouldn't be fair to hold back my document now until it's fixed manage to completely miss the point. If fixing the problem before the document is published advances the goal, then that is what we should do. If publishing the document without the fix advances the goal, then _that_ is what we should do. Sometimes, the right answer is to do both! If an IESG member places a DISCUSS on a document, and your response is you don't have sufficient grounds for a DISCUSS or please tell me what change to make to my document to make the DISCUSS go away, then you are totally missing the point. The correct response is please help us to understand your concern so that we can work toward a resolution. Sometimes that resolution will in fact be a simple and obvious change to the document. Sometimes it will involve pointing out the obvious reason why there is not really a problem. Usually it will be somewhere in between. It may involve publishing a document which has a known problem because doing so advances the goal more than fixing the problem would. It may involve scrapping the whole document and starting over. Usually, it will be somewhere in between. Often, the way forward will not be immediately obvious to anyone involved. THIS IS NOT A FAILURE. It is the system working the way it is supposed to, with people working together to produce high-quality standards that improve the Internet. So, is constituency mismatch a failure of the IETF? Quite often, yes. Does it indicate a fundamental flaw in the process? NO. It means that the process did not get followed, and in particular that a group failed to work with the community to produce a document which the IETF as a whole could support. That may be because someone doesn't get it, and thus wasn't aware of who they needed to work with or what they needed to do or how to ask for help. We should work with such people, both to help them get it and to help
Re: Discuss criteria
On Tuesday, January 02, 2007 12:21:37 AM +0100 Harald Alvestrand [EMAIL PROTECTED] wrote: John Leslie wrote: This is venturing into dangerous territory. The best expertise on the technical issues involved _should_ be in the WG that produced the document. Expecting to find _better_ expertise within the IESG seems less than rational... Expecting the best available expertise on charset issues and string matching in the Kerberos WG is, in my opinion, less than rational. As chair of the WG in question, I have to agree. Though we do have a couple of individuals who seem to have developed more expertise in that area than is healthy. :-) But the Kerberos WG still has to define protocol operations where strings are compared. Sometimes a WG needs help with issues outside their core purview, and sometimes they won't discover that until their documents hit the IESG. That's life. (apologies to the Kerberos folks, who, I think, are now very much educated on those specific issues, for using them as an example) None needed; I think you illustrated the point perfectly. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria
On Thursday, January 04, 2007 03:12:07 PM +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: I don't see where you get that from. I can think of two cases where we might get such an assertion from an AD: 1. The IETF Last Call did generate dissent. I'd expect this to be the common case. That is, if an AD asserts there is lack of consensus, I would normally expect that to be because there is a demonstrated lack of rough consensus that has not been resolved. 2. The IETF Last Call generated indifference *and* the proposal, whatever it is, clearly has very wide impact. At that point it seems perfectly legitimate to question whether people really know what that have agreed to by their silence. Now, a better way to handle that is for the concerned AD to send explicit mail to the community during the last call - but if that hasn't happened, I don't see anything illegitimate in a DISCUSS asking for additional community review. Neither do I, but I would not this to be described not as a lack of consensus, but as a case where broad _support_ seems necessary but is not present, or one in which the AD is concerned that the document has not received sufficient review in a particular area. However, since the IETF works by consensus, I don't see how we can take an assertion of non-consensus off the list. Agree. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
On Monday, January 08, 2007 11:03:00 AM + Adrian Farrel [EMAIL PROTECTED] wrote: If we don't do this then they simply are not DISCUSSes. They are just post-it notes. Not true. Remember that DISCUSS is a ballot position. As I understand it from my conversation with an IESG member several years ago, its meaning is I think there is an issue the IESG needs to discuss. As Spencer described, in many cases the resulting discussion satisfies the concerns of that IESG member, and the ballot position is changed to something else. Sometimes that happens prior to the telechat - if the issue is I don't think we can paint the walls bright black, the sponsoring AD may reply out of band and say yes, but the document says to paint them bright _blue_, and the issue is resolved even before the telechat. So, in many cases the WG does not need to be involved in such a discussion. Copying the WG on every such note would only generate confusion and invite people to start arguing in situations where doing so is premature and wasteful. That said, I _do_ wish the tracker would maintain history of DISCUSS and COMMENT comments, instead of only showing the latest ballot text. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
On Monday, January 08, 2007 12:52:16 PM +0100 Simon Josefsson [EMAIL PROTECTED] wrote: This lack of communication may cause friction. IESG members raise issues, which ends up the tracker, and for which they might not receive any response at all on. They may get the impression that the document author is inactive and not following up on problems raised (at least I would get that impression if I were preparing comments on others' document). The document author instead wonders why no comments or questions are generated by the IESG evaluation process. This indicates a failure on the part of the document shepherd, who is responsible for fostering that communication and for following up to make sure issues are resolved, and who _does_ get email for every tracker state change. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
On Monday, January 08, 2007 08:09:58 PM +0100 Frank Ellermann [EMAIL PROTECTED] wrote: How about allowing PROTO shepherds to post to the I-D tracker? Can't they ? At least the questionnaire (modulo 1F) is posted. Not at present. The writeup is posted by whoever processed the shepherd's request for publication (to iesg-secretary, which AFAIK is an RT queue). Further changes are generally made as necessary and appropriate by the IESG secretary, the AD who placed a DISCUSS, or the sponsoring AD, who is supposed to be copied on all of the shepherd's communication regarding the document. IIRC, there ws a plan at least at one time to provide greater access to shepherds, such as the ability to post comments on one of their documents and perhaps even make certain state changes. However, the tracker's access control model was somewhat primitive. There is work in progress (requirements-gathering appears to be nearly complete) to extend the tracker to provide WG chairs with tools to track documents while they are still in the hands of the working group. I expect this will require extending the access control model, so perhaps when that's done we'll see enhanced access for shepherds. Anyone from the tools team want to comment on this? -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft status links on the wg pages?
On Wednesday, December 20, 2006 07:19:10 AM -0800 Dave Crocker [EMAIL PROTECTED] wrote: Since we rely on volunteers for a number of IETF activities, beyond writing specs, it is at least worth exploring this additional avenue of saving money (and maybe even getting better operations, although I note this not as a criticism of the Secretariat, past or present, but of the normal effects of being overworked.) The tools team has produced a lot of neat stuff. However, the more they maintain on a long-term basis, the less time they will have to produce new neat stuff. I'd rather see the more-stable things maintained by people who are being paid to do so, both to reduce the chances of losing them if one or more volunteers become unwilling or unable to do so, and to free the time of those volunteers for new development that is both useful to the IETF and probably more interesting to work on. That said, I think we should all keep in mind that the tools team are volunteers, and the rest of us do _not_ get to decide what they spend their time on. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ion-ion-store open for public comment
On Monday, December 18, 2006 10:41:56 PM -0800 Dave Crocker [EMAIL PROTECTED] wrote: Jeffrey Hutzelman wrote: One might want to wonder, a bit, about the IETF's having a growing number of such documents, and that this might make it more difficult to know enough about IETF procedures and the like On the contrary, I don't think the process has gotten any more complex; we just have more documentation about it. [...] I'm sure the list is longer, but the above seem sufficient for making the point. OK; I stand corrected - the process has gotten more complex, and in many cases less flexible. But the documentation has improved, too. We can argue forever about the advantages and disadvantages of the former and how to fix what's wrong without making it more broken, but I hope we can agree that having good documentation is helpful. Yes, the rules are different, just as the rules for Informational RFCs are different from standards track RFCs. That's why the idea of a new RFC sub-category make sense. Maybe. But it seems sort of heavyweight to me. The same sort of correction would have taken the IETF six months to a year plus a lot of arguing and reopening old issues. And then there is the possibility that you are describing a deeper IETF problem that needs its own focus... I'm probably describing a symptom of such a problem. But I've been unable to figure out what the real problem is, and I'm starting to get weary of the effort, and of band-aids that promise to make everything all better without such understanding. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ion-ion-store open for public comment
On Sunday, December 17, 2006 06:05:45 PM -0800 Dave Crocker [EMAIL PROTECTED] wrote: One might want to wonder, a bit, about the IETF's having a growing number of such documents, and that this might make it more difficult to know enough about IETF procedures and the like On the contrary, I don't think the process has gotten any more complex; we just have more documentation about it. Whether that makes it easier or harder to know enough about IETF procedures would seem to depend on the accuracy and currency of that documentation. On reflecting about the forces that seem to have led to the creation of the ION experiment, I suspect that there are two concerns: 1) Needing a label that collects together internal operating notes and distinguishes them from other IETF documents, and 2) the overhead of getting an RFC published. The first could be solved easily by adding a new, non-standard-track sub-label to the RFC series and I suspect the latter could be resolved by making an arrangement with the RFC Editor to have IONs go through less handling and proofing overhead. (And, gosh, this might even give a basis for reviewing why RFC publication has become high overhead...) I don't think it's just about the overhead of getting an RFC _published_; it's about the overhead of achieving IETF consensus on one. Process BCP's should be about IETF-level policy, not the operational practices of the I* or of any other entity that implements those policies. Recently, the Federal Communications Commission in the US adopted a number of changes to regulations governing the Amateur Radio service. The changes were officially published on November 15, and went into effect 30 days later. In between, someone noticed an error which inadvertently made certain operations illegal that should not have been, and asked the FCC to fix it. The fix was approved on December 15, the same day the new regulations became effective, and will probably become effective sometime in February. The same sort of correction would have taken the IETF six months to a year plus a lot of arguing and reopening old issues. A similar correction to an ION would have taken days, at most. And that's sort of the point - overall policy should be set by IETF consensus, but operational details should not. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] Review of draft-manral-ipsec-rfc4305-bis-errata-02.txt
On Monday, December 11, 2006 04:34:54 PM -0600 Nicolas Williams [EMAIL PROTECTED] wrote: On Mon, Dec 11, 2006 at 05:30:26PM -0500, Russ Housley wrote: Nico: Use of the NULL ESP algorithm implies no confidentiality protection, while use of the NULL AH algorithm implies no integrity protection (unless combined mode ESP algorithms are used). And in general we want IPsec used to provide integrity or confidentiality+integrity protection, but not really just confidentiality protection. I generally agree with your point. Integrity protection is important, but I am not sure that this is the document to drive this point. We have seen NULL encryption and NULL integrity algorithms are very useful for debugging. Right. I am not suggesting a change of policy here, but rather an explanation for the MUST NOT use NULL ESP and NULL AH together. So, MUST is for implementors. It's about requirements on the implementation, not on how it is used. If you say that the NULL algorithms MUST NOT be used, you are requiring the implementation not to permit their use under any circumstances. That seems excessively strong. I agree with Russ - while deploying the NULL algorithms in production would be silly, having them for debugging can be terribly useful. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
On Wednesday, November 22, 2006 04:00:49 PM + Tony Finch [EMAIL PROTECTED] wrote: On Wed, 22 Nov 2006, [EMAIL PROTECTED] wrote: SMTP, on the other hand is an operational failure and even today, no one really knows how to properly implement and properly maintain an SMTP service. The actions of criminals exploiting weaknesses in the SMTP architecture have led to a series of bandaids that still have not proven to be effective. Any communications mechanism which allows you (or your organization) to receive messages from people (or organizations) you have no prior relationship with is vulnerable to spam. Spam is NOT an SMTP problem. Correct. For example, the postal mail system is vulnerable to this same problem: As is my usual practice, I asked the post office to hold my mail while I was away at IETF 67 (this is a standard service offered by the US Postal Service at no charge). I took some time off after, so when I finally picked up my mail, it was about 3 weeks worth. I received a plastic shopping bag full of mail, and after I sorted through it, I had several bills and a grand total of three other pieces, all of which were prearranged (an issue of QST, a newsletter, and an invitation). The rest of the bag was spam. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)
On Monday, October 23, 2006 04:14:10 PM -0400 John C Klensin [EMAIL PROTECTED] wrote: (1) Any language in 3683 that appears to limit other actions with regard to mailing list abuse needs to be overridden. Agree. IMHO this is by far the most important part of Brian's proposal, or of its intent, anyway. (2) We should let the experiment of 4633 run its course before doing major retuning. Agree. (3) 3683, at least for the present, should remain on the table. (4) It seems to me that the arguments that we should not permit indefinite (or very long) suspensions without some more formal action and opportunity for community comment have merit. 3683 is a _very_ big hammer. Such tools should not be difficult to use, but they should not be used without careful consideration of whether they are appropriate. You can do a lot of damage trying to use s sledgehammer to drive a finishing nail. I don't think the PR-action mechanism needs to be rescinded, but I do think it needs to be used with care, and I definitely think we need alternatives. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-iesg-discuss-criteria (was: [...] DISCUSS: draft-carpenter-rescind-3683)
On Friday, October 20, 2006 04:01:13 AM +0200 Frank Ellermann [EMAIL PROTECTED] wrote: For the draft in question that means that it's now at 12:2, and if one member changes his or her mind it could fail with a 11:3. You are confusing the normal balloting process with the alternative one. Under the normal process, three IESG members have voted yes on this document (which is 3x the usual number), 9 have voted no-obj, two have abstained (including Brian, who's recused himself because he is the author), and there is one discuss. The alternative balloting procedure is designed to allow the IESG to approve a document over the strong objections of one of its members (presumably, an IESG member having only weak objections would enter an abstain, as Ted Hardie has done in this case). This is an unusual step requiring a strong consensus, and it is not designed to be easy. As far as I can tell, it also has not been invoked for this document. but since you brought it up, let's look at this. The text you quoted matches that at http://www.ietf.org/u/ietfchair/discuss-criteria.html, and requires two-thirds yes and not more than two no votes. Note that these are votes entered specifically under the alternative balloting procedure; they are not derived from any normal votes which may have been entered. In particular, there is no reason to assume that someone who voted yes or no-objection under the normal procedure will vote yes under the alternative procedure. Under the normal procedure, a yes vote means I think this document should be published and a no-obj means I don't have any strong feelings against publishing this document; under the alternative procedure, a yes mean I really think this document should be published, even though person X has objections. The latter is rather a stronger statement. Now, since Brian is the document author and has recused himself, there are 14 sitting AD's who would be eligible to cast votes under the alternative procedure. Since ceil(14*2/3) == 10, that means that publishing the document would require at least 10 yes votes and not more than 2 no votes. Since abstain and no do not mean the same thing, the document could pass under that procedure with as many as 4 IESG members abstaining -- but not with more than 2 actively voting no. Finally, note that the alternative balloting procedure is intended to be applied as a last resort, when it is clear that the AD holding the discuss and the WG or individual who submitted the document cannot reconcile their differences. I would be quite surprised to see this procedure invoked for the document now under discussion, since it is clear that steps are actively being undertaken to try to address David's concerns. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
On Wednesday, October 04, 2006 02:31:36 PM -0700 todd glassey [EMAIL PROTECTED] wrote: Vidya good commentary, maybe I can add some more. The NEA, per the charter-need's justification statement says: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the posture of endpoint devices Ah two new terms of Art - Posture and Devices. I only see one. I believe device is a fairly well-understood term, though perhaps node would have been more appropriate in this context. However, I completely agree that this proposed charter uses the term posture far too often not to define it. I fail to see how whether my computer is sitting upright or lying on its side is relevant to whether it should be allowed access to the network. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Tuesday, October 03, 2006 11:27:36 AM -0400 John C Klensin [EMAIL PROTECTED] wrote: Good. If we disagree, it is only on what a formal change constitutes. I would consider an in-depth summary of what is wrong with 2026 (at least on any basis other than a personal informational opinion piece) and any attempt to replace 2026 with a version that reflects current practice to be such formal changes, if only because they would require almost the same level of effort in review and consensus-finding as actually changing the process. But some might disagree. As I start to write this, I've read through a little more than half of Brian's draft; I stopped when I found something to comment on. What I'm seeing is descriptive, not prescriptive - it describes ways in which RFC2026 differs from what we actually do, offers interpretation based on current practice, and so on. I think a document like that, taken as a non-normative description rather than a specification, could be useful operationally. People who read RFC2026 without being familiar with current practice are likely to be rather confused, and Brian's draft clears up many of the possible confusions and offers additional commentary that may be useful in understanding what goes on. I assume that a document like this would be published as an informational document, without the benefit of IETF consensus and possibly without even a Last Call (there is _nothing_ that says Informational documents need a last call, and they are frequently published without one). I wouldn't have a problem with that, and in fact, it's probably best that this _not_ be an IETF consensus document if it is to serve a useful purpose. Now, the thing I found to comment on. Brian writes the following about the last paragraph of section 4.2.2: This presumably means outside of the IETF process not outside of the Internet community. As part of this year's RFC Editor RFP process, clarity is being sought about the independent submissions track, which should probably not be discussed at all in the basic definition of the standards process. See [I-D.klensin-rfc-independent] for a more current description. Actually, I think the section means what it says, and is referring _not_ to independent submissions but to cases where a specification developed elsewhere is republished as an RFC to make it more readily available to the Internet community. For example, we do this on a fairly regular basis with the specifications of cryptographic hash functions. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Friday, September 29, 2006 11:28:56 PM +0200 Eliot Lear [EMAIL PROTECTED] wrote: My point here is that the three step process is not used as intended. Existing practice clearly demonstrates that the vast majority of our work - far more than intended - never reaches beyond PS. This is reality. Simply documenting that fact in a new RFC2026bis would be to say, Our standards are broken and we know they're broken. That's not what motivated me to write a draft. What motivated me to write a draft was that it's important that we say what we do and we do what we say. Then write that. We have a process which defines three stages and what has to happen to progress to each stage. Where reality diverges from RFC2026 is that 2026 specifies particular timelines for reviewing documents and progressing them along the standards track, while what actually happens is that documents are progressed only when someone cares enough about them to make it happen. As your graph shows, we published documents at all three levels last year. We could eliminate one or both of the extra steps entirely, or become more agressive about actually making them happen, or do any of a wide variety of other things to make them happen. But none of those would be consistent with current practice, which is to progress documents beyond PS if and only if someone cares enough to make it happen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)
On Wednesday, September 27, 2006 08:49:19 AM -0400 John C Klensin [EMAIL PROTECTED] wrote: Sure. But that isn't what the term means in common (non-IETF) practice and the document is quite specific that the return value contain exactly one label (er, item) with no provision at all for two. Except it doesn't say label; that's your interpretation. I grant it is an entirely reasonable interpretation, and in fact the alternate interpretation that was suggested is not one that would have occurred to me. IMO, this document should be rejected, and should stay rejected until the authors clean up their terminology, explain how the capability is intended to be used, and then explain why the Internet needs it. Once it reaches that point, a Last Call review will make sense I agree. As it stands, this document refers to DNS concepts using terms other than those normally used, and in particular the term domain suffix, while not having any formal meaning I am aware of, has at least one commonly-used meaning which is different than that apparently intended by the authors. In short, I believe this document currently lacks the precision appropriate for an IETF specification. , but I would suggest that the proposal should still be rejected unless the return value can be an all-but-hostname FQDN, not a single-label suffix. I agree with this also, given that the latter seems fairly useless. Fortunately, I suspect the document authors also agree, and are simply using poor terminology to say what they mean. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)
On Thursday, September 28, 2006 07:32:17 AM +1000 Mark Andrews [EMAIL PROTECTED] wrote: Except it doesn't say label; that's your interpretation. I grant it is an entirely reasonable interpretation, and in fact the alternate interpretation that was suggested is not one that would have occurred to me. Well for this option to encode a TLD it would have to encode 2 label. True, but that is a subtlety that is lost on most people. As for domain name suffix while I can't remember seeing a formal definition. In the DNS world it is any domain name appended to a unqualified or partially qualified domain name to create a fully qualified domain name. Except among people who use it to mean TLD, which does seem to be a common usage. I have seen this usage on the web sites of domain registars. There are clearly multiple uses here, and which one the reader assumes will depend on his background and possibly other factors. Now the DNS RFC's always talk about both wire and presentation formats. The option itself is a domain name in uncompress DNS wire format. Yes; I think the reference makes that reasonably clear, particularly if one is already familiar with what is currently common practice in DHCP and the DNS. But as has been pointed out, not all of the readers of this document will have that background. Basically, if John Klensin misinterpreted your document, and Dave Crocker did, and I did, that's at least three readers with at least some familiarity with the concepts involved for whom the document was not clear enough. IMHO, that's enough to suggest it could use some clarification. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fw: Why cant the IETF embrace an open Election Process rather than some
On Thursday, September 14, 2006 01:37:11 PM +0100 Tim Chown [EMAIL PROTECTED] wrote: Isn't he barred from posting here? Perhaps, but one of the checks against abuse of the ability to bar posters is that they can still get a point across if they can convince someone else to forward their comments. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what happened to newtrk?
On Tuesday, September 12, 2006 06:06:08 PM -0400 John C Klensin [EMAIL PROTECTED] wrote: You are correct. I did not address that issue, partially because, personally, I do not consider it very important. While documenting what we are doing would be nice, I don't believe the community is completely happy with what we are doing and, hence, that energy would be better spent figuring out how to move forward. I think that if people are interested in documenting what we are currently doing, the most effective way to do that is for someone to write one or more informational, descriptive internet-drafts that attempt to document the current state of affairs, and then ask for input on them. The author(s) of such documents should feel free to reject input suggesting that the process should be changed as out of scope. I think that if someone had the desire and energy to do this work, it could be done relatively easily and without much controversy, provided it was understood to be non-normative in nature. I don't consider such an effort useful enough to engage in it myself, or to actively encourage someone else to do so. But I certainly won't _discourage_ someone who's interested in spending time on such an effort. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
On Fri, 8 Sep 2006, Ned Freed wrote: I don't think the lack of support for unencrypted IMAP or POP is quite sufficient. What's to stop an attacker acting as a MITM (by publishing a bogus SRV record or whatever) getting an unencypted connection and turning around and connecting to the server using encryption? That's exactly the scenario I was thinking of. However, just because this and other attacks are real doesn't mean that there's no security gain from a setup that's subject to downgrade attacks. Often as not it is far more difficult to mount a MITM attack than it is to mount to perform passive eavesdropping. True. However, spoofing a DNS response is often considerably easier than mounting a MITM attack at the network layer. Phill is correct that deploying DNSSEC helps with this. However, I don't see wide deployment of DNSSEC today, and I'm not holding my breath. Please, feel free to prove my pessimism unwarranted. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
On Thursday, September 07, 2006 07:07:51 PM -0400 John C Klensin [EMAIL PROTECTED] wrote: However, 2195 is not, itself, a SASL method and there is nothing in the procedural rules as I understand them that permits the SASL WG to de-standardize it (you could write any of several styles of document that would designate it as not recommended or even historic but such documents had best be in your Charter and Last Called as doing that). To the extent that SASL is the successor to the original extensible authentication framework contained in IMAPv4, yes, CRAM-MD5 is a SASL mechanism. The cross-references don't explicitly point out that RFC obsoletes RFC1731, but it seems clear that was the intent. Now, suppose someone comes along who _likes_ the non-SASL incarnation of CRAM-MD5 in 2195. Let's call this hypothetical person nobody to avoid casting aspersions on Frank. Nothing in our current procedures prevents him, at any time, from preparing an interoperability report on 2195-specified CRAM-MD5, pointing out that there are many deployed interoperable implementations, and asking that 2195 be reclassified (or a 2195bis be published) as a Draft Standard. Well, he could ask that 2195 be advanced as-is, but I would expect such an effort to fail, as that version has turned out to be somewhat underspecified. Multiple interoperable implementations is not the _old_ criteria for advancement; it is necessary but not sufficient(*). Given that the SASL WG has an explicit charter item to produce a revised TS for CRAM-MD5, with RFC 2195 as a starting point, I would expect any effort to do so outside of that WG to meet with very strong resistance. As Kurt has noted, the WG is nearly finished its work on that item, and the resulting draft will be in Last Call soon. The working group decided, due to a variety of considerations, not to pursue publication of the new document on the standards track, and instead to ask that it be published as Informational. However, the decision as to whether to publish that document and what status to assign it belongs to the IESG, not the working group. IMHO, an argument that it should be assigned a status other than that requested by the working group would be an appropriate subject for a Last Call comment. If nobody were so inclined, I would expect him to protest any effort on the part of the SASL WG to deprecate 2195 itself Why? That working group's charter clearly includes an item to produce an updated specification for CRAM-MD5, and it seems obvious that the intent is that such a new specification obsolete RFC 2195 (if it's not obvious, that's a bug in the charter; certainly everyone participating in the work has understood that to be the intent). (*) I think this is perhaps the crux of the matter. I do not believe that every old specification should be advanced along the standards track simply because it has been around a while and has multiple implementations. Advancing a specification to Draft Standard sends the signal that the IETF thinks the specification is a good idea and that people should deploy it. Protocols for which that is not the case have no business advancing toward the status of Internet Standard, *even if we thought they were good ideas when they were written*. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
On Thursday, September 07, 2006 07:48:45 PM -0400 Jeffrey Hutzelman [EMAIL PROTECTED] wrote: Well, he could ask that 2195 be advanced as-is, but I would expect such an effort to fail, as that version has turned out to be somewhat underspecified. Multiple interoperable implementations is not the _old_ criteria for advancement; it is necessary but not sufficient(*). Ugh. s/_old_/_only_/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
On Friday, September 08, 2006 04:49:11 AM +0200 Frank Ellermann [EMAIL PROTECTED] wrote: That's my real problem: If users or worse implementors don't know how stuff works it's bad. What you end up with are some hypothetical situations like this: A hypothetical situation is one that could occur, but didn't. A thinly veiled description of an actual situation is not a hypothetical. - a lottery with a cute crypto random algorithm, and everybody thought that it's perfect. Turns out that it's useless if the list of participants is published together with the result of the lottery. The spec was already quite clear on this. - a nice library where implementors use it as documented. A few years later the IETF changes an obscure default in the library, and again years later an IETF WG decides that the implementations using the updated library are non-conforming The change you are referring to in GSS-API v2u1 (RFC2743) is hardly to an obscure default; in fact, it was the addition of a new capability. The API (_not_ the wire protocol) did change in a backward-incompatible way, and the spec documented that. All that was required was to read the new API specification before using a library which implements the new version of the API.(*) The SASL WG, which is not responsible for GSS-API, has not _decided_ that implementations of an old protocol using a newer library without updating to the new API are non-conforming; however, some of its individual members did point out that updating an implementation in this way can result in behavior that does not conform to that required by the original spec. What the SASL WG _did_ decide was that its updated specification, retargeted against the new GSS-API version, needed to express a requirement made necessary by the backward-incompatible change. - an IETF ticket system where apparently nobody (and certainly not me) knows precisely why it used to work with my browser until summer 2005, but doesn't anymore - ditto a famous bookshop where I ordered books securely for years, and now I use their insecure interface, because the former doesn't work anymore for me (only their server for the secure icons, but bad enough to be unusable for orders) - a browser test site by a CERT where nobody knows why their test suite doesn't work with my browser (other test sites find no problem). I don't think I can help you with any of these. - an IETF server where my browser tells me again and again that the server certificate expired 1998 (the correct behaviour for this situation as far as I can judge it), but I'm pretty sure that it did work before Maybe your browser was broken before? Maybe the cert wasn't expired before? In any case, I don't think this scenario supports your argument that documenting a protocol is better than not documenting it, because I doubt that the problem is the result of an ill-defined or underspecified protocol. Instead, I'd guess that it is a result of an oversight on the part of the operator of that server, combined with a complete lack of anyone bothering to report the problem (but that's just a guess, based on my experiences with people not bothering to report problems to me and then complaining that they never got fixed). In addition, while I mostly agree that documenting a protocol is usually better than not documenting it, I fail to see the relevance of that point in this discussion. If we're talking about what happened to newtrk or what the standards process should be, then we're talking about how to designate and advance protocol specifications that _are_ being published. If we're talking specifically about CRAM-MD5, then please bear in mind that the SASL WG decided some time ago that the correct course of action was to produce an informational document describing CRAM-MD5 as deployed, rather than to produce an incompatible updated protocol which we would not ever encourage anyone to actually deploy. For those watching from the sidelines, the updated document is draft-ietf-sasl-crammd5-07.txt. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
On Thursday, September 07, 2006 08:12:44 PM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: The solution to this particular problem is to use SSL as the transport. IMAP and POP both support this use. It is a trivial matter to discover that IMAPS is supported using an SRV record. Of course, if you depend on this technique to determine whether TLS should be used, you are subject to a downgrade attack which not only exposes your password to a dictionary attack, but also makes it fairly simple for an attacker to gain access to the server as you _without_ carrying out such an attack. If you're going to depend on TLS to protect CRAM-MD5 or HTTP Digest or plaintext passwords, you need to know in advance that you're doing so, and properly validate the server's certificate. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Adjusting the Nomcom process
On Wednesday, September 06, 2006 02:08:06 PM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: One simple fix here would be to publish the list on IETF announce BEFORE it goes to the secretariat and to ONLY use that list regardless of whether people are excluded or not. I like that approach; it's straightforward and easy to analyze. This still leaves the question of what to do if people were left off the list and need to be added in. Yes; that's a hard one. The most common/likely failures can be handled by publishing the list twice, and allowing anyone to add their name at any time prior to the second publication. Anyone who wants to be sure they are added will submit their name before the first publication, and check to insure they are listed. However, that doesn't prevent a person from being excluded due to malicious interference or unusual communication problems. One possible answer would be to allow multiple entities to publish lists of volunteers (say, the Nomcom chair, the IETF secretariat, and the ISOC President), and use the union of the published lists (which any party can easily compute). Under this model, volunteers would normally be expected to submit their names as usual to the Nomcom chair, but if they are then omitted from the first list, would submit again to all three sources. Once this is done, the selection process consists of computing the union of the published lists, sorting according to a canonical order, and applying RFC3797 until enough candidates have been selected. Another safeguard that can be put in place here is to date the choice of random seeds a fixed time after the list is posted. What purpose would this requirement serve? -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On Thursday, August 31, 2006 11:11:51 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote: James Galvin wrote: But there is a part of the process that is not public: the actual selection of eligible volunteers. 1) The criteria are public. 2) The result is public, with the intention of time for review. I'm not sure how the internals of going from 1 to 2 could be made public and still function. Since the criteria are reasonably objective, I'm having trouble seeing how transparency on the decision process is meaningful. I agree. The important property here is not that any part of the process be observable, but that the results be independently verifiable. That is done by making all of the inputs(*) public before the process runs, and using a well-defined, fixed algorithm. (*) For this purpose, the random data itself is not an input, but the identification of the random source(s) and exactly how they are to be sampled is. At base, I suspect this demonstrates the problem with our being too rule-oriented, and not enough community oriented. It loses sight of the underpinnings of comfort and legitimacy, and that is community review and approval when a situation does -- or reasonably might -- entail the unknown or, at least, controversy. Really, as soon as the need or ability to make a decision as to whether to reset had been made, we had already lost. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On Thursday, August 31, 2006 06:43:53 AM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Furthermore the absence of a complaint makes things worse not better. Phill, I can assure you from personal knowledge that at least one complaint _was_ made. As Brian noted, Andrew took action to correct the issue before the formal dispute resolution process was invoked. And before you ask, no, I will not tell you who made the complaint, but I will say that I was not consulted on the issue of how to fix the problem, and that I don't believe the complaintant I know about was consulted either. Given the nature of the complaint (that a volunteer was ineligible), I believe there were two reasonable courses of action. One is to remove the name from the list before running the random process, and the other is to run the process with the name, but discard any selection of that name. If the error had been discovered before the random data became available, the first choice would have been the obvious one. However, it was not, and the situation is complicated by the fact that the list of volunteers did not become available in time for anyone to challenge eligibility prior to the random data becoming available. Even before the error in the list was discovered, I considered complaining about the timing issue and suggesting the remedy of running the process with new random data that would not become available before people had a chance to object (in other words, the same remedy that Andrew ended up applying). If you or anyone else feels that there is a problem, the correct course of action as described by RFC 3777 is to bring the issue to the nomcom chair and then, if the situation is not resolved to your satisfaction, take it to the ISOC President as a formal dispute. Nowhere does RFC 3777 suggest that a suitable remedy is to complain on a public mailing list that you were not personally consulted. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On Thursday, August 31, 2006 09:26:11 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote: Ned Freed wrote: The goal of this process is not just to make it hard to game the system, but also for everyone to be completely confident the system has not been gamed. Allowing the same person that creates the list the authority to later reject that list and start over based on an imperfection that didn't lead to a bogus selection makes it impossible to have the necessary confidence in the process. This strikes me as a key point about managing problems with this process (or maybe *any* IETF process.) A robust process has little or no dependence on the vagaries of one or a few people. The issue is not with the people but with the structure of the control mechanism. I agree with Ned here that an important design feature of this process is that it is easy to verify that the process was carried out correctly and that its results were not tampered with. I also agree with Dave that any failing in the present instance is in the process which allowed a situation to develop in which the results could be tampered with, and not with Andrew Lange's handling of that situation. I don't think anyone believes there was foul play here, but the problem is that a situation arose in which someone had to decide how to proceed, and that decision had predictable results. Worse, it is trivially easy for a future nomcom chair to recreate that situation, and it may be possible even for some other person to do so. I've reviewed the specification for this process, including the random selection algorithm, several times over the past few years. I've always believed the selection process was reasonably well-designed to meet its goals, and I certainly didn't predict the present situation. However, now that it's been raised, it seems reasonable to fix it _for the future_. Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and _always_ rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility be resolved before the random data becomes available. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor RFP Review Request
On Tuesday, July 25, 2006 04:24:01 PM -0400 John C Klensin [EMAIL PROTECTED] wrote: So I'd like to suggest that 2.e be changed a little bit: OLD: Submit document to IESG for review of conflicts or confusion with IETF process, end runs around working group activities, and obvious and significant harm to the Internet NEW: As required by RFC 2026, submit document to IESG for review of conflicts or confusion with IETF process, end runs around working group activities, and obvious and significant harm to the Internet This change is counter to RFC 3932, which is claimed to have removed harm from the things that the IESG will consider. Reinstating that criterion in this RFP seems completely inappropriate. While I'm not sure I entirely agree with the complete removal of harm to the Internet as something the IESG will consider, RFC3932 does in fact do that, and I agree it would be inappropriate to reintroduce it here. However, I should point out that that's not the effect of the proposed change - the language about harm was already in there. I would suggest that neither this RFP nor any eventual contract for the RFC-Editor function should specify exactly what the IESG will or will not review for. Instead, it should spell out what rights and responsibilities the various entities have; specifically - the responsibility to send the document to the IESG for review - the responsibility of the IESG to respond within a particular time - the right of the RFC-Editor to publish - the right of the IESG to require inclusion of an IESG note h. Coordination with Other Document Streams 1) Coordination with and prioritization of other document streams is the prerogative of the IAB I'm assuming that h.1 is not intended to cover the document differentiation issue, but in any event, it would not do it well. The IESG and the BCP-approving community hasn't finished discussing (by approving a changed BCP) a view that the IAB is now arbiter of the IETF's public messaging on independent RFCs. Nor has the broader community agreed that the IESG (which is more or less the same entity as the BCP-approving community) has the authority to do this. I think BCP-approving community was intended to include the IETF as a whole. Without making any comment on who has the power to do what, it seems prudent for the RFP to avoid painting itself into a corner. Due to independent RFC's potential close involvement with working group RFCs, there are reasons for WG folks to really think about this. I don't think there's any intention to affect a standards-related issue by placing language in the RFP/contract, but we should really watch that we do not. But, if parts of this RFP evolve to assert that the RFC Editor function is under IESG control for non-IETF documents, or that the IESG can set rules for how non-IETF documents are handled without the consent of the RFC Editor, then we have a problem. Why? If ISOC is funding this thing, then it gets to have some say in its operation. Exactly how much autonomy the RFC-Editor has and in what areas is ultimately a matter for mutual agreement between ISOC and whoever ends up providing that function. The vehicle for expression of that agreement is a contract, and the RFP is nothing more than a means for finding people who might be interested in such a contract. The question of whether it's the IESG or the IAB or some other group that gets to set the rules for publication is effectively just determining who will drive ISOC's decisions regarding the functioning of the RFC-Editor, once an agreement is in place. Now, you might argue that the RFC-Editor should have some level of authority to publish documents on its own, or to make rules about how document publication should work, or to be consulted in the making of those rules, and I might even agree with you. But if the IETF decides it doesn't want that, I don't see how that is a problem -- a relationship in which I pay you to perform some service in the way I specify, and not in some other way, is perfectly normal. You might also argue that even if ISOC gets some say in how the RFC-Editor function is performed as long as it is funding it, and has the right to stop funding it, ISOC (and by extension, the IETF) doesn't have the right to hire someone else to be RFC-Editor. If I understand correctly, this is the question you don't want to put in the critical path of this RFP. Unfortunately, I think this is something that must be resolved before the process goes too far. I'd hate to see people's decisions affected by concerns over what might happen if ISI doesn't get the contract. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list
Re: Flaw in the NOTEWell System makes NOTEWELL NOTWELL
On Tuesday, July 25, 2006 03:44:21 PM -0700 todd glassey [EMAIL PROTECTED] wrote: Hi there Audit Fans - Lets look at NoteWell and figure out how it interacts with Corporate Governance and Compliance Policies... First of all, you keep using the word NOTEWELL as if it is the name of something. Perhaps a policy, or a system, or a process, or a body of documents, or ... I don't know. But the IETF has no process or body of material which it calls NOTEWELL or NoteWell or anything like that. The admonition Note Well appears above a one-page notice which is distributed to all participants at IETF meetings, published on the IETF web site, and so on. That page reminds people that the IETF has certain rules requiring contributions made to its process and the responsibilities of people making those contributions, and that anything you say in places like an IETF meeting or mailing list is subject to those rules. 2) The IETF however claims that any Email sent to it in any form constitutes NOTEWELL and becomes its property. The problem is that it has no agreements with the other email provider to make that true. As I explained above, there is no body of documents or process or whatever called NOTEWELL, so there is nothing that constitutes NOTEWELL. I think the phrase you are looking for here is is subject to the terms of BCP 78 and BCP 79. The IETF does not claim that any email or other contributions sent to it become its property. In fact, IETF contributions remain the property of the contributor, with the IETF gaining only certain non-exclusive rights which it needs in order to carry out its mission. For someone who contributes material that belongs to his employer, it is up to him to insure he is authorized to do so, just as it is up to him to make sure the material he wants to contribute is not confidential before posting it to a public mailing list. Interestingly, many other SDO's do _not_ work this way. Their members are typically companies, not individuals, and those members are required to pay a fee and sign a contract, one of whose terms is that any contributions made to the standards process are works for hire, belonging to the SDO. So who actually owns the IP? Whoever owned it to begin with. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by [...]
On Thursday, July 20, 2006 01:04:39 PM -0500 Pete Resnick [EMAIL PROTECTED] wrote: On 7/19/06 at 9:02 AM -0400, Thomas Narten wrote: ...it makes no sense to appeal to ISOC that the process itself was unfair and has failed to produce a proper result, if there wasn't first an appeal on actual substance that didn't result in the appropriate outcome. But, technically, I would not expect the appeal to the IESG/IAB and the one to the ISOC to be exactly the same. In the former case, the appeal is presumably on actual decisions and actions made in WGs, by the IESG, etc. In the latter case, the argument is much more about the process itself (and how it failed to protect the rights of all parties in a fair and open Internet Standards Process as indicated in 2026) and is less focussed on the details that led to the original appeal. On this we might agree (though I think this is something different than what Brian and Sam are saying): You can read Further recourse... to mean that you can't appeal a process on the grounds of fairness unless you have been affected by that process. But I think we also agree that you don't bring the question of fairness of the process to IESG/IAB, but straight to ISOC: The appeal you bring to the IESG/IAB is different from the one you bring to ISOC. On 7/20/06 at 11:12 AM -0400, Sam Hartman wrote: Having read 6.5 in its entirety multiple times, I agree with Brian's reading not yours. OK, for the sake of argument let's assume that we read it like you and Brian. Let's ask some questions: If I think that the way technical choices are made in a WG is unfair, do I bring that to the WG chair to adjudicate first? That's what I would do under 6.5.1. Or, since it is a procedural question, do I bring it straight to the IESG chair as 6.5.2 requires me to do? Do WG process questions (as defined in 6.5.1) go to the IESG chair (as defined in 6.5.2)? No, not while they're still questions. The section you are reading describes the appeals process; it doesn't come into play until there is something to appeal _and_ you feel it's worth doing so. For example, if you don't like what's going on in a working group, you can take your issues to the chair, or to the responsible AD. If the problem is that you think the chair has made a specific decision in which process was violated and which resulted in a bad outcome, you can appeal that. If the problem is that you think the chair is abusing process and that a bad outcome might result, you can go to the responsible AD and ask them to tell the chair to shape up or be removed. But that's not part of the appeals process; it's management. I can't figure out how to read the the first paragraph of 6.5.1 (especially the last sentence) and the first paragraph of 6.5.2 and come up with an explanation where the procedures for 6.5.1, 6.5.2 and 6.5.3 are tied to each other. They are independently run processes. And nowhere in the process of 6.5.3 is there mention of bringing it to the IESG or IAB. I think the problem comes from assuming that because 6.5.1 and 6.5.2 are clearly separate paths, then 6.5.3 must also be a separate path, rather than a follow-on to 6.5.2. The document is structured rather confusingly, but I've always read it Brian's way, too. And, I don't see any harm in having something go through the lower levels first, particularly since the usual case is that someone doesn't like a decision, appeals it, and then doesn't like the way the appeal was handled. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by [...]
On Thursday, July 20, 2006 11:02:23 AM -0700 todd glassey [EMAIL PROTECTED] wrote: By the way - why would the IETF figure that something it wrote in IPR or Network or any other WG would be legally binding on ISOC and its BOT??? Heh. Network isn't an IETF working group; the phrase Network Working Group at the top of RFC's is a historical nod to the group that started the series. In this particular case, we expect the appeals process to be binding upon ISOC and it's board because it was approved by that board, as all IETF process documents must be. Before you start spouting audit-speak at us and quoting practices which were not intended for an organization like the IETF and are not relevant to it, you could at least do your homework. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: questions about Dallas money
On Wednesday, July 12, 2006 06:09:42 PM -0400 Michael Richardson [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 $177/person for FB. So, if I put $20 of looneys in my pocket each day ... your pocket would be pretty heavy. Since water, soda, and cookies are all going to be $2 each anyway, you'd save a lot of weight by using slightly larger coins. Or do the vending machines not take those yet? -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On Monday, July 17, 2006 10:11:07 AM -0400 Jeffrey Altman [EMAIL PROTECTED] wrote: For me Paris and Montreal were the two worst meetings I have experienced in ten years because of the separation of the IETF hotel from the meeting locations and the in ability to provide network access in the hotel public spaces. My productivity dropped significantly because of those failures. While I agree with most of what Jeff said, I have to comment on this. I agree that having the hotel separated from the meeting locations is a significant issue, both because of the extra time required to travel between locations, and because of the lack of network connectivity. I actually found Vienna worse for this than either Paris or Montreal, because people were scattered across many hotels, often several blocks away from the meeting site. However, the conference centers in both Paris and Montreal had excellent meeting facilities. The network last week was fabulous, and as Jeff pointed out in a message to the WG chairs list, Paris was where we first discovered the utility of having a few extra wireless mics for supporting round-table discussion. The best IETF meetings from my perspective are those held in Minneapolis. The hotel understands what we need. The lounge and bar areas are smoke free and plentiful. There is accessible food via the habitrails. Things just work. I strongly agree. We've been away from Minneapolis for too long. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On Saturday, July 15, 2006 05:24:45 AM -0400 Fred Baker [EMAIL PROTECTED] wrote: Thanks. gee whiz, that was a bunch of work for me. You had a tool? arg... It's best to always ask Henrik and/or Bill if they have a tool. Often they do, and if not, it may take less time to produce it than it would take one of us to realize we need it. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On Monday, July 17, 2006 06:46:11 AM -0700 Andy Bierman [EMAIL PROTECTED] wrote: - I didn't find a terminal room, but instead a giant 'break room' for ad-hoc meetings and food breaks. This was wonderful, and about time! 802.11 has thankfully made the terminal room obsolete. I want this format every time. Please consider 2 enhancements: - A/C around the perimeter for laptop power - beverages available (at least pitchers of water) all day There actually was a terminal room, hidden around the corner to the left as you walked away from registration. I went there exactly twice, to pick up printouts for the PGP session (once would have been nice, but my laptop crashed and I was late for a meeting, so had to go back afterward). I definitely agree that the all-day cookie room was a great idea, and I'd very much like to see this sort of thing again. It could do with a few more tables and power than we had this time, and an all-day supply of water or beverages would be good, too. Of course, the potential negative aspect is that folks who aren't attenting the session right before a cookie break can camp out and grab cookies right as they arrive. But, that can happen anywhere... -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On Tuesday, July 18, 2006 12:03:34 AM +0100 Tim Chown [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 11:38:15AM -0400, Stephen Campbell wrote: Or skip the car. Fly into LAX, take one of several shuttles to Los Angeles Union Station, and take Amtrak's Surfliner to San Diego. These trains run every 1 to 2 hours and get to San Diego in less than 3 hours. And it's hassle-free. Not so good after 9+ hours on a plane though, is it? Nor is driving. Actually, it's pretty nice. The seats are nicely spaced, there's plentiful power, beverages, and you can get up and walk around. Of course, my opinions on this matter might be a bit biased. For example, I see no reason to fly to LAX and take a shuttle to Los Angeles Union Station when it takes a mere two days to get there by rail from Chicago Union Station. :-) -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Minutes and jabber logs
On Tuesday, July 18, 2006 12:14:00 PM +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: if the minutes are properly written, it's enough to ask for agreement on the minutes. Yes, but you have to be careful. Many organizations follow a practice in which the members approve the minutes of each meeting sometime after the meeting (often, at the next meeting). But this approval is merely agreement that the minutes are an accurate representation of what happened at the meeting. In the IETF, it's not good enough for the mailing list to agree that the minutes are _accurate_. They also need to agree with the decisions recorded therein. Still, your point is well taken. Raw jabber logs certainly do not constitute minutes. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
On Thursday, July 06, 2006 10:45:52 AM -0400 Bill Fenner [EMAIL PROTECTED] wrote: It looks like 3 out of 4 data channel establishment mechanisms are broken with this FTP server software and configuration for IPv4. I didn't test with IPv6. I did, inadvertently. PASV worked, as did at least one of PORT and EPSV. I didn't try EPRT. My guess is that there's some _thing_ in the IPv4 path that is breaking things because it doesn't like PORT and doesn't support the extended modes, either because it's too old or too broken. This is one of the reasons for both the layered network model and the end-to-end principle -- avoiding the need for devices in the middle of the network to understand application protocols not only makes it easier to deploy new applications, but also reduces the chances that some device you have no control over will break the applications you already have. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF IPv6 platform configuration
On Wednesday, July 05, 2006 12:53:59 PM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Agh, replied to the wrong message there in case it was not obvious. I was not suggesting using the subway in the hotel as an IPv6 platform. -Original Message- From: Hallam-Baker, Phillip Sent: Wednesday, July 05, 2006 3:52 PM To: 'Ken Raeburn'; ietf Mailing List Cc: [EMAIL PROTECTED] Subject: RE: IETF IPv6 platform configuration If memory serves me right there is a subway terminal built into the foundation of the Delta International. Where the other end of the subway goes is another matter. I recently looked into the subway situation in Montreal. The Palais des Congress, the Delta, and the main rail station are consecutive subway stops on the same line. They all also appear to be connected by underground tunnels; in fact, it's unclear to me whether using the subway would actually be shorter or faster than walking. IIRC, there is a bus terminal across the street from the rail station. I have no idea if this is the right terminal for people coming in from the airport. Myself, I plan to arrive by rail. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)
On Wednesday, June 28, 2006 09:45:27 AM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I do not think it would be a good thing to make it an inviolate rule that a chair can never be an editor. Nor do I. I do think that there should be a fixed rule prohibiting members of the IESG being WG chairs. I would also include the IETF chair in this. I don't. While I agree this should be a rare occurrance, I have seen no evidence of a problem that such a rule would be intended to address. If it's not broken, why spend time trying to fix it? The position at BOFs is rather different. It is usually helpful to have someone experienced in IETF process to chair a BOF and often the best person to do that is someone who is not directly associated with the actual proposal. I agree. In addition, I would note that while a BOF chair does have the same logistical responsibilities as a WG chair in terms of making the meeting happen, they are not necessarily making a long-term commitment to the proposed work. Of course, many BOF chairs are already active with the proposal, but that's not a requirement and, as you note, may actually not be the best way to run a BOF. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)
On Monday, June 26, 2006 11:24:55 AM -0400 Keith Moore moore@cs.utk.edu wrote: Perhaps requirements documents should be more like rationale documents: we chose to solve this problem in this way because of this... In general we need to discourage the meme requirements documents. No, we don't. We just need to discourage the practice of waiting to write such a document until after protocol design is complete, rather than doing it first. need problem definition documents and design goal documents from the early phases of the process Yes, absolutely. That's what a requirements document is supposed to be. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA SLA Input Sought
On Monday, June 26, 2006 04:22:57 PM -0400 IETF Administrative Director [EMAIL PROTECTED] wrote: The IAOC is negotiating a service level agreement with ICANN/IANA for services it performs on behalf of the IETF. The SLA supplements the MOU executed by ICANN and the IETF in 2000. Who does or will pay for the IANA function? Does funding come from IASA, ICANN, or some other source? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)
On Friday, June 23, 2006 05:24:11 PM -0400 Keith Moore moore@cs.utk.edu wrote: On Fri, 23 Jun 2006 16:18:40 -0400 Burger, Eric [EMAIL PROTECTED] wrote: I would offer that in *some* groups the running code bar is reasonable. I would have little objection to requiring running code as a test of feasibility of a new idea. I would object strongly to an argument that just because someone has running code, means it's a good indication of adequacy of the protocol. Specific examples aside, I agree. Running code should be a necessary condition for something to progress, but not a sufficient one. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
