These notes do not attempt to duplicate the content of the slides. Instead, they summarize the material presented, and focus on comments and discussion. Agenda: Date: Wednesday, December 5, 2007 Time: 1300-1500 WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 1300 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 Discuss WGLC comments on NEA requirements draft http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-05.txt 1410 Next Steps 1440 Discuss requirement for mutual network endpoint assessment http://www.ietf.org/internet-drafts/draft-wei-nea-mnea-00.txt 1500 Adjourn WG Status: Steve reviewed WG status since the last IETF. The milestones since the last IETF (IETF69) are as follows: --- First WGLC 7/13/2007 - 8/10/2007 --- draft-nea-requirements-04.txt published in August 2007 --- draft-nea-requirements-05.txt published in November 2007 --- Second WGLC 11/5/2007 - 12/3/2007 One comment (generally positive) was received during the second WGLC. If no substantive issues are raised during this meeting, the next step is to take the draft to the IETF Last Call. NEA requirements draft: Prior to review of -05 version of draft, Steve asked for a show of hands who had read any version of the requirements draft. Approximately 10-12 people raised their hand. When asked who had read the -05 version of the document 5-6 people raised their hand. Mahalingam Mani reviewed the changes to the requirements draft since the last IETF when the -03 version of the draft had been discussed. He summarized the changes to the common requirements, the PA requirements, the PB requirements and the PT requirements. Mani then reviewed all the requirements as specified in Section 7 of the document. Questions and comments were as follows. Common Requirements: Hao Zhou had a question on C-7 regarding what a large number of attributes actually means. Mani stated there is no specific number in mind. Steve suggested that we not stall moving the draft through the IETF process, but in parallel discuss what metrics we desire to hit. Tim Polk said that we shouldn't be too specific on what metrics to hit at this point, since it may box us in unnecessarly. The intent of the requirement is to guide protocol design choices. Gary Tomlinson said the numbers could be larger than one expects. Based on implementation experience, they had guessed wrong on how much traffic would get exchanged. Tim stated that requirements are a statement of intention not hard metrics. During protocol discussions, the WG must make sure these requirements are not overlooked during the design stage. Yaron Sheffer said that C-9 covers C-10. Doesn't feel we should specify encoding type. Tim Polk disagreed. He sees value in C-10. Paul Hoffman pointed out that language and encoding are two different concepts, therefore C-9 and C-10 are distinct requirements. The requirement for UTF-8 encoding (C-10) is needed for interoperability, since in some countries there may be a preference for a national encoding. The requirements draft needs to say that an implementation must support UTF-8. PA Requirements: There were no comments on PA requirements. PB Requirements: Susan commented that PB-1 reads as being uni-directional, whereas the intent is that it is bi-directional. This can be easily fixed by saying that communication is between PBC and PBS, rather than saying communication is from PBS to PBC. Mani said that bi-directional assessment is actually covered by requirement C-1. PT Requirements: There were no comments on PT requirements. Next Steps: Steve asked for a hum in the room regarding whether the -05 draft was ready to be sent to the IESG for IETF Last Call and then for consideration for approval as Informational. The hum was unanimous in favor of moving the document forward. Steve declared, based on this hum and on previous discussion on the WG email list, that there is WG consensus in favor of moving the draft forward. Tim stated that having just one comment in four weeks is indicative that the document is done, and that he approves of sending the document to Last Call. Steve to send document this afternoon to AD. Steve presented proposed milestones for the upcoming protocol work including submission of candidate proposals for PA and PB in February prior to the next IETF in March. These proposed milestones assume that the IETF Last Call goes smoothly and no substantive updates are required to the requirements draft. Tim Polk suggested some rewording of milestones as presented in the slides relative to IESG timelines. Tim also stated that we can start work on protocols one the IESG receives the requirements document (after IETF LC comments have been resolved). Gary asked a question about where Internet Drafts for PA and PB may come from. Tim Polk said these are from individuals. They may come from other SDOs, assuming the Drafts meet IETF requirements. Copyright issues are sometimes a sticking point. Stefan Santesson suggested reordering the last couple of milestones to show that the protocol submissions are submitted to IESG prior to IETF Last Call. Mutual network endpoint assessment: Ke Jia (Jack Chia) presented an individual submission on mutual network endpoint assessment (draft-wei-nea-mnea-00.txt). This work currently lies outside the scope of the charter. The intent of the presentation was not to request a change in the charter, but to gather feedback on the use case. Mauricio Sanchez asked the question how this would this apply in a hot-spot ISP use case. Specifically, what which attributes would the endpoint request from the AP? Hao Zhou responded that he thought the intended use case is for peer-to-peer applications such as file sharing. Paul Hoffman added that mutual posture validation might be useful for protection in this use case, e.g. where sharing executables. Paul mentioned that peer-to-peer communications may be directed via a server, and asked whether a peer-to-server communication would cover this use case. He also asked whether there is IPR associated with the submission. Ke Jia said no. Gary said the idea was interesting, but that the challenge would be operational in nature, e.g. managing trust relationships and policies. Nancy Cam-Winget on behalf of Kaushik Narayan asked what the trust model is? Jack said this had not been considered yet. Tim said this is interesting work and a potentially useful idea, and worthwhile to get input from the WG and investigate further. However, he would not support the addition of this use case into the requirements document at this point in the process, as it is research and will negatively impact the milestones. There is nothing preventing a protocol design from supporting this use case. Jack agreed and is just looking for feedback at this point. Meeting adjourned.