[Nea] Draft minutes for IETF74

["Susan Thomson (sethomso)" <sethomso at cisco.com>]

Draft minutes for IETF74 have been posted at the WG web site
http://tools.ietf.org/wg/nea.
Also included below.

Please send revisions to me by Wed Apr 29.

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: Monday, March 23, 2009
Time: 1300-1500 PDT (GMT-0700)
WG Charter: http://www.ietf.org/html.charters/nea-charter.html
WG Tools: http://tools.ietf.org/wg/nea
WG email: nea at ietf.org

1300 Administrivia
     Blue Sheets
     Jabber & Minute scribes
     Agenda bashing
1305 WG Status
1310 Discuss PA-TNC (recent changes and WGLC comments)
   http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-03.txt
1350 Discuss PB-TNC (recent changes and WGLC comments)
   http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-03.txt
1430 Open Mic
1450 Review Milestones and Next Steps
1500 Adjourn

WG Status
=========

The PA-TNC and PB-TNC were updated based on changes discussed at the 
last IETF. 

Working Group Last Call for comments on the documents ended prior to 
the IETF with one comment.

Changes to -03 version of PA-TNC I-D:
=====================================

Kaushik Narayan reviewed the changes made to the -03 version of PA-TNC.

There were the following changes:
1. IANA Considerations no longer require a RFC. Expert Review with 
Specification is required. The specification must be permanently and 
publicly available and likely to ensure interoperability. IETF standard 
values must be useful and not harmful to the Internet.

2. The section on evaluating the PA-TNC protocol against NEA 
requirements per RFC 5209 has been moved to the Appendix

3. Pre-RFC 5378 text has been added to the first page

WGLC Comments on -03 version of PA-TNC I-D:
===========================================

WGLC Comments included the following proposed changes:
1. SHOULD to MUST: A message recipient MUST use the same version number 
in a response if the version is supported. If the version is not 
supported, a message recipient MUST respond to the message with a 
Version Not Supported error message using version 1. 

2. Version Discovery: The -03 version of the I-D specifies that a 
sender can use a special-purpose message with version 0 for version 
discovery. This is in addition to the ability to send a message, and, 
if the version is not supported, receive a Version Not Supported 
error message containing the min-max range of versions supported by the 
recipient. In the interests of simplicity and to avoid redundancy, the 
proposal is to remove the version 0 mechanism since it is not deemed 
necessary to have two ways of performing version discovery.

Steve pointed out that the motivation for having the two mechanisms in 
the first place was to provide a means of performing version discovery 
without triggering an error.

Kaushik asked for those in favor of retaining Version 0 discovery to 
comment. Nobody did.


3. The WGLC comments also proposed some minor wording changes.

All of the above proposed changes to be confirmed on the mailing list.

Changes to -03 version of PB-TNC I-D:
=====================================
Steve Hanna reviewed changes to the PB-TNC specification.

The changes included the following:
1. IANA Considerations were changed in the same way as for PA-TNC 
described above.

2. The section on evaluating the PB-TNC protocol against NEA 
requirements has been moved to an Appendix

3. Pre-RFC 5378 text has been added to the first page

4. State machine change has been simplified

Steve reviewed the history of changes to the state machine. 

The -01 version of the state machine allowed the client and server to 
re-try in the middle of an assessment, but only the client could 
trigger a posture assessment after an assessment had completed.

The -02 version of the state machine made changes to allow the server 
to trigger an assessment after the completion of an assessment, but it 
led to synchronization errors when both the client and server trigger a 
re-assessment at the same time. 

The -03 version of the state machine addresses the issues with the -02 
version. However, this version only supports triggering re-assessment 
after an assessment has finished.

WGLC Comments on -03 version of PB-TNC I-D:
===========================================

WGLC Comments included the following proposed changes:
1. Make PB-TNC version handling the same as PA-TNC: Unlike PA-TNC, the 
-03 version of the specification has no support for version discovery. 
The proposal is for PB-TNC to adopt the proposal described above for 
PA-TNC. However, there will be some differences in the version numbers 
that can be used. Some version numbers will be reserved to accommodate 
prior usage.


2. PB-Assessment-Result and PB-Access-Recommendation MUST NOT appear in 
a batch of type other than Result (was SHOULD NOT)

3. PB-Access-Recommendation MAY appear in a batch of type Result (was 
SHOULD)

Steve asked whether these proposals seemed reasonable. There were no 
objections.


Susan asked for confirmation that an implication of the version 
handling above is that the version number field in PB-TNC would be 
modified to be the same size as that used in PA-TNC. 

Steve confirmed that the current size of 4 bits would be expanded to 8 
bits to be the same as PA-TNC.

Milestones
==========

The above proposals will be confirmed on the mailing list and -04 
versions of the protocol specs published in late March or early April. 
After that the specifications will be submitted for IETF Last Call.

Once the specifications have passed IETF Last Call and IESG 
consideration, the milestones in the charter are complete.

Next Steps
==========
To kick off the discussion, Steve described the 3-layer NEA framework 
for the benefit of those in the meeting who were not familiar with it. 

The PA protocol reports information about the environment of a NEA 
client (OS version, AV status etc) to the NEA server.

The PB protocol encapsulates this information in batches between client 
and server.

The PT protocol encapsulates the PB protocol for transport across the 
network.

The PA and PB protocols have been the subject of the working group 
charter to date. The WG needs to consult with the ADs regarding PT 
since the charter text and milestones need to be updated.

Tim Polk said that once the PA-TNC and PB-TNC specifications are done, 
re-chartering is likely to occur. The WG needs to define new text and 
milestones to accomplish this work. It is reasonable to expect that 
this work can proceed before the PA-TNC and PB-TNC I-Ds are fully 
approved by the IETF and IESG.

Stephen Farrell asked whether this can be accomplished prior to the 
next meeting.

Tim Polk said yes, this was possible. The charter needs to be approved 
by the IESG. The precise timing depends on the IESG meeting schedule, 
but it should be doable within a month. It is not unreasonable to 
expect that this can be done prior to the Stockholm meeting.

Susan asked whether the charter updates would be submitted to the IESG 
if the IETF Last Call did not go smoothly. 

Tim replied that he does not expect there to be problems during the 
IETF Last Call, but if there are, the charter updates will not be 
submitted to the IESG until the IETF Last Call comments are resolved. 

Steve asked whether the revised charter would be considered if the IETF 
Last Call went smoothly, but the IESG had comments. 

Tim said that he would be prepared to consider re-chartering in this 
case, but it would depend on what the IESG comments were. He does not 
want the WG to lose momentum between now and the Stockholm meeting. The 
intent is for the charter revisions to trail closely behind the RFC 
approval process. 

Jerry Thrasher referred to a sentence in the charter that indicates 
that PT is a deliverable. There is wording in the current charter that 
says that the WG will identify and specify the use of one mandatory to 
implement PT protocol that is fully documented in an RFC. 

Steve explained that the intent of this wording was to say that the WG 
was not in the business of specifying a new transport protocol, and 
that the WG would identify one that already exists. 

Kaushik pointed out that it is likely there will be multiple PTs 
needed, e.g. one pre-access control, and one post-access control. Many 
existing implementations implement multiple protocols already. The 
charter currently specifies one mandatory to implement posture 
transport protocol. Would it be acceptable to have multiple?

Tim answered that it is better to have a minimal set of mandatory to 
implement protocols. It makes sense for there to be one, unless there 
are strong reasons to the contrary.

Kaushik said that different PTs are optimal in different circumstances.
He asked whether it would be acceptable for the WG to specify more than 
one PT, even if only one was mandatory to implement.

Tim said yes, he would be comfortable with that.

Yaron Sheffer asked whether the TNC documents would be updated to match 
that of the IETF documents.

Steve said that the TNC documents are in public review status, which 
mean they are in draft form. The goal is to make them semantically 
equivalent to that of the IETF, even though the text of the 
specifications may be different.

There was a question whether IF-MAP as defined in the TNC would be part 
of the revised charter. 

Steve responded that this is not currently within the scope of the 
charter and will probably not be part of the updated charter at this 
time.

Kaushik asked whether the charter would be opened up for other items 
such as a protocol between the Posture Broker Server and Posture 
Validation Server.

Tim answered that there is nothing to preclude other work items from 
being considered during the re-chartering process, but he is not 
inclined to support opening up the kitchen sink at this point in time 
unless there is strong WG consensus to do so. Rather, the working group 
should focus on defining a PT.

Kaushik asked whether it would cause problems to re-charter again to 
include new work items, if the WG found that this was necessary in the 
near future. 

Tim said he would be open to re-chartering again, adding that WGs 
should probably re-charter more often than they do. It does not have to 
be done serially as has been the case so far.

Kaushik said that assertion attributes and data acquisition mechanisms 
are two examples of work items that have been discussed in the WG, but 
have been deferred to date. 

Tim said we should not get ahead of ourselves until there is WG 
consensus to do so.

Kaushik asked whether there is a problem with the fact that the 
protocol name contains the name of a non-IETF organization, and whether 
there is precedent for this.

Tim did not believe this was a problem, but should verify it. 

Discussion is to be continued on the mailing list.

Meeting adjourned.