Subject: Re: [Nea] Extending WG Last Call on PT-TLS I-D

From: Carolin Latze <[email-masked]>
Date: Fri, 04 Nov 2011 09:37:36 +0100

I did not read the complete draft again, but checked it mainly against 
my last comments:

- section 3.1.1: would it make sense to specify how to keep the TLS 
session alive? I think it might be helpful to ensure interoperability

- section 3.6, type 8: maybe add "[RFC5793]" so that readers know where 
to find the PB-TNC spec

- section 3.9: error code 6 exists twice (SASL Mech Error & Auth Need)

regards
Carolin

On 10/31/2011 03:58 AM, Stephen Hanna wrote:
> No comments were received during this WGLC. That makes it
> hard for the WG chairs to determine what the consensus of
> the WG is with respect to this document. We have agreed to
> extend this WGLC until 5 PM PDT on next Friday, November 5.
>
> Please take this opportunity to review this document and
> provide your comments, even brief ones such as "fine work"
> or "needs more details in section 5".
>
> Thanks,
>
> Steve
>
>    
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Susan Thomson
>> Sent: Wednesday, September 28, 2011 6:24 PM
>> To: [email-masked]
>> Subject: [Nea] Starting WG Last Call on PT-TLS I-D
>>
>> A new version of the PT-TLS I-D has recently been posted based on
>> comments
>> received at the last IETF meeting.
>>
>> This message is a WG Last Call for comments on this draft:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-01.txt
>>
>>
>> The Last Call period will run for 4 weeks ending on Wednesday Oct 26 at
>> 5pm
>> PT.
>>
>> Please send your comments and suggestions for updated text to the NEA
>> WG
>> mailing list by the above date. Issues will be addressed on the mailing
>> list
>> and at the next IETF meeting in November.
>>
>> Please take the time to review the I-D carefully and suggest
>> improvements.
>>
>> Thanks
>> Susan
>>
>> _______________________________________________
>> Nea mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nea
>>      
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
>

---

From: Susan Thomson <[email-masked]>
Date: Fri, 04 Nov 2011 18:56:22 -0400

A few editorial comments below.

Thanks
Susan
------------------

Section 1.1: 
Remove last sentence. Don't think it is needed anymore.

Section 2.1:
First sentence:
EAP is not necessarily run directly over link layer. Hence, for generality,
remove "link layer oriented bindings such as" from first sentence.

Bullet list, first item:
While PT-TLS is full duplex, PB-TNC does not take advantage of this except
for async initiation of posture exchanges. Correct? If so, you may want to
make this clearer.

Section 3.3:
First sentence: Do you mean Posture Broker *Client* here?

Section 3.4.2.2
First sentence: "it is" -> it's

2nd para: First few sentence repetitively uses the word "client". In one
case, I think you mean PT Server, and in other cases, I think one can drop
referral to authentication "of the client"  without loss of clarity.

Section 3.6
Message Type 10: In description, do you mean "recipients of type *10* or
higher ..."? The message type IDs are different from that listed in Section
6.2. I think Section 6.2 needs to be corrected?

Section 3.7
Last sentence: Change the SHOULD NOT to a MUST NOT?

Section 3.8.3
Ist para, 2nd last sentence: Typo "if it believes *it* is"

Section 3.9
Two error messages with code #6

Section 6.2:
See comment on section 3.6.

---

From: Stephen Hanna <[email-masked]>
Date: Sat, 12 Nov 2011 08:02:40 -0500

Susan and I have reviewed the WGLC results for PT-TLS.
Although only two responses were received, both were
generally positive on the document with only minor
comments. The issue of keepalives and the question of
SHOULD NOT vs. MUST NOT in section 3.7 seem to be the 
only substantive comments.

We have asked the document editors to prepare a
presentation for IETF 82 and an email to the list
summarizing the issues raised during WGLC and
providing proposed resolutions. Once these issues
have been resolved in the WG, the document editors
will post a new version of the draft which can go
through a quick WGLC if substantive changes were
made. Assuming WG consensus is reached, we will
then submit the document to the IESG.

Thanks,

Steve