Re: Non-priority baggage handling (Re: Warning - risk of duty free ...)
AFAICT, they're just visible indicators of who flies a lot, which means they also tell people which bags might be more valuable to steal. I ask them not to put the tags on. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt
Narayanan, == Narayanan, Vidya [EMAIL PROTECTED] writes: Narayanan, Dan, There is a fundamental security property in all Narayanan, that we have been discussing: Narayanan, It MUST NOT be possible for an entity A, impersonating Narayanan, as entity B, to obtain any key material that entity B Narayanan, may actually possess at any time. I continue to believe the model you are using is too simplistic to have the discussion you're having. We're focusing on issues that arrise when entities have multiple identities in different namespaces. At least, that is the focus of the text I'm asking for discussion about. i don't understand how you can discuss that text without a model that involves entities with multiple names. I'm going to meet with Lakshminath on Sunday and then make a consensus call. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Non-priority baggage handling (Re: Warning - risk of duty free ...)
--On Friday, 16 March, 2007 07:50 -0700 Joe Touch [EMAIL PROTECTED] wrote: AFAICT, they're just visible indicators of who flies a lot, which means they also tell people which bags might be more valuable to steal. I ask them not to put the tags on. Joe, I've also been told by a couple of airlines that, if your bag gets lost and ends up sitting in a figure out who this belongs to and how to get it there area, those brightly-colored tags get the first attention. I cannot verify this from experience: after some lost luggage incidents lately, if the priority tags get higher priority treatment, I hate to think about what the rest of the bags are getting. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
Ned == Ned Freed [EMAIL PROTECTED] writes: --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson [EMAIL PROTECTED] wrote: And it was a suggestion/ request that, before this document was published in _any_ form, that it at least acquire a clear discussion as to when one would select this form over the well-established ASN.1 form for which there is existing deployment, existing tools, etc. Ned This suggestion was at the very least strongly implicit in the earlier Ned discussion. I think I made some preliminary conclusions regarding the intent of this effort, which I can write more about later. Ned It also occurs to me that what may be needed here is a BCP on how to best use Ned ASN.1. We have such a BCP on XML. ASN.1 is similarly complex and similarly Ned decorated with features, so it makes sense to me that if we're going to Ned continue to use it why not have a document discussing what features make sense Ned and what ones don't. (For example, some sage advice on when and how to use Ned EXTERNAL could have made several protocols a lot more tractable.) I began such a document a few years ago. Perhaps I should dust it off. I would certainly be supportive of that. Also, I think many people contemplating ASN.1 would do well to read the actual specifications, as well as the reasonably good (and freely downloadable) books by Dubuisson and Larmouth. To be honest I found the specifications totally inpenetrable as a means of initially learning ASN.1, including the relatively straightforward initial description that first appeared in X.400-1984. (I have no idea why they insist on making macros in particular seem like so much more than they really are.) Of course I no longer have this problem - but surely that's to be expected after implementing X.400-1988 from scratch... The free books are OK IMO but not great. Although it's now fairly dated, I still think the best book on ASN.1 is the one by Douglas Steedman: ASN.1 Tutorial and Reference. Unfortunately it is out of print and nearly impossible to find - and it was fairly expensive when it was in print. (And no, my copy is not for sale ;-) I went so far as to put this one on my list of books the ACM should revive and republish, but I fear I was the only person who did so. Put differently, we all know that this _can_ be done but, if there is another solution already out there, widely deployed, and in active use, a clear explanation about _why_ it should be done and under what circumstances it is expected to useful is in order. Ned Given how little uptake (AFAIK) there has been of the various encodings for Ned ASN.1 beyond BER and DER (let's see, there's CER and PER and at least two Ned others whose names I cannot recall), I'm not especially worried about XER Ned taking the world by storm. Indeed, I think it would actually help XER's case if Ned there was some explanation of where and why you'd ever want to use it. Use of alternative encoding rules might best be coupled with presentation layer negotiation, which is a direction the IETF has historically resisted moving towards, I think. (It doesn't help that PER is rather baroque for the sake of conserving bits.) Or it might not. If memory serves, I actually implemented this stuff in our X.400 code because some profile or other (German maybe?) required it. What I found was that apparently everyone else that did it just coded it as a checkbox item and didn't bother to check to see if it actually worked. The result was a huge loss of interoperability, and X.400 interoperability was in general so poor that I think we actually went so far as to rip it all out. (It's a huge pain to implement for X.400 in any case because X.400 P1 uses RTSE, not ROSE, and hence it is convenient to pre-encode messages and put them in files.) This IMO is one of the big problems with lots of options in protocols - they tend to result in batches of infrequently used code that contains lots of bugs. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ION approved
An IETF Operational Note has been approved and posted: http://www.ietf.org/IESG/content/ions/ion-agenda-and-minutes.html RFC 2418 outlines the procedures for IETF Session operation. However, it contains little information about post-IETF meeting working group chair responsibilities. In particular, it provides little guidance with respect to either form or submission deadlines for the artifacts of the meeting, namely, session minutes and presentation materials. This document addresses these issues and provides suggestions about the form and content of Working Group agendas and minutes. The use of the templates is not mandatory and the guidance herein may be safely ignored. For the general ION page, see http://www.ietf.org/IESG/content/ions.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pwe3-aii-aggregate (AII Types for Aggregation) to Proposed Standard
The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'AII Types for Aggregation ' draft-ietf-pwe3-aii-aggregate-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-aii-aggregate-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14352rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL Routing Requirements in Support of RBridges ' draft-ietf-trill-routing-reqs-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 substantive comments to the ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15187rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pkix-scvp (Server-based Certificate Validation Protocol (SCVP)) to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Server-based Certificate Validation Protocol (SCVP) ' draft-ietf-pkix-scvp-31.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-31.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=4376rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
PGP Key Signing
Once again, we will be holding a PGP Key signing party at the 68th IETF meeting in Prague. We have been scheduled to meet at 1620 on the evening of Wednesday, March 21 in the Roma/Vienna/Madrid room. Note that we have a very tight time-slot between the last afternoon and the plenary, so please be on time. The procedure we will use is the following: o People who wish to participate may do so in one of two ways. You may bring slips of paper with your name, e-mail address, key-id, and key fingerprint. (One way of generating this if using gpg is gpg --list-keys --fingerprint [EMAIL PROTECTED]) You should bring enough for everyone who may attend; given recent attendance patterns, around 50 should be more than enough. (You can generally fit 10-12 strips containing your key fingerprint on a single sheet of paper, and then cut out strips to hand out.) o Alternatively, you may email an ASCII extract of their PGP public key to [EMAIL PROTECTED] by noon on Wednesday, March 21. Please include a subject line of IETF PGP KEY, and please DO NOT MIME-ENCRYPT your e-mail; send it to me as plain text. The method of generating the ASCII extract under Unix is: pgp -kxa my_email_address mykey.asc (pgp 2.6.2) pgpk -xa my_email_address mykey.asc (pgp 5.x) gpg --export -a my_email_address mykey.asc (gpg) If you're using Windows or Macintosh, hopefully it will be Intuitively Obvious (tm) using the GUI interface how to generate an ASCII armored key that begins -BEGIN PGP PUBLIC KEY BLOCK-. o By 1500 on Wednesday, you will be able to fetch complete key ring from any of the following locations with all of the keys that were submitted: /afs/grand.central.org/project/ietf-pgp/ietf68/ietf68.pgp http://grand.central.org/dl/ietf-pgp/ietf68/ietf68.pgp ftp://grand.central.org/pub/ietf-pgp/ietf68/ietf68.pgp o At 1620, come prepared with the PGP Key fingerprint of your PGP public key; we will have handouts with all of the key fingerprints of the keys that people have mailed in. o In turn, readers at the front of the room will recite people's keys; as your key fingerprint is read, stand up, and at the end of reading of your PGP key fingerprint, acknowledge that the fingerprint as read was correct. o Later that evening, or perhaps when you get home, you can sign the keys corresponding to the fingerprints which you were able to verify on the handout; note that it is advisable that you only sign keys of people when you have personal knowledge that the person who stood up during the reading of his/her fingerprint really is the person which he/she claimed to be. o Send the signed keys to the owners, and, optionally, to the PGP key servers. Some poeple opt to NOT send the signed keys to the keyservers, but rather choose to send them only to the e-mail address on the key's userid, encrypted for that particular key. This tends to ensures the validity of the e-mail address. Note that you don't have to have a laptop with you; if you don't have any locally trusted computing resources during the key signing party, you can make notes on the handout, and on the strips of papers, and then take these and sign the keys later. Acknowledgement: The bulk of the text of this message was taken from the messages usually sent by Ted Ts'o to announce IETF key signing parties. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'IANA Considerations for PPP over Ethernet (PPPoE)' to Informational RFC
The IESG has approved the following document: - 'IANA Considerations for PPP over Ethernet (PPPoE) ' draft-arberg-pppoe-iana-03.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-03.txt Technical Summary This document provides for an IANA registry of PPPoE TAG and Code fields. Known existing usages are reserved, and a first come first served policy is established for future codes. Working Group Summary The PPPEXT working group reviewed the document and there are no known concerns with the work. PPPoE itself is not a standard protocol (L2TP and DHCP are standards-track alternatives), and future extensions are thus not encouraged. However, the new registry will help prevent possible conflicts that may develop before the standards-based solutions are adopted by PPPoE users. Protocol Quality This document does not specify any protocol. The registry established reflects current practice within the community. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: '6LoWPAN: Overview, Assumptions, Problem Statement and Goals' to Informational RFC
The IESG has approved the following document: - '6LoWPAN: Overview, Assumptions, Problem Statement and Goals ' draft-ietf-6lowpan-problem-08.txt as an Informational RFC This document is the product of the IPv6 over Low power WPAN Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-08.txt Technical Summary 6LoWPAN is specification describing how to utilize IPv6 on top of low power, low data rate, low cost personal area networks. These networks today being built using IEEE 802.15.4 standard radios. These radios have an extremely limited frame size which makes it necessary to define an adaptation layer to support link layer fragmentation and reassembly. Additionally since these networks utilize low power transmission it is necessary for the adaptation layer to support network layer mesh capabilities. This specification defines the header format for this adaptation layer. Working Group Summary The working group reached consensus on this document. Document Quality There are at least 6 independent implementations of this protocol being worked on and all concerns raised during the review and WGLC have been addressed. Geoff Mulligan is the Document Shepherd. Note to RFC Editor 1) The draft indicates in its 3rd line that the intended status is Standards Track. However, the document should be Informational. 2) The document does not contain any normative statement (capitalized MUST, MAY, SHOULD, etc.), Section 1.1 and the reference to RFC 2119 could be safely deleted. 3) Normative references should be [ieee802.15.4] and [RFC2460], with the remaining informative. 4) OLD: An admittedly non-technical but important consideration is that intellectual property conditions for IP networking technology are either more favorable or at least better understood than proprietary and newer solutions. NEW: An admittedly non-technical but important consideration is that IP networking technology is specified in open and freely available specifications which is favorable or at least able to be better understood by a wider audience than proprietary solutions. OLD: As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work out of the box, be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. Network management should have little overhead yet be powerful enough to control dense deployment of devices. NEW: As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work out of the box, be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. The size constraints of the link layer protocol should also be considered. Network management should have little overhead yet be powerful enough to control dense deployment of devices. OLD: Network Management: One of the points of transmitting IPv6 packets, is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. [RFC3411] specifies SNMPv3 protocol operations. SNMP functionality may be translated as is to LoWPANs. However, further investigation is required to determine if it is suitable, or if an appropriate adaptation is in order. This adaptation could include limiting the data types and simplifying the Basic Encoding Rules so as to reduce the size and complexity of the ASN.1 parser, thereby reducing the memory and processing needs to better fit into the limited memory and power of LoWPAN devices. NEW: Network Management: One of the points of transmitting IPv6 packets, is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. However, management solutions need to meet the resource constraints as well as the minimal configuration and self healing functionality described in section 4.4. The Simple Network Management Protocol (SNMP) [RFC3410] is widely used for monitoring data sources and sensors in conventional networks. SNMP functionality may be translated as is to LoWPANs with the benefit to utilize existing tools. However, due to the memory,
