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

From: Paul Sangster <[email-masked]>
Date: Mon, 12 Dec 2011 16:52:08 -0800

Thanks for the comments, some comments/proposed solutions are below...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Carolin Latze
> Sent: Friday, November 04, 2011 1:38 AM
> To: [email-masked]
> Subject: Re: [Nea] Extending WG Last Call on PT-TLS I-D
> 
> 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

[PS:] Good idea, we propose adding a SHOULD reference to the soon-to-be-RFC TLS heartbeat (currently draft-ietf-tls-dtls-heartbeat) to address this item.

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

[PS:] We already included this reference at the first use of PB-TNC higher in the document.

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

[PS:] Thanks, we'll fix that.

> 
> 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
> >
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea

---

From: Paul Sangster <[email-masked]>
Date: Mon, 12 Dec 2011 16:57:12 -0800

Susan,

Below are the proposed fixes to the issues you've identified...

> Sent: Friday, November 04, 2011 3:56 PM
> To: Stephen Hanna; [email-masked]
> A few editorial comments below.
> 
> Thanks
> Susan
> ------------------
> 
> Section 1.1:
> Remove last sentence. Don't think it is needed anymore.

[PS:] Agreed, will remove

> 
> 
> 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.

[PS:] Will remove

> 
> 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.

[PS:] This is a list of TCP/IP transport features.  It doesn't mean that assessment layer protocols make full use of them.   We will change to highlight how NEA protocols use this feature to support asynchronous initiation of posture exchanges within a single connection") as you proposed off-line.

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

[PS:] I think this is regarding the second paragraph of 3.3 and we will fix that.

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

[PS:] Will change to "its"

> 
> 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.

[PS:] Will modify text

> 
> 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?

[PS:] Good catch, we'll fix this.

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

[PS:] Agreed.  Will change to:
"Subsequent assessments on the same session MUST use the negotiated version number and therefore MUST NOT send additional version negotiation messages."   I don't think there was a compelling reason for the SHOULD NOT that used to be in this sentence.

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

[PS:] Will change this

> 
> Section 3.9
> Two error messages with code #6

[PS:] Thanks, Carolin noticed this too.

> 
> Section 6.2:
> See comment on section 3.6.

[PS:] Will fix table to match 3.6

---

From: Susan Thomson <[email-masked]>
Date: Wed, 21 Dec 2011 10:23:45 -0500

Hi Paul

Thanks for addressing these comments.

Looks good to me.

Susan

On 12/12/11 7:57 PM, "Paul Sangster" <[email-masked]> wrote:

> [PS:] This is a list of TCP/IP transport features.  It doesn't mean that
> assessment layer protocols make full use of them.   We will change to
> highlight how NEA protocols use this feature to support asynchronous
> initiation of posture exchanges within a single connection") as you proposed
> off-line.
> 
>> 
>> Section 3.3:
> "Subsequent assessments on the same session MUST use the negotiated version
> number and therefore MUST NOT send additional version negotiation messages."
> I don't think there was a compelling reason for the SHOULD NOT that used to be
> in this sentence.
> 
>> 
>> Section 3.8.3