2014-09-29: Minutes
slides-interim-2021-ietfieee-03-sessa-2014-09-29-minutes-00
| Meeting Slides | IETF-IEEE (ietfieee) IAB ASG | |
|---|---|---|
| Date and time | 2021-12-31 19:00 | |
| Title | 2014-09-29: Minutes | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2022-06-10 |
slides-interim-2021-ietfieee-03-sessa-2014-09-29-minutes-00
IAB, IESG and IEEE 802 Executive Committee Minutes of the 29 September 2014 Meeting, Newark, NJ, USA Reported by: Cindy Morgan (IAB Executive Administrative Manager), Jon Rosdahl (IEEE 802 Executive Secretary), and Dan Romascanu ATTENDEES ------------------- - Jari Arkko - Richard Barnes - Kathryn Bennett - Benoit Claise - Alissa Cooper - Subir Das - Spencer Dawkins - Donald Eastlake - Adrian Farrel - Norman Finn - Eric Gray - Brian Haberman - Bob Heile - Joe Hildebrand - Russ Housley - Konstantinos Karachalios - Barry Leiba - Ted Lemon - Kathleen Moriarty - Cindy Morgan - Paul Nikolich (present from item 7 on) - Glenn Parsons - Pete Resnick - Dan Romascanu - Jon Rosdahl - Dorothy Stanley - Andrew Sullivan - Pat Thaler - Juan Carlos Zuniga MINUTES ------------------- 1. Introductions and Goals of the Meeting Dan Romascanu welcomed everyone to the meeting and led a round of introductions (see list of attendees, above). Dan Romascanu noted that these joint sessions began as a way for the leadership from the IETF and the IEEE 802 to interact and provide early warning about the projects being discussed within each group; the communication between the two groups is much better now. This is the first face-to-face meeting since the IETF and the IEEE 802 went through their leadership changeovers in March 2014. 2. Changes in the Routing Area Slides: http://www.iab.org/wp-content/IAB-uploads/2013/01/Routing- Area-Working-Group-Reshuffle.pptx Adrian Farrel outlined upcoming changes in the IETF Routing Area. He noted that no work is being removed or added, it is just being reorganized internally. He noted that some changes will happen before IETF 91 in November, with the rest to follow in early 2015. The Routing Area Working Group (RTGWG) is currently rechartering to improve clarity and become a venue for discussing new work. IETF work on VPNs, data centers, pseudowires, and BGP-enabled services is currently split into 4 Working Groups: PWE3, L2VPN, L3VPN, and NVO3. Under the new plan, this work will be split into 3 Working Groups: PALS (Pseudowire and LDP-enabled Services), BESS (BGP-enabled Services) and NVO3 (Network Virtualization Overlays). IETF work on traddic engineering, optical networking, and RSVP-TE is currently split into 3 Working Groups: PCE, CCAMP, and MPLS. Under the new plan, this work will be split into 4 Working Groups: PCE (Path Computation Element), CCAMP (Common Control and Measurement Plan), TEAS (TE Architecture and Signaling) and MPLS (Multiprotocol Label Switching). Adrian Farrel noted that the NVO3 Working Groups is currently rechartering; since this is an area of shared interest with IEEE 802, Adrian asked that people look out for the message to new-work about this effort. NVo3 will continue working on architecture and requirements for data center VPNs, centrally controlled data center VPNs, and new encapsulations. Work on the BGP-based control plane is out of scope for NVO3 and will be moved into the new BESS Working Group. Dan Romascanu asked whether the old NVO3 work being moved into BESS will be an area of shared interest with 802.3. Adrian Farrel replied that the BGP part is not a specific area of interaction with IEEE 802; that interaction will remain in NVO3. 3. Status of the Shared Areas Work Coordination Doc: http://www.iab.org/wp-content/IAB-uploads/2013/01/ coordination-14.pdf Dan Romascanu and Pat Thaler reviewed the list of shared work items. The coordination document (see above) has the current status of each item. Ted Hardie and Juan Carlos Zuniga agreed to put together a detailed description for item 23 on the shared areas work list, on naming in Layer 2 networks. Adrian Farrel and Glenn Parsons agreed to provide a description for item 25 on the shared areas work list, on 802.1. and PCE. 4. New Work: Proposed BOFs and PARs at the November Meetings The group reviewed the expected IEEE 802 PARs and IETF BOFs under consideration for their respective November meetings. IEEE 802 will consider the following: - 802c, Amendment: Local Media Access Control (MAC) Addressing - 802.1AS-rev - Timing and Synchronization for Time-Sensitive Applications - 802.1Qch- Amendment: Cyclic Queuing and Forwarding - 802.3bv- Amendment, 1000 Mb/s Operation Over Plastic Optical Fiber - 802.3by- Amendment: Media Access Control Parameters, Physical Layers and Management Parameters for 25 Gb/s Operation - 802.15.7a- Amendment for a Physical Layer Supporting Optical Camera Communications For the current status and more information, please see: http://www.ieee802.org/PARs.shtml IETF will consider: - Archive Top Level Media Type (ARCMEDIA, Applications Area) - DNS Private Exchange (DPRIVE, Internet Area) - Deterministic Networking (DETNET, Internet Area) - Autonomic Networking Integrated Model and Approach (ANIMA, Operations and Management Area) - Layer Independent OAM Management in the Multi-Layer Environment (LIME, Operations and Management Area) - Shared Unified Policy Automation (SUPA, Operations and Management Area) - Internet Video Codec (NETVC, Real-Time Applications and Infrastructure Area) - Bit Indexed Explicit Replication (BIER, Routing Area) o This work was noted as being of possible interest to the IEEE 802 Executive Committee - Abstraction and Control of Transport Networks (ACTN, Routing Area) - Interface to Network Security Functions (I2NSF, Security Area) - Delay Tolerant Networking (DTN, Transport Area) For the current status and more information, please see: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart Pat Thaler reminded the group that the PARs and BOFs under consideration had not yet been approved as of 29 September 2014. 5. New OPS Area Work - LIME Benoit Claise reported that the IESG is considering a proposal for a new working group, Layer Independent OAM Management in the Multi-Layer Environment (LIME). The work is on the specific OAM extensions that will need to be defined. There will be three deliverables: - YANG data model(s) for generic layer-independent and technology- independent configuration, reporting and presentation for OAM mechanisms. - An architecture for OAM that can be used as guidance by other IETF working groups developing new OAM protocols or modifying existing OAM protocols, at any layer and for any technology. This guidance will cover both the management and data planes. Existing OAM architectures will be reviewed. - Applicability document: The YANG model(s) specified in this working group must be usable and extensible by the existing OAM technologies. This usability and extensibility must be demonstrated, for example with IP Ping, traceroute, BFD, and LSP Ping. Note the technology-specific data model extensions should ideally be worked on in the respective working groups. Glenn Parsons asked if this would be a catchall YANG model group, or if this is for a baseline YANG model. Benoit Claise replied that it was for a baseline YANG model that is OAM-specific. Glenn Parsons mentioned that there is a new volunteer in IEEE 802 that he is hoping will pick up writing some of the MIBs. He added that moving everything from MIB to YANG would be a lot of work. Dan Romascanu replied that IETF is not planning to translate all of the MIB models to YANG, and added that this could be discussed further in 802.1. For more information: http://datatracker.ietf.org/wg/lime/charter/ 6. Deterministic Networking Slides: http://www.iab.org/wp-content/IAB-uploads/2013/01/tsn-nfinn- Deterministic-Networking-BOF-0914-v1.pdf Norm Finn updated the group on the current work on Deterministic Networking. Deterministic networking includes time synchronization, resource reservation for critical data streams, extremely low packet loss rations an guaranteed end-to-end latency, and convergence of critical data streams an other QoS features. Two classes of users are driving the work: industrial users, and audio/video users. As audio/ visual services have moved from analog to digital, lost packets and latency have become larger concerns. Fortunately, these sorts of data streams are easily characterizable by schedule of bandwidth. Norm Finn reported that IEEE 802 is currently working on several standards relating to time synchronization. 802.1 Audio Video Bridging is now the Time-Sensitive Networking TG. 802 is working on low-level schedulers and shapers. They have completed an AVB Credit- based shaper, and work on transmission pre-emption, time scheduled synchronization, and synchronized queueing and forwarding is still in progress. The work involves a mix of Layer 2 and Layer 3, as both bridges and routers are important parts of these networks. This will require cooperation between IEEE 802 and IETF. Time synchronization will be left to other Working Groups and SDOs. Low-level (typically hardware) queuing, buffering, shaping, and scheduling mechanisms can be left to IEEE 802. The proposed Deterministic Networking BOF in the IETF can work on existing 802 protocols and determine their relevance to the DetNet problem. IETF had a side meeting on DetNet at IETF 90, and has started a mailing list. A draft problem statement is in progress as draft-finn-detnet-problem-statement, and several versions of a Working Group charter proposal are being circulated. A 2-hour BOF session has been requested at IETF 91. It was noted that this work will have significant challenges, especially with regards to security. The distinction between layers is not that clear, it looks like we need to build a form of traffic engineered path that crosses both L2 and L3. In some cases, this means being able to identify 2 paths. Part of the robustness is being able to nail down disjoint so that you can get the traffic through as much as possible. Norm Finn clarified that this works just like RSVP today. It's a soft path. One of the things we want to do is harden that. Security gets interesting. Right now there is not much on security; we are trying to add more. Spencer Dawkins mentioned that the presentation was very useful, this being something that can be done in the IEEE that is not in the IETF, which is to put something together at a system level. When talking to the IETF, it is helpful to say we have a system in mind and we're not here to talk about the system. The system level would fall more under the IAB authority. Norm Finn appreciated this, and said that they are trying to narrow the problem statement down to do that. Jari Arkko, echoing what Spencer Dawkins said, noted that this is an exciting topic. As noted, there are some challenges in the complexity and having to bind some of the layers together. We shouldn't run the BOF here, but instead talk about how we best address this--how to slice this into pieces so that it is approachable. Joe Hildebrand asked a different question: assuming this is successful, one will not want to want to run TCP on top of this. Norm Finn responded that UDP is a real common one in this space. There may be some new transport protocols that come out of this here. There are protocols that are better at TCP and are better if you don't drop anything. All these sources have a fixed data rate. There a number of protocols that have a time stamp on every packet. This is at what time you should turn the light switch off. There are a lot of home-grown protocols whose only use is UDP. Spencer Dawkins considered that it sounds like DCCP may be interesting. Richard Barnes asked to what degree is this something where the work is already done at layer 2? Norm Finn responded that what has been done so far is something that works a lot like RSVP. Whatever protocol you're using to run your topology, you send out your reservation and you follow that down, and when the talker gets the reservation he knows he can stream the data and nothing will get lost. And the reservation automatically gets remade along the new path. Going forward, we want to have the dual path, which requires nailing it down, and what that needs, how do you do that. At one level, we need a protocol to either enhance RSVP with layer 2 stuff so that we have a protocol that both bridges and routers deal with along the way. And this is why the PCE is of interest to us. We have the 3rd piece, which is the serial replicating and bringing it back together at the other end. You can imagine using pseudowires in the general sense. Looks attractive because it's on the outside of the packet. Richard Barnes replied that this can be explained as we have these Layer 2 things that have these properties, and we need those Layer 3 things to bridge them. 7. Inter-SDO relations Russ Housley reported that the IETF has a peer relationship with ISO/ IEC JTC1 SC6, and thus an agreement not to write competing standards. IETF is watching what is happening in the Chinese National Body, as well as tracking ITU Plenipotentiary activities. Pat Thaler reported that the IEEE 802 has a standing committee for ISO/IEC JTC1. Dorothy Stanley noted that IEEE 802.11 has used that relationship to get ISO standardization for their specifications; they are now working to do the same on standards out of 802.1, 802.3, 802.16, and 802.22. Paul Nikolich added that IEEE 802 also has an open dialogue with 3GPP on cellular and wireless standards. 802 also has good relationships with the Wi-Fi Alliance and the Ethernet Alliance. Jari Arkko noted that there is multi-stakeholder work on the IANA process, as well as larger discussions about Internet governance. Those discussions are not necessarily about inter-SDO relationships, but the SDOs will be affected by the final outcome. 8. IS-IS TLVs Glenn Parsons reported that IEEE 802.1 would like an IS-IS TLV assignment to control explicit trees, and asked what the process for that would be, and whether an RFC would be required. Dan Romascanu replied that the process for that registry is review by the expert reviewers. Adrian Farrel added that there would be no need for an RFC simply to get an assignment from an already-existing registry. Glenn Parsons will follow up with Adrian Farrel and the expert reviewers for the IS-IS TLV registry about getting that assignment for 802.1. Glenn will also send a detailed description of the issue to Dan Romascanu for addition in the shared work items list. 9. Local Address Management in IoT Environments Slides: http://www.iab.org/wp-content/IAB-uploads/2013/01/new- addresses-thaler-local-address-acquisition-0914-v1.pdf Pat Thaler explained that the focus is about local address management in IOT environments. They are discussing making it easier to use local addresses, largely for virtualization environments. When MAC addresses were created, they were used pretty slowly. It was fairly narrow and the address space seemed like it would last forever. But at the end of the last decade, more were used and commonly users own 3-5 devices. Now even more addresses are used per person across the world: cell phones, TVs, Blu-Ray, tablets, printers, media computers, laptops, etc. A lot of addresses appear per household. With IOT network ports are going into smaller and smaller devices, many ports can be seen per home, per car, per machine. All these things consume global address space; once it is used it's burned forever. There is an explosion of IOT addresses,;you can have a car, and by 2020 a car could have 50-100 ports per car. That is a lot of addresses. Why not use local addresses? It is desirable to avoid users having to become local address administrators, in the case of virtual things that have a physical address. Where it talks to the orchestration system, it has a physical address used and then uses the virtual address/local address for the machine. In order to enable virtual address space for IOT, there is a need to make it easier to use the local address space for users. Local address space is huge, but it lacks organization for anything other than a local administrator assigning stuff. So the first step is to provide some structure for that use. Where a local address keeps track of what is used in a portion of address blocks, and create a protocol to use that address block, and then they can assign out of that block and not conflict. If someone wants to deploy these protocols, they will need to migrate anything uses addresses in that part of the space out of there. Norm Finn found that people are confused by that. There are no reserved bits in MAC addresses. There is only the Global/Local bit that is reserved. Anyone who is using local addresses today could conflict with any of this. All the proposals are about dividing up the address space, and existing users will be affected. Pat Thaler agreed that something needs to be done, and it's a huge resource. If the transition happens now, the number affected would be smaller. The next step would be to define a standard generic protocol for address acquisition. The RAC has already started doing this. They have defined 24-bit value similar to an OUI and the new Company ID (CID) is that the global bit always says so. One use is for local address blocks for protocols where we define vendor extensions. It does not have to be an OUI; it could also be a CID. The RAC has defined these CIDs, but there is not a lot of information out there about how to use them. There is a need for an amendment to 802. A proposed PAR on this called IEEE 802c. Juan Carlos Zuniga explained that the CID and OUI are similar, but not the same. Pat Thaler added that the difference is that in the OUI, the global/local bit is set to global, and in a CID the global/local bit is set to local. Jari Arkko asked if one has an OUI, can they just change that bit and make it a CID? Pat Thaler answered no; you need to go get the CID, which may not be the same name. Jon Rosdahl added that to complicate things, there were some companies that were grandfathered in from before the global/local bit was set. But that address space was not duplicated for the CID space. Pat Thaler added that while they are on the record because they were assigned, it is unlikely anyone is using them. Juan Carlos Zuniga explained that the intent is to create a new PAR where companies can request to play in the local space. Pat Thaler reported that a PAR was proposed, and the quadrant is one of the upper quadrants where they're assigning CIDs from. They can use a protocol that assigns out of that block, and use it as a default block for their protocol. This would create some reserved bits; you should only be assigning out of this block if you have this CID. And this [other] block is for local addresses, in the old way. Juan Carlos Zuniga asked: When you mention protocol, you mentioned avoiding collision of addresses. Could it also be an internal algorithm in the device? Pat Thaler answered that they are not talking about the protocol yet. And if you worry about continuity, don't change the address for the device every minute. It might say something about duplicate addresses. They are just laying down a roadmap. The next part of the work is to define a protocol. Norm Finn stated that something he would be interested in is whether in order to get one of these addresses, you need an identity. Pat Thaler answered that currently one issue about getting a MAC address is there is no way to get an address unless you already have a MAC address. She added that she will propose that we have a null address that is only used as a source address, and then bridges can ignore it as needed. And then we can use group addresses, multicast addresses for the destinations. Identifying the right response, with a multicast destination address, how does the client know which reply PDUs are for it? You don't want to have the same random number as someone else. Need a random number generator big enough that it's unlikely that two people would choose the same number at the same time. Norm Finn observed that if it's a matter of including your EUI-64, one of the justifications for this is privacy; this blows away the privacy. Pat Thaler stated that if you have an EUI-64, it's easier to come up with a random number, but she is not proposing this for privacy. Privacy from whom? And still need to authenticate from someone, and we may not be able to be private from them. If this is done under some sort of authentication, only the guy you're authenticating to would be able to see your true identity. Juan Carlos Zuniga reported that in the privacy group, one of the discussions that came out of this was about how Bluetooth keeps privacy on a changing MAC address. Once they have a peer addresses they can broadcast what looks like a random address but still recognize the things you already paired with. Jari Arkko intervened at this point, noting that we could discuss the privacy implications at length. One thing is to think about who you are private to. The question in his mind is: are there impacts of the new scheme to IPv6 addresses? Pat Thaler answered that the primary driver isn't privacy, though privacy may leverage it. She thinks this is transparent and the impact is minimal to IETF protocols that assume MAC address identities. Brian Haberman observed that RFC 7136 says there is no significance to any bit in the MAC addresses being used. Jari Arkko observed that if it is a dynamically changing thing, that's an impact. Pat Thaler stated that for the purpose of this one, you would do this when you came up and then only redo it if there was a network that came up and there was a duplicate address. Who is the address server? There would be 2 address servers. You could do an address-claiming kind of thing and you send a probe packet to see if anyone else is using this value. We'd have to deal with it, and there are some networks where you can't see everything. Some pretty rough protocols about how to do that sort of thing. An address server might see the claim, and try and find out whether you can claim an address or not. Duplicate address protection protocols: There should be a check and prevent a duplicate address, and the servers can partition from the local address space. For specialized stable networks, you don't want to do this overtime; you turn the key. Those are not networks where you should be expecting changes. IOT addresses should be able to operate without a global MAC address and without configuration. Juan Carlos Zuniga asked for the 24 bits and the small network with 1000 nodes, is there a presentation or is there a rough estimate? Pat Thaler said that for 24 bits you could probably be a good bit larger. If everyone has a separate one and you're trying to get yours, when you're adding it's a bit lower. Birthday paradox, you try again and are very unlikely to get the same one again. For 16 bits and 1000 nodes, it was very unlikely you'd have to choose more than 2 times. For 1000 nodes and 24, it's much lower. Norm Finn asked a question about IPv6. Do people who use IPv6 addresses ever make the assumption that these two addresses are the same? Brian Haberman observed that this happens only if they are doing pervasive monitoring. Norm Finn observed that this will break that. Many people in the room replied that that would be a good thing. Dan Romascanu asked if there any action items here? Jari Arkko observed that everything here is similar to what we've been doing with DHCP and DNA and same scenarios. There has been some evolution in this space. You do mobility and you come back to the network and have to quickly confirm. Lots of cases. Norm Finn asked whether, given you're going the same thing twice in a row at L2 and L3, do you need to have two of these? Jari Arkko answered that concerning privacy, if you don't change thing all at once you're going to link things together. Subir Das stated that where there is some kind of delay requirements, that angle needs some work investigating. Pat Thaler answered that unless you're changing it because of privacy standard that says you change it periodically to try to obscure who you are, you don't assume that MAC addresses define identity, because for some there it is not, it assigned when they get on the network. 10. Pervasive Monitoring Slides: http://www.iab.org/wp-content/IAB-uploads/2013/01/Privacy- ECSG-update-IETF-IEEE-Exec-meeting.pptx Juan Carlos Zuniga noted that the slides are an update that some may have seen parts of before. This is to get people on the same page regarding the EC privacy study group recommendations. At the last plenary meeting, 802 did a privacy tutorial. This was an outcome of the STRINT workshop in March. Despite the good work and interest, there was still a missing part on lower layer protocols. The Tutorial provided an update on the recent concerns about Internet privacy, the actions that IETF is taking, and the guidelines that are being followed when developing new specifications (e.g. RFC 6973 - Privacy Considerations for Internet Protocols). - It highlighted privacy concerns applicable specifically to Link Layer technologies, and provided suggestions on how IEEE 802 can help addressing them - The idea of developing an IEEE 802 recommended practices document, similar to the one produced by IETF (e.g. RFC 6973) was suggested and supported by several IEEE 802 members from different WGs. Juan Carlos Zuniga recalled that the 802 EC Privacy Study Group was created in July; he chairs this. It is chartered to run through November 2014, with the expectation of renewal until March 2015. The scope is to study privacy issues related to IEEE 802 technologies and consider the need for a recommended practice applicable to IEEE 802 protocols. If such a need is identified, the SG will determine whether the IEEE 802 criteria for standards development (CSD) support the initiation of a project and, if so, it will prepare a PAR for consideration by the IEEE 802 Executive Committee. Current topics include: - Threat Model for Privacy at Link Layer, - Privacy Issues at Link Layer, - Proposals regarding functionalities in IEEE 802 protocols to improve Privacy, - Proposals regarding measuring levels of Privacy on Internet protocols, - Implications of MAC address changes. The group is planning an opt-in trial using IETF and IEEE meetings networks to assess performance and implications of users' MAC address randomization. This is currently under discussion with the IETF NOC team. They are discussing implications to DHCP pools, states in network switches, MAC address collisions, ARP/ND, IPv6 addressing, AAA servers. The guideline would be to use specific tools that have known behavior. We may also need some specific tools for the trial; need to keep track of the number of users. Keep logs, these are the details we are figuring out. The planning team will have more discussions later on this week. If they think we have a good set of tools, they will likely give it a go for the next IETF meeting. The planning team has had one teleconference so far, as well as presentations at 802 interim meetings in Ottawa and Athens. There will also be 2 teleconferences before the next 802 plenary. Some resources: - EC SG Web Page http://www.ieee802.org/PrivRecsg/ - Mailing list (reflector) stds-802-privacy@listserv.ieee.org - Mentor (document repository) https://mentor.ieee.org/privecsg/documents - RFC 6973 - Privacy Considerations for Internet Protocols http://tools.ietf.org/html/rfc6973 Juan Carlos asked how to enforce privacy recommendations on future protocol standards. Kathleen Moriarty answered that the IETF is trying to do a mix of things. The Security Directorate reviews drafts, and SEC ADs and Alissa Cooper (RAI) are also looking for privacy concerns as well. Alissa Cooper clarified that at one point IETF tried to have a Privacy Directorate separate from the SecDir, but couldn't get it off the ground. We are trying to make people think both about security and privacy. In general it's not as formal as it is for security considerations. They talked about a dedicated privacy considerations section when working on RFC 6973, but decided there was already enough angst about the required sections of documents. Paul Nikolich repeated a question asked during the tutorial because it's core to this issue: How do we quantify privacy? Without a metric, how do we know if we're improving or not? Do you agree that that is an important consideration? Richard Barnes answered that having a way to measure things is important, but in terms of quantification, it isn't super helpful. When you solve a security problem, you're not moving a number, you're changing a risk profile. Juan Carlos Zuniga added that it's a difficult question to answer, and can turn philosophical very quickly. Look at the way the RFC was written, look at the threat model, and then provide some way to identify the risk. Jari Arkko agreed with Richard Barnes; the analysis is important, but it is qualitative rather than quantitative. He think this is exciting stuff, thank you for doing it. Jari asked Juan Carlos Zuniga if he has a feeling on whether this is workable or doable; can a system run and not have a problem with those things? Juan Carlos replied that they are optimistic. Jim Martin had a thought that if things work out well, next step is to incorporate it in the regular IETF network. The idea is that it is feasible, but we need to see how it will behave. Barry Leiba stated about having a threat model and knowing the privacy things that are sensitive is good. And as Alissa Cooper and Kathleen Moriarty noted, review is important as well. * * * Kathleen Moriarty presented an overview of the IETF work on pervasive monitoring. Slides http://www.iab.org/wp-content/IAB-uploads/2013/01/IETF- SecAreaPMOverview-MoriartyFarrell-0914.ppt Kathleen Moriarty explained the theme of encryption without authentication. Authenticated encryption is difficult. Encryption without authentication might look the same as the plain text would. Discussions on this topic are ongoing on the perpass mailing list. Barry Leiba replied that HTTPS will get you TLS, but that you won't see the key symbol indicating that a page is encrypted if you just use HTTP. Jari Arkko asked how the IETF and 802 can benefit from the work the other is doing. Juan Carlos Zuniga replied that the earlier point about changing the timing when one changes identifiers is the sort of coordination that will be needed to be more effective. Paul Nikolich added that this whole privacy area is a really good opportunity for tight collaboration between the groups. Dan Romascanu proposed that this kind of status presentation (e.g. Kathleen Moriarty's presentation linked above) to be presented at one of the SG calls, providing a list of pointers. Kathleen Moriarty added that diversity in personal experience improves the effort; she sees this in the IETF SecDir reviews. Different people pick up on different things. Paul Nikolich suggested a possible collaboration area on the threat models. Juan Carlos Zuniga answered that he and Alissa Cooper have been discussing this, and that he asked for her help on the threat model. Alissa Cooper reiterated Jari Arkko's earlier point that there isn't much point in solving a problem at one layer when there are still problems at all of the other layers. She added that just because something is hard does not mean that is a reason not to do it. The IAB has been thinking about what has been accomplished in terms of privacy and security. Subir Das asked for whom are we trying to provide privacy? The user, the device, or both? Alissa Cooper answered that they have been focusing on the individual. A device generally doesn't have need for privacy unless there is an individual associated with it. In RFC 6973, the IAB decided to concentrate on when something can be associated with an individual person. Kathleen Moriarty added that the threat model guided them towards that decision; that was the deduction after working through the scenarios. Alissa Cooper observed that the challenge is that when developing an app for a single use, one doesn't know how it will be used. Barry Leiba observed that even if one can't associate a MAC address with him, if one can associate a MAC address with a pattern of behavior, then that can lead to him. Jari Arkko noted that the point about correlation at multiple layers was not meant as discouragement. Norm Finn asked whether ,given the amount of information collected about a user by his apps, and the degree to which the apps can talk to each other--are we wasting our time on MAC address privacy? Barry Leiba answered that it's not the whole picture, but it's not a waste of time. Alissa Cooper concluded that we are looking at ways to de-correlate some of these application identifiers, and that additional efforts in the MAC address space would be useful as well. 11. Action Items, Future Meetings, and Planning Work Ahead NEW ACTION ITEMS: - Ted Hardie and Juan Carlos Zuniga to put together a detailed description for item 23 on the shared areas work list, on naming in Layer 2 networks. - Adrian Farrel and Glenn Parsons to provide a description for item 25 on the shared areas work list, on 802.1. and PCE. - Glenn Parsons to follow up with Adrian Farrel and the expert reviewers for the IS-IS TLV registry about getting an assignment for 802.1. - Glenn Parsons to send a detailed description of the 802.1 IS-IS TLV issue to Dan Romascanu for addition in the shared work items list. - Juan Carlos Zuniga, Stephen Farrell, and Alissa Cooper to write up a description for the shared work items list on pervasive monitoring. The group discussed possible future meeting dates. Dan Romascanu noted that IETF and IEEE 802's meeting calendars will not have them on the same continent at the same time anytime in the next two years. The group discussed whether face-to-face meetings were still necessary, since there are also the interim conference calls. The group deferred making a decision on future face-to-face meetings until after the next conference call, tentatively scheduled for January 2015.