[Nea] IETF 75 NEA minutes

[Stephen Hanna <shanna at juniper.net>]

Here are the minutes from the NEA WG meeting at IETF 75.
Thanks to Paul Hoffman and Stefan Winter for taking them.

If you have any comments or corrections to these minutes,
please send them to the NEA list before September 9.

Take care,

Steve

Minutes from NEA WG Meeting
IETF 75 in Stockholm, Sweden
July 27, 2009, 5:40 PM - 7:40 PM
Chaired by Steve Hanna and Susan Thomson
Notes taken by Paul Hoffman and Stefan Winter

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 for IETF 75 NEA WG meeting
=================================

Date: Monday, July 27, 2009
Time: 1740-1940 CEST (GMT+0200)
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

1740 Administrivia
         Blue Sheets
         Jabber & Minute scribes
         Agenda bashing
1745 WG Status
1750 Discuss PB-TNC (IETF LC and IESG comments)
     http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-04.txt
1820 Discuss PA-TNC (IETF LC and IESG comments)
     http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-04.txt
1850 Discuss proposed charter updates  
1915 Process for soliciting proposals on Posture Transport protocol
1930 Review Milestones and Next Steps
1940 Adjourn

The agenda was reviewed with no change. Minute takers volunteered.

Susan Thomson reviewed WG status. Since IETF 74, we have
published -04 drafts for PA-TNC and PB-TNC that reflect the
WG consensus for response to comments received during WGLC.
After this, we submitted the specifications to our AD,
who forwarded them to IESG with a request to consider
them for publication as Proposed Standards. An IETF LC
was held from June 9 to June 23 and several comments
were received, including a Gen-Art review and IANA
comments. After this, the documents were scheduled
for an IESG telechat but they have been deferred due
to several COMMENTs and DISCUSSes received from IESG
members. We will discuss the IESG comments today and
agree on resolutions on the mailing list. More IESG
comments are expected.

Since we have completed all the milestones in our
charter, we have drafted a charter revision that
calls for us to begin work on PT, the Posture
Transport protocol. This charter revision was sent
to the NEA WG for review and support was received.
We will discuss the proposed charter changes today.

Steve Hanna gave a quick overview of the NEA reference
model and showed an example of PA-TNC messages nested in
PB-TNC messages inside PT.

Steve reviewed the comments received on the -04 version
of PB-TNC. First, he pointed out that the changes in that
document were previously presented at IETF 74 and reviewed
on the mailing list. During IETF LC, a comment was received
complaining that the text in section 1.1 regarding the TCG
is confusing and ambiguous, especially with respect to change
control. The proposed resolution is to remove this section
and add a note in the acknowledgements section thanking
the TCG for submitting the first draft of this protocol.
IETF has change control for PB-TNC but there's no need
to point that out since that's always true for RFCs
unless there's a note to the contrary. No comments
were received on this proposal.

The IANA also provided comments during IETF LC. First,
they caught several mistakes: values that were included
in the main part of the spec but left out of the IANA
Considerations section. Those will be added to the
IANA Considerations section. Second, they raised a
concern with our instructions that said that when
a vendor submits a request to register a vendor-specific
value in one of our registries, the IANA should archive
the vendor's spec describing that value and then make
that spec publicly available if the vendor stops doing
so. In their IETF LC comments, the IANA said they don't
have a process for archiving specs. However, after further
consultation they have decided that they do have a
process for this. It's just very new so some IANA
employees didn't know about it yet. So this is no
longer a problem.

Susan Thomson pointed out several issues with PB-TNC.
First, she pointed out that the Retry-Acknowledge flag
is no longer needed now that we have moved to our new,
simpler state machine. The proposed resolution is to
remove that flag, returning that bit to the Reserved
field. No comments on that. Second, Susan pointed out
that section 4.1 of PB-TNC said to send Version Not
Supported errors in a PB-TNC message with version 1.
That conflicts with section 4.9.2, which says to send
those errors in a message with version 2. Section 4.9.2
is correct so section 4.1 will be fixed.

Moving on to IESG comments, Alexey pointed out that
we missed including a language tag to go with the
Remediation-String field since that's a human readable
string. BCP 18 (RFC 2277) says that we must provide
a way to indicate the language for human readable
strings so we will add a language tag to this string.

Alexey also pointed out that the Version Not Supported
error includes a range of versions (Min and Max) but
this won't work if the range of versions supported
includes one of the reserved values, like 0x09.
The proposed solution is to just say that the
reserved values listed in the PB-TNC spec are
understood to be omitted from the range. Teddy
Hogeborn asked whether it would be permitted to
provide a range of 2-13 if 13 is a reserved value
and what the meaning would be, if permitted. Steve
said that the meaning should be 2-13 with the
reserved values blocked out (i.e. 2-12 if 13 was
the only reserved value). Teddy asked for this
to be clear in the spec and Steve agreed.

Teddy also asked whether these protocols duplicate
most of SNMP. Steve said that there is some duplication
but SNMP can't run before an IP address is assigned.

The next IESG comment is that the PB-TNC spec doesn't
reflect our earlier decision to allow a single Posture
Collector to have multiple Posture Collector Identifiers
(and similarly for Posture Validators). The proposed
resolution is to fix this text in the PB-TNC spec.

Another IESG comment was that the error handling in
the PB-TNC spec is not as tightly specified as it
should be. We had lots of SHOULDs that should really
be MUSTs to maximize compatibility and minimize
confusion. We must be careful not to create infinite
loops where both sides loop sending errors because
they don't understand each others' errors.

Paul Hoffman asked for us to include a complete list
of the changes that we make during this process. Steve
agreed that the editors will send a complete list of
changes to the NEA mailing list.

Teddy pointed out that some fatal errors can't actually
be reported, for example when the underlying transport
fails. Steve agreed. We'll note that in the spec.

Next, we moved on to comments on the PA-TNC spec.
The first few comments were very similar to the
first comments on the PB-TNC specification: a
request to remove or clarify the TCG text in
section 1.1, a few values missing from the IANA
Considerations section, an IANA concern about
archiving vendor specifications, and a request
to have a language tag on the Remediation-String.
These will be resolved in the same way discussed above.

The first new comment is a suggestion that we
should require a Posture Collector to respond
to an Attribute Request (either with an error
or with the requested attribute) instead of
saying the Posture Collector SHOULD respond.
This seems like a good idea since it will make
it easier for a Posture Validator to determine
whether the Posture Collector is present (even
if it returns an error) vs. absent (in which
case no response will be received).

An IESG member suggested that we include a
warning about the dangers of accepting and
executing automated remediation instructions.
The proposed resolution is to include such a
warning in the Security Considerations section
and probably also in the section that describes
remediation instructions.

The next IESG comment was a question about the
status of the PA-TNC Security draft. Apparently,
we didn't remove all references to this draft
when we decided to drop it last year. This will
be fixed by removing those references.

Then there was another request to tighten up
our error handling. Yes, we'll do that, as
described under PB-TNC above.

The next request was to use the Field Types defined
in section 3.6 throughout the document. The editors
have been discussing this. Some of us think that this
is a good idea since we reuse these types several
places in the spec and Posture Collector vendors
might want to reuse those types in their vendor
specific values. Others of us think that we don't
actually reuse many types, other than unsigned
integers which are easy to specify. Since we don't
agree on this, the editors that favor reuse will
try editing the spec to have reuse. Then we'll all
review this revised specification to see if it's
better. If so, we'll keep it. If not, we won't.

Teddy asked that if we're going to define our own
terms, we should choose names that make it clear
when we're talking about our special kind of date
or string type and when we're just referring to
dates or strings in general. Steve agreed.

Yoran Sheffer asked that when we remove section 1.1
and add an acknowledgement for TCG, it would be good
to retain the text that explains the relationship
between the TNC specifications and this document.
Tim Polk (our Area Director) said that the IESG would
rather not include this text since it raises too many
issues. First, the IETF shouldn't be making statements
about what the TCG is going to do in the future.
Second, it's hard to predict what the relationship
between IETF and TCG will be in the future. We hope
that it will be good but we can't say for sure.
It's better to just say that the specs came from
TCG. That's a fact that will always be true.
Paul Hoffman agreed that it's better to take out
this text since it's very hard to predict the
future. We might fork in the future. We hope not
but we can't promise anything.

Another issue pointed out by the IESG is that we
should select Designated Experts. The best process
for doing this is for the WG chairs to recommend
nominees to the Area Director, who will pass those
recommendations on to the IESG, who will decide
and appoint the Designated Experts. Steve asked
if there are any volunteers for this position.
He described the duties also. Nobody spoke up.
Steve and Susan will go find some volunteers.

The last issue was some minor typos, clarifications,
and inconsistencies that must be fixed. Those will
be fixed in the next draft of the documents, which
will be sent around for WG review.

Susan presented the goal of the charter changes. Our
current charter says that we should select a PT
protocol defined by others. That's not quite right.
We want to run our PT protocols over existing transports
but some NEA-specific work will be needed. We must
define how PB should be carried over those existing
transports (like EAP or TLS or whatever). The goal
of the proposed charter changes is to explain that
and set out a process and timeline for the NEA WG
to develop PT protocols, which will be thin layers
over existing transport protocols. The gist of this
proposed charter was discussed at IETF 74 and the
actual text has been reviewed on the NEA mailing list.

Susan reviewed the actual text in the proposed charter
changes. A discussion ensued on the change from "one"
mandatory to implement PT protocol to "at least one".
The problem is that some customers want to do posture
assessment before assigning an IP address to the NEA
client (probably using an EAP-based transport) and some
want to do posture assessment after an IP address has
been assigned (probably using an IP-based transport).
Some want to do both. If we select only one mandatory
to implement PT protocol, one of these groups of customers
will be disappointed. Tim said that we should leave
the charter flexible so that we wait until we have
some concrete protocols before we make our decision.

Yaron said that leaving this charter text flexible might
cause us to adopt two equivalent transport protocols.
Steve and Tim both said that they will push hard to
avoid having two transport protocols unless there is
a very strong reason to do so, such as if there are
two incompatible use cases. Paul suggested saying that
we should require one PT protocol for layer 2 and one
PT protocol for layer 3. Tim said that we may end up
there but probably shouldn't put that in the charter.

Susan reviewed the new milestones. The plan is to use
a process to get PT protocols that is similar to the
process that we used for PA and PB protocols. We'd
solicit proposals that meet our requirements in
September with submissions due in October. At IETF 76,
we'd review the submissions and decide what to do
for WG drafts. Then we'd aim for rapid development
of the specifications, probably including a virtual
interim meeting in January. If all goes well, we
should be able to do a WG LC on the specifications
in March, resolve the comments at IETF 77 in April,
and submit the specs to the IESG in May 2010.
Paul pointed out that the first milestone needs
an "s" on the end ("protocols" not "protocol").

Tim said he thinks the draft charter is ready for
IESG consideration. They may decide that it needs
changes or that it needs an IETF LC. We'll see.

We did a hum on whether the charter changes proposed
by Susan are acceptable. The hum was unanimous that
the charter changes are fine.

We discussed the timing of when to have the IESG
consider the charter and when to have them look
at modified versions of PA-TNC and PB-TNC. After
some discussion, it was agreed that we can not
get PA-TNC and PB-TNC revisions through WGLC
by August 13, especially since we still have not
received comments from several IESG members.
Therefore, we'll ask the IESG to send us their
comments on PA-TNC and PB-TNC ASAP. We'll make
changes to address their comments, post new
versions of PA-TNC and PB-TNC, do WGLC, and
then ask for them to be on the IESG telechat.
We'll ask the IESG to consider our charter
changes on August 13.

Teddy asked about whether we could reuse data
structures from MIBs, since there's lots of overlap.
Steve said that there's not actually that much
overlap. Teddy thinks there is some. And even
if there aren't MIBs for this, maybe we should
just define MIBs and use those in our protocol.
Tim said that the OPS and Management ADs didn't
seem to think this was a solved problem. Also,
the Security Area doesn't have a good track
record on defining MIBs. And we have a good
set of protocols that should work well.

Meeting adjourned