Re: RPS Accessibility
Could be an app that put you in the queue and used your laptop/tablet/smartphone microphone to get the audio. On Tuesday, August 6, 2013, Michael Richardson wrote: Dave Crocker d...@dcrocker.net javascript:; wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. +1. And move the microphones to the people, rather than the other way around. We can easily have three or four microphones that can play leap-frog around the room. -- Michael Richardson mcr+i...@sandelman.ca javascript:;, Sandelman Software Works
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Following a request to look at this document, and with only a cursory look at the archives, I'm confused. The note is always intended to be included in the document itself, right? Is this change designed to compel, as opposed to request, the RFC Editor to include the note? If the answer to those is yes, then I support the change. The RFC Editor is not selected to make judgments on whether a note from the IESG should, or should not be included in a document. It's not an editorial judgment, it's is a technical concern. However, I think some form of appeal is needed, perhaps to the IAB, that would allow authors some measure of control of what goes in their document. Brian On 8/31/09 9:29 AM, Jari Arkko jari.ar...@piuha.net wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Yes, I understand, this only applies to the Independent Submission stream. We ask the IESG to review these documents, and that review is technical. I don't think it is appropriate for an editor to make a judgment of whether a technical note is, or is not appropriate to be included in a document. I think the presumption should be that it is appropriate, and the authors have a way to object. While I understand the role of the ISE is somewhat different from the RFC Editor, I understand the role to be primarily editorial and we are not choosing the ISE with regard to their ability to make judgments like whether the IESG note is appropriate or not. I think it would be okay to have the note go through an IETF consensus call. Brian On 8/31/09 11:25 AM, John C Klensin john-i...@jck.com wrote: Brian, Remember that 3932bis applies to the Independent Submission stream, not to IETF documents of any flavor. These are, in general, documents that have not been formally reviewed in the IETF (although many of them have been extensively discussed). They are not IETF Stream documents, about which, subject to push-back from WGs and the community, the IESG can do pretty much as it likes. For these documents, there is no IETF Last Call. If the IESG creates a note, that note reflects the individual judgments of the ADs (and presumably IESG review and approval of those judgments) and not the rough consensus of the IETF community. Given that, while it may be a technical concern (or at least reflective of a technical preference), it is a concern from (at most) a group of individuals who happen to be on the IESG; there is no requirement that it represent a technical concern from the IETF community. In that context, what you are really asking for is that the preferences or concerns of that group of individuals -- preferences that they could not get the RFC Editor or document authors to accept through normal review channels -- override the decision-making process and approval of a non-IETF stream. Especially since we expect documents in the Independent Submission stream that would carefully criticize or provide alternatives to IETF-approved approaches (see RFC 4846), giving the IESG that much authority, especially without consulting the IETF Community and determining consensus, does not seem sensible or consistent to me. Indeed, it seems like a mechanism for permitting only authorized dissent. ... YMMD. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
I like this thought quite a bit. I see the RFID thing as being a good idea in concept, and we need to work through how to use it most effectively. In this specific case, I think we treat the tag as an identifier, and allow the user to decide what the data associated with this identifier should be. After all, you can write whatever you please on the blue sheets. I personally would not have a problem if the name was immutable, but I could see giving up on that. Suppose there was a website where you could, either before, during, or after the event, indicate, per session, what you want on the electronic blue sheet. The swipe was the token that enabled the content of the website data to be copied. Establish a time limit (5 days after the session maybe) to freeze the content, do the mapping, and delete the website data. Brian On 8/31/09 12:56 PM, Steve Crocker st...@shinkuro.com wrote: I won't be in Hiroshima and won't be able to participate nor will I be able to opt-out, so I don't have a personal stake in this and am commenting only as an interested observer. As has been noted, this won't be an absolutely clean, seamless replacement of the blue sheets. The list of possible downsides is already growing, e.g. privacy issues, inflexibility in choosing which email address to use for each working group, and I won't be surprised if the list grows a bit. At the same time, the list of possible new capabilities is also growing, e.g. identifying the speaking at the microphone. This sort of discussion is similar to other settings that are introducing electronic versions of previously manual processes, e.g. in the health care industry. Let me offer a point of view and a suggestion. Point of view: Rather than thinking of the RFID chips as serving to be simply a direct replacement of the blue sheets, take as a given that this will be a new and somewhat different technical foundation with some positives and some negatives. The blue sheets also had positives and negatives, e.g. the cost and pain of storing them, the difficulty and cost of reading them, their legal status and retention policy, etc. Look at the RFID chips from a fresh perspective, not solely as an automation of the blue sheets. Suggestion: As noted above, similar issues apply in other settings. This community has an opportunity to tackle the interplay of technology and social policy issues that affect itself far more cogently and efficiently than most communities do. Let's grasp the nettles and see if we can work through the issues in a sensible and rational way. Do we need a privacy policy regarding the information collected? If so, let's create one. Do we need access controls on the information? If so, let's create them. Do we need an ability to edit information that's been collected if it's inaccurate? If so, let's build it. Do we need more flexibility in the information stored in the record, e.g. a distinct email address for each working group? If so, let's add it. Steve On Aug 31, 2009, at 12:27 PM, Paul Hoffman wrote: At 5:55 AM -0700 8/31/09, Alexa Morris wrote: The data collected consist solely of an individuals full name and company/organization affiliation. We are not collecting email address information on the e-blue sheets. Please note that you are now also collecting information that *is not* on the current blue sheets, namely company/organization affiliation. I have noted that some people I know who have signed a blue sheet before me have used personal email addresses while (I assume) their badge lists their actual company/organization affiliation. As a person with multiple company/organization affiliations, I sometimes change the email address I put on the blue sheets to be the one most appropriate to the topic of the WG. It is a bad idea to have this experiment create combined blue sheets that have data that differs depending on the collection method. There are probably a dozen WGs in the IETF who have had this problem come back and bite them on their collective backsides during protocol development or, unfortunately, after their protocols have deployed. Please strongly consider having the readers record exactly what the current blue sheets record, or change the blue sheets to record what the readers are recording for this meeting. The first of these two will most likely cause less revolt. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [XCON] Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
Minor nit on the last part: When the keys are randomly generated and of sufficient length, these attacks do not obtain obtain doesn't work. Either do not succeed or generally do not succeed or even usually fail. Brian -Original Message- From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] Sent: Sunday, June 17, 2007 5:52 AM To: [EMAIL PROTECTED] Cc: Cullen Jennings; [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] Subject: [XCON] Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 Hi David, thanks for your comments. Answers inline: [EMAIL PROTECTED] wrote: I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. This is a relatively straightforward draft about how a client opens a TCP connection to a BFCP server when it has the server's transport address information. Section 3 ventures into the area of IP address selection - it references RFC 3484 (which is good) and then goes on to make additional comments and recommendations on usage and state of deployment of the techniques specified in RFC 3484. While there's nothing technically wrong with this text, the additional comments and recommendations are not specific to BFCP, and may belong in a more generic document. Given that such a generic document does not exist, we need to give these recommendations here. Section 4 starts with All BFCP entities implement TLS ... That is correct, as RFC 4582 requires this, but it would be better to cite RFC 4582 as part of this statement, e.g., [RFC 4582] requires that all BFCP entities implement TLS ... What about performing the following change? OLD: All BFCP entities implement TLS [7] and SHOULD use it in all their connections. NEW: [RFC 4582] requires that all BFCP entities implement TLS and recommends that they use it in all their connections. In the second paragraph of Section 4, I would change can request the use of TLS to SHOULD request the use of TLS. OK, I will fix it. Section 5.1 specifies that SubjectAltName identities in certificates are to be preferred to Subject identities. Is this specific to BFCP or more general? We got that recommendation from our security adviser. I do not know whether this will be documented in a generic document at some point. The following text appears to be an oversight: If the client knows the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client. The client *always* knows the server's IP address (e.g., DNS returns it). I think the intended case here is that the client contacts the server using the server's IP address and as a result does not know the server's hostname. Rephrasing in that sort of fashion would also express a preference for hostname as certificate identity, which I believe is desirable. What about performing the following change?: OLD: If the client knows the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client. NEW: If the client does not know the server's hostname and contacts the server directly using the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client. Section 6 disturbingly shifts between password and pre-shared key and appears to get a few things wrong in the process. To begin with, the statement that TLS PSK mode is subject to offline dictionary attacks. is false when the PSK is high-entropy. OTOH, it is correct when the PSK is low-entropy (e.g., a password, or derived from a password without introduction of additional entropy). The discussion in Section 7.2 of RFC 4279 applies, especially the last paragraph about PSK generation. The section needs to be carefully revised to distinguish between password and pre-shared key, especially given the mention of use of PBKDF2 to generate the latter from the former. what about performing the following change?: OLD: TLS PSK mode is subject to offline dictionary attacks. In DHE and RSA modes, an attacker who can mount a single man-in-the-middle attack on a client/server pair can then mount a dictionary attack on the password. In modes without DHE or RSA, an attacker who can record communications between a client/server pair can mount a dictionary attack on the password. Accordingly, it is RECOMMENDED that where possible clients use certificate-based server authentication ciphersuites with PSK in order to defend
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
On most devices of interest, this is a non issue; they are small embedded devices, like phones. For other situations, for example a sip softclient running on a laptop, we will specify an api on the O/S the application is running. The api will front end a set of Location Configuration Protocols of which DHCP is one. Brian -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 9:50 AM To: John Schnizlein; David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums But how does my application access it? DHCP is not something that an application layer program should be allowed to perform. It is a security issue. For good reason performing DHCP operations requires privileges beyond mere network connectivity on Windows. That is why configuring application programs from DHCP never caught on. -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Sunday, April 22, 2007 6:41 PM To: David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums The reason that DHCP is appropriate for information about the location of the host is that the scope of DHCP administration usually does match the local network to which the host is attached. Location is local information. John On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote: The point is that the ISO L(x) is not what one considers when judging wether or not a certain configuration value would make a good band name. I mean DHCP option. What we (strive to) consider instead is the administrative scope of the configuration information, and wether it matches common and practical use of DHCP. On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote: On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: DHCP is a layer 3 technology that talks directly to layer 2. DHCP is a technology that dynamically configures hosts. If a host has a configuration knob that might reasonably and properly be set by the systems administrator or the network you are presently attached to, then it is reasonable and proper to configure it via DHCP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Sorry, bad choice of words. I'm not sure, but almost certainly not IETF. IETF doesn't do apis. I'm trying to get MS+Apple+Linux and maybe some embedded OS folks to agree to have a common api. I don't know if that will work yet. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 4:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian, we will specify an api on the O/S the application is running Who is we, geopriv? Guy Caron -Message d'origine- De : Brian Rosen [mailto:[EMAIL PROTECTED] Envoyé : 25 avril 2007 14:29 À : 'Hallam-Baker, Phillip'; 'John Schnizlein'; 'David W. Hankins' Cc : 'GEOPRIV WG'; ietf@ietf.org Objet : RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums On most devices of interest, this is a non issue; they are small embedded devices, like phones. For other situations, for example a sip softclient running on a laptop, we will specify an api on the O/S the application is running. The api will front end a set of Location Configuration Protocols of which DHCP is one. Brian -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 9:50 AM To: John Schnizlein; David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums But how does my application access it? DHCP is not something that an application layer program should be allowed to perform. It is a security issue. For good reason performing DHCP operations requires privileges beyond mere network connectivity on Windows. That is why configuring application programs from DHCP never caught on. -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Sunday, April 22, 2007 6:41 PM To: David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums The reason that DHCP is appropriate for information about the location of the host is that the scope of DHCP administration usually does match the local network to which the host is attached. Location is local information. John On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote: The point is that the ISO L(x) is not what one considers when judging wether or not a certain configuration value would make a good band name. I mean DHCP option. What we (strive to) consider instead is the administrative scope of the configuration information, and wether it matches common and practical use of DHCP. On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote: On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: DHCP is a layer 3 technology that talks directly to layer 2. DHCP is a technology that dynamically configures hosts. If a host has a configuration knob that might reasonably and properly be set by the systems administrator or the network you are presently attached to, then it is reasonable and proper to configure it via DHCP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Geopriv mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/geopriv ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Agree that 3825 doesn't have the ability to express uncertainty and confidence. I don't wish to enhance it to do so at this time. However, a triangulated WiFi location may have sufficiently low uncertainty that it could be used for many purposes, including emergency calling, without reporting what the actual uncertainty was. In order to actually be useful if the endpoint was mobile, the endpoint would have to implement a location update, since only it can requery DHCP to get a new location. The device that does the triangulation may not be connected to the DHCP infrastructure. In these circumstances, HELD may be a better choice Also, the most common initial deployments of WiFi will be that the clients of an AP are given the location of the AP they are connected to as their location, and that will often be civic. RFC4776 would work well there. I expect that will be a very common deployment model. Brian -Original Message- From: Dawson, Martin [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 9:03 AM To: Brian E Carpenter; Hannes Tschofenig Cc: Brian Rosen; GEOPRIV WG; ietf@ietf.org; Allison Mankin; John Schnizlein Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 3825 can actually only represent uncertainty to the extent that it can be conveyed by precision. This makes it unsuitable for the sort of arbitrary uncertainty around arbitrary location values you refer to. Cheers, Martin -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Friday, 20 April 2007 10:59 PM To: Hannes Tschofenig Cc: Brian Rosen; 'GEOPRIV WG'; Dawson, Martin; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums On 2007-04-20 09:21, Hannes Tschofenig wrote: DHCP is not a great choice in a mobile environment and also not when it comes to more complex location representations. Why can't a mobile system have a locally valid DHCP record (+/- the length of a wireless link)? For that matter, why couldn't a DHCP server have real-time triangulation data, if it exists at all? Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 together? Brian -- -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -- -- [mf2] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
The cable systems use the MAC address of the DOCSIS modem to determine which subscriber is asking for location. It's not perfect, because it is possible to move a DOCSIS cablemodem from one house to another within some area (often the service area of the CMTS, but in many systems, less than that). The ability to move without detection is a problem the have for other revenue sources and there is some effort being put into systems to detect that kind of thing. The incidence of moving the cablemodem without notice is apparently very small. You don't get the location of the server, you get the location of the client. Brian -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 9:39 AM To: Brian E Carpenter Cc: 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian E Carpenter wrote: On 2007-04-20 09:21, Hannes Tschofenig wrote: DHCP is not a great choice in a mobile environment and also not when it comes to more complex location representations. Why can't a mobile system have a locally valid DHCP record (+/- the length of a wireless link)? For that matter, why couldn't a DHCP server have real-time triangulation data, if it exists at all? Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 together? If you look at DOCSIS cable, a single head end can subtend a huge amount of cable in a single bridged domain. I seem to recall that in a rural Canadian MSO I worked with it was 10's if not 100's of miles. I have no clue how accurate GEOPRIV tries to be, but it sure seems that if the location of the headend/dhcp relay is only piece of information you have, your accuracy is going to be pretty lousy in many cases. If this information is intended for first responders, it seems that all you're doing is pointing to the right haystack to start searching for the needle. Mike, who probably shouldn't open his mouth here ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Yup. There are no mechanisms that work when the Pringles cans come out other than actual endpoint measuring mechanisms (like GPS), which have their own limitations. The standards recommend methods for users to override the automatic mechanisms when they do things like Pringle can extensions. There are a set of security issues on THAT, but it's still a workable notion. The Cablelabs guys and individual MSOs have looked at this, and most believe they can deploy a DHCP based location infrastructure that works pretty well. The pretty part is mostly the problem of cablemodem moving. Nothing is perfect, nor does it need to be. I think it's good enough, although I'd really like them to be advancing on detecting cablemodem moves. At least that error source is a deliberate user action which is really already prohibited by contract. This whole area is complex because there isn't anything that works always. There have to be options, both for access network operators, device manufacturers and even end users to deal with all the variations in reality that occur. And again, nothing is going to be perfect. Brian -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 10:14 AM To: Brian Rosen Cc: 'Brian E Carpenter'; 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian Rosen wrote: The cable systems use the MAC address of the DOCSIS modem to determine which subscriber is asking for location. It's not perfect, because it is possible to move a DOCSIS cablemodem from one house to another within some area (often the service area of the CMTS, but in many systems, less than that). The ability to move without detection is a problem the have for other revenue sources and there is some effort being put into systems to detect that kind of thing. The incidence of moving the cablemodem without notice is apparently very small. You don't get the location of the server, you get the location of the client. That's only because there's an out of band arrangement with the MSO and the subscriber. DHCP itself gives no such information. Wireless substantially confuses the matter too. All it takes is two Pringle's cans to cast that relationship in doubt. Mike Brian -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 9:39 AM To: Brian E Carpenter Cc: 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian E Carpenter wrote: On 2007-04-20 09:21, Hannes Tschofenig wrote: DHCP is not a great choice in a mobile environment and also not when it comes to more complex location representations. Why can't a mobile system have a locally valid DHCP record (+/- the length of a wireless link)? For that matter, why couldn't a DHCP server have real-time triangulation data, if it exists at all? Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 together? If you look at DOCSIS cable, a single head end can subtend a huge amount of cable in a single bridged domain. I seem to recall that in a rural Canadian MSO I worked with it was 10's if not 100's of miles. I have no clue how accurate GEOPRIV tries to be, but it sure seems that if the location of the headend/dhcp relay is only piece of information you have, your accuracy is going to be pretty lousy in many cases. If this information is intended for first responders, it seems that all you're doing is pointing to the right haystack to start searching for the needle. Mike, who probably shouldn't open his mouth here ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
In the example you gave the Hilton is EXACTLY the network that MUST give you your location, and Verisign, if they tried, would give a valid, but very wrong location. That is the point of using DHCP for location, you need the closest possible server to get the right location. You need a server that understands the L2 to which you are connected. Anything L3 and farther has a big problem of where, exactly, are you? The proposals for L7 versions of location configuration protocols suffer mightily from the problem of figuring out where you are in the L2. They have to go to great lengths to determine some kind of identifier that they can unambiguously use to figure that out. I think we have (painfully) figured out a way though that morass that will work in enough circumstances to be interesting, but it remains hard, very hard, to identify the L2 when your server is sitting at L7. So, make sure that when you go to the Hilton that you use it's location server, or you may have a big problem if you have to make an emergency call (or even order a pizza). DHCP is an excellent choice for a location server for networks where the DHCP infrastructure is present, and can reasonably be upgraded. The L7 guys point out, correctly, that that's a tall order in a lot of interesting networks. I think that is right. I do think they believe L7 works on every network. I'm certain it doesn't. That's why the compromise of BOTH is probably required. I know it's the only way we are going to get anything done in the next year. Brian -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 6:39 PM To: James M. Polk; Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums DHCP is a layer 3 technology that talks directly to layer 2. This is entirely acceptable, useful and right for NETWORK configuration. DHCP is an entirely sensible means of obtaining an IP address and _proposals_ for domain name prefixes and DNS servers. DHCP should not be used for any other purpose. In particular to make use of DHCP for application configuration is a layer violation. Layer 7 should NEVER communicate with Layer 2 directly. When that happens we lose all the power and flexibility built into the IP stack. To give a concrete example of the problems caused. I am currently typing on a VeriSign machine in an office in VeriSign corporate HQ. In that environment the local DHCP server could provide me with useful and valid suggestions for all manner of services. But its still the wrong technology. The problem is that when I take the machine to the Hilton Garden Inn down the road where I am staying I explicitly DO NOT want the hotel network to provide any more than an IP address. I am not going to use their DNS server and I certainly don't want to make use of any email server, DNS prefix, GEOPRV or any other application layer feature they might want to foist onto me. I am using the Hilton Garden Inn LAN, I am not joining their network. The machine is remaining on the VeriSign network. DHCP is a fine technology for the task DHCP is designed to do. It is an inappropriate technology for application or service configuration. The proper infrastructure to support those needs is DNS, supplemented if necessary by HTTP or LDAP backing store (i.e. either discover the services via DNS directly or use DNS to discover where the directory service is to be found). Looking at the history of UPnP and Zero Config it strikes me that attempting to manage networks through peer to peer broadcast or multicast have been a bust precisely because of this layer violation. -Original Message- From: James M. Polk [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 5:31 PM To: Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums At 04:20 PM 4/19/2007, Dawson, Martin wrote: DHCP is not adequate because it doesn't meet multiple sets of requirements as documented multiple times ... bologna documented multiple times means in individual submissions of which, zero facts were presented to substantiate If DHCP were so inadequate, why is the DSL forum now going to specify it? Why does PacketCable define it? These were fairly recent moves... And, how many times has HELD been presented as if it were a product of an IETF WG? James ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org
RE: IM and Presence history
However, what this subthread demonstrates is that they were conceptually an incremental change, not a giant, discontinuous, intellectual leap. I thought we all knew that. Oh, I agree, we knew that. There are very, very few discontinuous intellectual leaps in our part of the universe. It's hard to name one that happened in the past decade or two. Can we name any discontinuous intellectual leaps of late in computer networking? Now that I think about it, forget of late, have there EVER been any? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IM and Presence history
If you squint hard enough, everything has already been invented. Telegraph operators had a form of presence if you squint hard enough. Presence is a continuously updated 'display' of a set of other people's status. Finger didn't do that. Yeah, you COULD have used the mechanism to implement a form of presence, but I don't remember anyone ever doing that, and if they did, it didn't make anyone sit up and take notice like the IM folk's buddy status systems did. They invented presence, as we know it, and of course it's not entirely new, but then again, little else is. Finger had antecedents in various time sharing systems versions of who is logged in mechanisms. They in turn had predecessors in various user id logging mechanisms on batch systems. I recall being able to determine who was in the CMU Comp Center by looking at a fairly often posted list of batch runs made for the 1108, and the G20 graphics systems certainly had mechanisms to know who was on the other displays way before I got there. Sending real time messages to users logged in is almost as old. The G20 graphics systems had such facilities. Every time sharing system did, and of course, the telegraph operators had a similar facility. They aren't IM. Brian -Original Message- From: Dave Crocker [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 11:01 AM To: John C Klensin Cc: ietf@ietf.org Subject: Re: IM and Presence history John C Klensin wrote: Yes. I wanted to keep the note from becoming even longer, but... ack. figured that, but found myself compelled that the history lesson was useful for the record. If I came in through an arpanet dial-up at some random place on the net, and telneted to my home system, then the finger for that home system would show me as 'present'. I am not seeing how today's presence systems are fudamentally different from that. Subjectively and from my perspective, the present systems feel, and sometimes actually are, much more distributed. But, yes, from the perspective you describe, we have advanced very little in terms of basic functionality. I believe that none of the proprietary IMs is anything other than purely centralized. Having to configure multiple IM accounts, to be able to talk to different people, doesn't feel at all 'distributed' to me, except in the bad sense of multiple, disconnected, centralized services. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Meetings in other regions
It may have changed, but when Marconi sponsored an IETF, the budget was about $250K for the network, terminal room, help desk, hospitality desk, t-shirts and the difference between expense and receipts for the social (hint: most socials cost more than the $25-30 that is charged). No equipment was bought (it was all borrowed from Marconi or other sponsors). I think we went over the budget. I am told most non U.S. meeting sponsorship costs are significantly higher, but I have no direct knowledge. You don't give the IETF any money, you just pay the costs detailed above. The IETF doesn't really tell you that you have to do any of the above. Everything really is optional, but most sponsors follow the established pattern. For U.S. locations, the sponsor is not involved directly with the venue, the hotels, A-V or other direct meeting support beyond the network; the secretariat handles it all. You don't see many companies rushing to spend hundreds of thousands of dollars to sponsor an IETF. There really isn't any glory, and lots of potential grief. Brian -Original Message- From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 4:20 PM To: Joel Jaeggli Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: Meetings in other regions On 24-jul-2006, at 16:28, Joel Jaeggli wrote: IETF should look for global sponsors, in a given time frame, for example for a year, or just a meeting if needed, but as said *decoupled* from the venue. Local sponsors can take care of the social, breaks, etc. As you know Jordi local sponsors have historically been invaluable in getting access to local resources, like network connectivity and handling the logistics of network setup. having local support is always better than not having it. I think Jordi brings up a good point, today sponsors are supposed to cough up a lot of cash AND do a lot of work. Presumably, it would be easier to find people with cash and people willing to volunteer work separately rather than insist on a package deal. Also, it's unclear how much sponsoring an IETF meeting is supposed to cost in actual cash. The documentation doesn't talk about cash, only about facilities. I'm pretty sure I can arrange for facilities such as bandwidth, network operations/terminal room staffing and maybe even a social event for free or nearly free by having different organizations sponsor each, but if I could come up with the money to pay market price for this stuff then I wouldn't be on this list but I'd be paying someone else to be on it. So is the quarter million figure that I saw floating by in my inbox supposed to cover the published host duties, or is this in _addition_ to taking care of these duties? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Flaw in the NOTEWell System makes NOTEWELL NOTWELL
I've actually been successful at arguing something like the opposite of this. Many corporations now assert this silly little hunk of text at the end of every message claiming the email is private and such. A typical one is: This message and any attachments to it may contain PROPRIETARY AND CONFIDENTIAL INFORMATION exclusively for intended recipients. Please DO NOT FORWARD OR DISTRIBUTE to anyone else. If you are not the intended recipient, please contact the sender and delete all copies of this e-mail from your system. This is in direct violation of Note Well, which requires all documents, including email to not contain proprietary or confidential information. Further, since the email is sent to the IETF, which has a well established policy of publicly posting all email sent to it, I have argued that unless this warning is removed, it renders the admonition ineffective for the cases it is wanted, since the sender obviously knows that what he is sending is not confidential, is instantly forwarded, is immediately made public and to claim otherwise means the sender is not actually serious about defending truly private IP. Several lawyers have agreed, and forced the corporation to allow removal of the postscript when sending to public lists, much to the consternation of the IT folks who thought implementation of the IP notice was simple. Since complying with IETF IP policy is a condition of participation, and no one is forced to participate, corporations can claim ownership, but cannot claim confidentiality. I also chuckle at the delete all copies of this email part. Most corporations routinely backup inboxes, making this impossible for the non-intended recipient to comply. I always compare this to the Hollywood stars who will not answer a call without incoming CallerId, and always block outgoing CallerId. Do note that even post SOX, the notice on the email typically does not claim ownership. Every company I know claims ownership of everything on their systems, which would include, presumably, all incoming mail. So you always have the dueling claims to fight over. Brian -Original Message- From: todd glassey [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 6:44 PM To: ietf@ietf.org Subject: Flaw in the NOTEWell System makes NOTEWELL NOTWELL Hi there Audit Fans - Lets look at NoteWell and figure out how it interacts with Corporate Governance and Compliance Policies... let me make a couple of observations: NOTEWELL http://www.ietf.org/NOTEWELL.html has some hidden requirements that make it broken. Let me illustrate... 1) All the major players who sponsor people in the IETF have an iron-clad email policy which EVERYONE is aware of that says that they OWN the IP emanating from their Email System. This is generally not negotiable here in the US either. This means that they WILL NOT allow any releases against IP sent from their Email Systems or Domain. The cannot - lest they lose the control they have over the internal use of the servers which might seem fun to this group - but its something that NO EXECUTIVE is going to allow. 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. 3) The IETF also tries to protect itself by requiring the Individual to represent that they have formal authorization to participate in the IETF through the Entity's resources, except that there is the issue of #1 which NO entity in its right mind would consider relaxing... So who actually owns the IP? Better yet - can ANY SOX constrained company with public controls in place on its internal services allow an Employee or Guest to use their infrastructure to participate in a process that directly violates their corporate operating guidelines? ??? Todd ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: What's an experiment?
I believe if the community does not have confidence that the protocol will actually work on the Internet, then we are experimenting. I think this definition would cover a number of protocols we would now consider for Proposed Standard (rather than Informational), and pushes us back towards Running Code. A protocol that has no implementations and is significantly new and different that we cannot inspect the document to have confidence it will work as intended would be Experimental. This is both a complexity and an exposition test as well as a measure of how similar a protocol is to other protocols we know work as intended. I think that when an author, or an entire work group, dreams up a significant new protocol and brings forth a complex document with no code, then we have a research and development effort underway, which should be allowed to complete; that is, test it. We have a product (a real standard), when we show that our research worked. As with most research and experimentation, it is not necessary to have market acceptance to have a successful research project. It is nice, and a good indicator that the protocol works. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian E Carpenter Sent: Wednesday, February 15, 2006 10:07 AM To: IETF discussion list Subject: What's an experiment? When considering some recent appeals, the IESG discovered that we have very little guidance about the meaning of experiments in relation to Experimental RFCs. RFC 2026 refers to work which is part of some research or development effort and the IESG has adopted some guidelines to discriminate between Experimental and Informational documents (see http://www.ietf.org/u/ietfchair/draft-iesg-info-exp-01.html ). But beyond that, we do not know what constitutes an acceptable experiment on the Internet. The IESG notes that the community could establish a variety of guidelines describing what is and is not acceptable in experiments. Historically, the IESG has made decisions based on its perception that there is a strong desire in the community to publish technology that is being deployed experimentally. We encourage community discussion and development of more specific guidelines on operational conflicts caused by experiments and how this should affect what we choose to publish. (However we recommend that such discussion focus on the general issue rather than the specifics of any case.) Brian Carpenter for the IESG ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
It's trivial for a human, but not for a computer. Many things trivial for humans are not trivial for computers. The kind of harvesting you are talking about is trivial for a human from any format as long as your editor can paste while losing formatting. What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. Your statement that the IETF is getting populated with people who don't code is true. It's a fact, and we need to adapt. Most (but not all) of the people who design protocols these days don't code; they have people who work with them who do. Part of that is unavoidable. The part I regret, which could be avoided, is the loss of running code that we used to care about. Another thread. Brian -Original Message- From: Theodore Ts'o [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 11:37 PM To: Brian Rosen Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org Subject: Re: Alternative formats for IDs On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote: Any format can be used for any purpose, but it might be time to fully stand up to requirements to harvest data, and to recognize (as I did on another side thread), that reading is getting harder and harder for ASCII. It may be a decent archive format still, but I'm not sure it's going to stay that way. Huh? Harvesting data from ASCII, in terms of pulling out MIB's to be fed into MIB compiler, or reference C code for algorithms like MD5 (RFC 1321) is *trivial* under ASCII. Last I checked, C compilers and MIB compilers still use ASCII text as input, and not Word documents or XML documents. Maybe part of what is going on is that IETF is getting populated with people who aren't close to coding as much as before? You can get perfectly decent text editors for all operating systems, even Windows. And even Word can import text (i.e., plain ASCII) documents Just Fine. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
Ted You are arguing that we have been producing documents for a long time with only primitive tools and we don't need to make any new tools. You are losing that argument. We are increasing the number, and usefulness of tools, and most of us appreciate these tools and want more of them. The range of useful tools we can produce is related to how much meta-data we put in the source files. The more meta-data we put in, the more usefulness we can get out of the data. There is very little downside to adding meta-data as long as it's easy to put in. For most of these things, we have to do special formatting, so we are already marking the octets in some way. Do you have any idea how painful it is to build any kind of product that has good management simply because there is no library of MIBs, with references to documents? There isn't even a LIST of IETF MIBs. You can't figure out if a document has a MIB unless you actually look at the text (although many have a big hint in the title of the document). So yes, I believe better MIB tools would lead to better products, although it would be hard to prove it. I would like to enable automated testing of ABNF. I'd like to be able to cross check the ABNF from one document against its normative references to see what changes or conflicts. I'd like to be able to generate a complete list of SIP error messages a UA may be expected to encounter. I'd like to see a lot more hyperlinking of things. All of these are much easier with meta-data. Brian -Original Message- From: Theodore Ts'o [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 8:58 AM To: Brian Rosen Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org Subject: Re: Alternative formats for IDs On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote: It's trivial for a human, but not for a computer. Many things trivial for humans are not trivial for computers. The kind of harvesting you are talking about is trivial for a human from any format as long as your editor can paste while losing formatting. What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. True. So what? Do you think that it is possible, or even a good idea, that tools be able to rip out a MIB without reading the rest of the text? If so, why the heck do we spend so much time working on a the human-readable sections, like Security Considerations? And how much time does it really save to have an automated tool pull out the MIB, instead of having a human do it? And what percentage of the effort does that represent out of the effort to create a product, anyway? 0.0001% 0.1%? I can usually do it in under a minute with some emacs macros, but I'm willing to admit that I may be a bit better at it than others. Other people could probably do it in a few minutes using sed and awk, or even (gasp) perl. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
sorry, couldn't help it You mean, like xml? -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 8:53 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: Alternative formats for IDs ... What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. You can do that with meta-data encoded in plain ASCII. In fact, that would work better for automated extraction than anything visual such as using multiple fonts. code.../code Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
I'd mostly agree if this was a one off, but it's not; it requires continuous effort to maintain. My experience that manual is usually cheapest if it only has to be done once, and automation is cheapest if it has to be continuously maintained. YMMV. Most of the harvesting of sections of things that are now text that could be harvested apply to RFCs and not IDs, but things like ABNF checking and even MIB checking could be part of ID nits. Hyperlinks apply to both. There are many ways to put meta-data in files, but I'd rather not invent a new one. xml is just fine, thank you. And we have a nice tool that puts out text and html, and with a small amount of effort, PDF from xml. Our reluctance to use it is mostly: The RFC editor has some problems which have not, to my knowledge, beenenumerated. There are currently other ways to produce ASCII output that people are reluctant to give up on. I suspect we can fix the former. The question is whether the usefulness of the harvesting and alternative outputs outweighs the latter, assuming we accept ASCII output as required and normative. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hoffman Sent: Tuesday, January 10, 2006 11:15 AM To: ietf@ietf.org Subject: RE: Alternative formats for IDs At 9:45 AM -0500 1/10/06, Brian Rosen wrote: Do you have any idea how painful it is to build any kind of product that has good management simply because there is no library of MIBs, with references to documents? There isn't even a LIST of IETF MIBs. You can't figure out if a document has a MIB unless you actually look at the text (although many have a big hint in the title of the document). So yes, I believe better MIB tools would lead to better products, although it would be hard to prove it. Why does this need to be done in the RFCs or Internet Drafts themselves? Why, for example, can't a human with a bit of training extract all the MIBs from the current RFCs and put them into a repository that is machine-accessible? Doing so would probably take less time than writing the tool to make human-readable RFCs also machine-readable. As for Internet Drafts (if we really want people implementing from Internet Drafts), it is trivial to create a convention that says if you want the MIB in your draft to be machine-readable, copy the MIB to a public web server and, in the draft, put on a line by itself: THE-MIB-IS-AT url. No changes are needed to any input or output tools, yet the problem of finding MIBs is solved. I would like to enable automated testing of ABNF. I'd like to be able to cross check the ABNF from one document against its normative references to see what changes or conflicts. I'd like to be able to generate a complete list of SIP error messages a UA may be expected to encounter. I'd like to see a lot more hyperlinking of things. All of these are much easier with meta-data. Sure. If any of those features came free or very cheap, that would be great. None of them do, particularly when you factor in the design-by-entire-IETF-mailing-list work factor. Instead, a bit of human interaction is much less expensive. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
So, the problem you are citing is the issue that you want to harvest data out of the ID or RFC. That's common now, and getting more common. You then immediately move to say ASCII is the right output format because it makes harvesting the data you want easy. Well, probably not as easy as publishing the ID/RFC in some way that is designed to make harvesting of the data within it easy. Say, xml (2629 and follow ons). I believe this issue has been raised before, but we have three uses for the ID and RFC files: we read them, we harvest data from them and we archive them (RFCs anyway) for later use. Any format can be used for any purpose, but it might be time to fully stand up to requirements to harvest data, and to recognize (as I did on another side thread), that reading is getting harder and harder for ASCII. It may be a decent archive format still, but I'm not sure it's going to stay that way. Of course, if you have three different uses, and you end up with more than one format to satisfy all of your requirements, then you have the normative problem. I really think some of you wave that particular flag a bit too strongly, but I think that most of us would be okay with publishing in multiple formats, including ASCII (for now), and even with saying that the ASCII text is the normative one, if and when there is any difference that matters between the formats. I think publishing the xml for harvesting really is the best thing we can do. If we do, we may want some more work done to make more harvesting possible. The schema now is really organized around readability. This probably has less to do with defining new tags than in using some metadata to mark things like ABNF, code, MIBs and the like. I am a proponent of PDF output format; I find it very useful for reading. I have had very few problems with PDF, fewer than with ASCII these days. I am also pretty pleased with HTML as the current tool (xml2rfc) creates. That would mean the the I-D editor and the RFC editor uses xml2rfc, we publish the xml, the ASCII and possibly PDF and/or html from the xml. If you want, the ASCII can be normative. That also implies the desired input format is xml. We can discuss if we want the RFC editor to accept something else and bear the burden of converting to xml. I've heard the RFC editor has tried using xml and xml2rfc and is not satisfied with the results as far as creating ASCII versions of RFC text. It would be interesting to hear what problems they have seen. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David B Harrington Sent: Saturday, January 07, 2006 9:33 AM To: 'John C Klensin'; 'Marshall Eubanks' Cc: ietf@ietf.org Subject: RE: Alternative formats for IDs Hi, As a MIB Doctor and chair of the Bridge WG, I have been working with the IEEE 802.1 WG, who will assume maintenance responsiblities for the Bridge WG Mib modules. IEEE 802.1 publishes their standards in PDF. We had to make a special request that they make the MIB portion of their documents available in ASCII format, partly so, as part of the transition process, IETF MIB Doctors could review their documents (e.g., running the MIB module through smilint and other compilers), but also so the MIB modules could be extracted for importing into network management applications, such as NET-SNMP and HP OvenView. A similar issue will exist for documents that contain code snippets. While I personally like PDF for many things, I find PDF to be a poor choice for IETF works-in-progress, or even for RFCs because they lack many of the characteristics that ASCII files offer. David Harrington [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John C Klensin Sent: Monday, January 02, 2006 3:37 PM To: Marshall Eubanks Cc: ietf@ietf.org Subject: Re: Alternative formats for IDs Marshall, --On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks [EMAIL PROTECTED] wrote: ... The project, currently referred to as PDF/A, will address the growing need to electronically archive documents in a way that will ensure preservation of their contents over an extended period of time, and will further ensure that those documents will be able to be retrieved and rendered with a ^^ consistent and predictable result in the future. This need exists in a growing number of international government and industry segments, including legal systems, libraries, newspapers, regulated industries, and others. The work will address the use of PDF for multi-page documents that may contain a mixture of text, raster images and vector graphics. It will also address the features and requirements that must be supported by reading devices that will be used to retrieve and render the archived documents. ^^ Emphasis added, of course. As I have understood it, PDF/A is
RE: objection to proposed change to consensus
This On the other hand, it does appear that the availability of ASCII support as a common denominator is decreasing over time. As has been observed, some software vendors seem to go out of their way to make simple ASCII hard to use. So there is increasing pressure to find a (truly) better solution. This is the nut of the output representation problem for me. Most people who object to changing the output format talk about ASCII as if it always was the standard, and always will be the standard. If we were having this discussion 30 or 35 years ago, we would be discussing whether ASCII would take over EBCDIC or not. 35 years ago, it would not be clear that ASCII would survive. There was a holy war about that. ASCII did in fact take over from EBCDIC, but it wasn't always clear that it would. As Bob points out, we are, in fact, coming to the end of the line for ASCII. It's not in trouble this year, except that it's pretty damn tough to print it satisfactorily on the machines most of us have to work with. I suspect it will get increasingly difficult to create and edit in the not too distant future. That would make it a possible minimum common denominator archive format, but not a useful reading format. It's probably true that we can push this problem off another year, but maybe not, and definitely not for very much longer. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Why have we gotten away from running code?
I notice that we have stopped being interested in running code. I think that is to our community's detriment. If two groups are arguing with one another, and one has implemented code and the other has not, I think we would give great weight to the running code. I don't see that happening. This happened in a session during this meeting where I was present. Running code was not considered significant in the discussion; it was not even mentioned as a criterion in deciding the issue. Probably more importantly, I think we should be VERY suspicious of new, complex specifications before we have running code. We are very clearly NOT doing this. We are willing to publish a proposed standard for an entirely new protocol that has very significant complexity, where there are people openly skeptical that it will work at all, with nothing but some sketchy simulations and a (admittedly well reviewed) draft. We are routinely publishing complex protocols and significant changes/additions without even simulations. Our rules permit us to do such things. We should rarely choose to. We don't know what we are getting into until we write code. We don't know how hard it is to implement, we don't know what works and what doesn't. Perhaps there are a large number of you out there that are able to claim reasonably complex things work based on reading a document and looking at simulations. I am not. My experience is that getting something to actually do what you want it to do is very illuminating. I wonder if we should change our bias towards bestowing Experimental status on drafts that ask to be published as RFCs without running code. Clearly, there are specifications where the complexity is low, and we have enough experience with the subject that we can be reasonably sure it works without running code. We should be able to bring such ideas out at Proposed Standard. Good judgment is always required to choose which side of a line a particular draft falls on. I assert we have pushed the line away from running code quite too far. We still do operate with rough consensus. We ought to return to having running code. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: calendar file for IETF
So, I just had to try it, even though my company insists on MS Exchange for calendars. Of course it didn't work, and I never expected it to work. However, the error message is at least amusing: This error can appear if you have attempted to save a recurring Lunar appointment in iCalendar format. To avoid this error, set the appointment option to Gregorian instead of Lunar. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eliot Lear Sent: Saturday, July 23, 2005 4:35 AM To: Cyrus Daboo; IETF Discussion Cc: Eliot Lear Subject: Re: calendar file for IETF An additional update reflecting yesterdays changes is now available at http://www.ofcourseimright.com/~lear/ietf63.ics. Additional stuff: - UIDs *should* be stable across changes. - An attempt has been made to make proper use of SEQUENCE - An attempt has been made to parse out LOCATION information - Garbage in/Garbage out problem repaired. - Several bad dates have been corrected. Usual cautions apply. This calendar file could blow up any tool it is applied to. But it didn't blow up iCal, at least. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Labels in Subject Headers Considered Ineffective At Best' to Informational RFC
I read the first draft of this document, and wondered: Does this propose to change IETF behavior on list management, so that the name of the list (usually same as working group) is not put in the Subject: using the feature of mailman that does this? When it was just a draft, it was just speculation. Now that the IESG is considering this draft, I want to ask: Is that what you have in mind? I think having the IETF list traffic have the solicitation class keyword marked appropriately is a good idea. I think having every email program on the planet become capable of filtering on this keyword is a good idea. I think having every email program on the planet become capable of displaying this field when it is not empty has some value, but I'm not sure what the tradeoffs are when the display is small, as on a PDA or mobile phone. However, until we get the latter two accomplished, I want the list manager to mark the Subject: with the name of the list. I don't know about you, but what I have today (very popular email program from a gigantic company and very cool cellphone/PDA combo thingy that works pretty darn nice for email) WILL NOT WORK WELL FOR ME if Subject is not marked. One does not have filters, and does not have a way to display an arbitrary header field. One has filters, but I don't see a filter mechanism for Solicitation Class, and I don't see that key word in the fields I can display, although there appears to be a way to define your own field so maybe that would work. Dunno, but unless it works at least as well as marking Subject, I don't want to get rid of that feature. So, I ask that the author of the draft state his intentions with respect to IETF list management, and that such an intention form part of the consideration of the IETF on what to do with the draft. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:ietf-announce- [EMAIL PROTECTED] On Behalf Of The IESG Sent: Tuesday, February 22, 2005 9:35 AM To: IETF-Announce Subject: Last Call: 'Labels in Subject Headers Considered Ineffective At Best' to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Labels in Subject Headers Considered Ineffective At Best ' draft-malamud-subject-line-02.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-03-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-malamud-subject-line-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
I don't have any comment on the issue of language tags, but speaking as a reasonably avid ABNF hacker, I agree with Sam, and would not want to establish a convention that ABNF in IETF RFCs is expected to be precise. One MUST read the text to understand what the limits of the syntax are. This is especially true with repetitions. It's usually tortuous to write ABNF that limits repetitions or string lengths. It's possible, but the result is very hard to understand. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman Sent: Saturday, December 18, 2004 1:55 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP Bruce == Bruce Lilly [EMAIL PROTECTED] writes: Bruce If there really are only 24 items of less than 11 octets Bruce each, a trivial solution is to simply list them (with the Bruce usual ABNF syntax) as literal strings. That should take no Bruce more than a half-dozen lines. Perhaps. I actually find a lot of ABNF specs are not as clear as they could be to humans because they are trying to describe the valid inputs as strictly as possible. In many cases I think the spec would be more clear if the ABNF were relaxed and other constraints were expressed at appropriate levels. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Shuffle those deck chairs!
You guys don't have a problem with the defensive suspension/no first use clauses, do you? Is there a preferred wording for it? Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric S. Raymond Sent: Wednesday, October 13, 2004 10:56 PM To: Sam Hartman Cc: Florian Weimer; [EMAIL PROTECTED] Subject: Re: Shuffle those deck chairs! Sam Hartman [EMAIL PROTECTED]: I think it would be wonderful if the free software community could come to a consensus about what their requirements are. That's not hard. We need licensing conditions that don't require us to either pay royalties or sign legal papers, and which don't inhibit re-use of the code by restricting the area of application. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Shuffle those deck chairs!
This text does not seem to cover what we usually encounter in protocol development. What happens is that you claim a patent that would be infringed by implementing the protocol. Another company has its own patent that it also claims would be infringed by implementing the protocol. You are willing to grant a worldwide, royalty free license to the patent to anyone, including the other company, so long as the other company doesn't try to force you to pay a royalty or take out a more restrictive license to his patent. Take a look at: http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIMPLE.txt for an example. Brian -Original Message- From: RL 'Bob' Morgan [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 1:28 PM To: Brian Rosen Cc: IETF Subject: RE: Shuffle those deck chairs! On Fri, 15 Oct 2004, Brian Rosen wrote: You guys don't have a problem with the defensive suspension/no first use clauses, do you? Is there a preferred wording for it? I think you'll find virtually identical wording on this topic in several well-known licenses: http://www.apache.org/licenses/LICENSE-2.0 http://www.mozilla.org/MPL/MPL-1.1.html http://www.eclipse.org/legal/cpl-v10.html http://www.opensource.org/licenses/afl-2.1.php - RL Bob ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
