Subject: Re: [wpkops] Draft charter last call

From: =JeffH <[email-masked]>
Date: Mon, 03 Dec 2012 10:51:55 -0800

I agree with Sean's comments.

regarding PaulH's comments..

 > references are normally not used in IETF WG charters

agreed overall with the point above in that there /are/ a few charters that have
included such.

 > The references here could easily be removed

I don't think the given references hinder the charter and it's useful to have
them at least clearly noted.

 > Capturing state changes that are visible to the user doesn't seem to be part
 > of "trust model", "certificate, CRL, and OCSP field and extension
 > processing", "certificate revocation", or "TLS stack operation".
 >
 > Possibly the last document could be expanded to "TLS stack operation and
 > interaction with the browser". Alternately, a document about visible state
 > changes in web browsers could be added to the list of documents. A third
 > option is to drop the paragraph if the group believes that adding this would
 > be to difficult to do cleanly.

I don't think we should drop it, we discussed this at fair length during the BoF..

 > The discussion went to whether or not aspects of UI should be considered
 > in-scope.  It was decided that functional aspects of user interaction should
 > be in-scope.  But aspects of style (such as colours and symbols) should not.

My supposition is that the "functional aspects of user interaction" will most 
likely be captured in the "TLS stack operation" document.  Altering the 
purported document topic as suggested above is fine by me.

HTH,

=JeffH

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Dec 2012 10:58:16 -0800

> agreed overall with the point above in that there /are/ a few charters that have

Indeed, there are now. So, ignore my request to remove them; they're fine.

--Paul Hoffman

---

From: Tim Moses <[email-masked]>
Date: Mon, 3 Dec 2012 21:11:49 +0000

Guys - I was also thinking that "field and extension processing" causes state changes that are communicated to the user.  So, rather than introduce an additional document to cover this requirement, I prefer to make sure it is adequately covered in the proposed existing set of documents.

I'll update the charter for final assent.

All the best.  Tim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Monday, December 03, 2012 1:52 PM
To: [email-masked]
Subject: Re: [wpkops] Draft charter last call

 > references are normally not used in IETF WG charters

agreed overall with the point above in that there /are/ a few charters that have included such.

 > The references here could easily be removed

I don't think the given references hinder the charter and it's useful to have them at least clearly noted.

 > Capturing state changes that are visible to the user doesn't seem to be part  > of "trust model", "certificate, CRL, and OCSP field and extension  > processing", "certificate revocation", or "TLS stack operation".
 >
 > Possibly the last document could be expanded to "TLS stack operation and  > interaction with the browser". Alternately, a document about visible state  > changes in web browsers could be added to the list of documents. A third  > option is to drop the paragraph if the group believes that adding this would  > be to difficult to do cleanly.

 > The discussion went to whether or not aspects of UI should be considered  > in-scope.  It was decided that functional aspects of user interaction should  > be in-scope.  But aspects of style (such as colours and symbols) should not.

My supposition is that the "functional aspects of user interaction" will most likely be captured in the "TLS stack operation" document.  Altering the purported document topic as suggested above is fine by me.

HTH,

=JeffH

_______________________________________________
wpkops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/wpkops

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Dec 2012 13:56:36 -0800

> Guys - I was also thinking that "field and extension processing" causes state changes that are communicated to the user.  So, rather than introduce an additional document to cover this requirement,…

Please note that the document that you thought covered "Capturing state changes that are visible to the user" is different than the one Jeff did. For example, I don't see how the state change of "starting TLS" to "TLS failed due to an expired certificate" has anything to do with "certificate, CRL, and OCSP field and extension processing". Jeff suggested that these visible state changes be in "TLS stack operation", which seems a heck of a lot more appropriate.

--Paul Hoffman