Subject: [Nea] DRAFT minutes of NEA WG meeting at IETF 70

From: "Susan Thomson (sethomso)" <[email-masked]>
Date: Sat, 15 Dec 2007 01:14:02 -0500

Below are the draft minutes of the NEA WG meeting at IETF 70.

Any updates, please let me know.

Thanks
Susan

-------------------------------------------

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: [email-masked]

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.

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea