IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-02-16. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: EKR, Benoit
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
7a. Other Business
1058 EST Adjourned
(at 2017-02-16 06:00:02 PST)
draft-ietf-6tisch-minimal
- Figure 5: Don't you need to specify units? - section 8: I see no point whatsoever in saying "Details are out of scope, but the link layer must provide some flexibility here." What is an implementer supposed to do with that? - section 8: You ought add a reference to the spec that explains how a JN that doesn't know K1 or K2 still fails the joining process for a fake EB. - section 8: "MUST be avoided" is bogus, you ought rephrase that with a MUST NOT I think (or a SHOULD NOT maybe if combined with the exception in the next sentence).
I agree with Mirja's comments about the use of Normative Language and believe that for a BCP document its use is not clear enough such that it could result in different "compliant" implementations that may not interoperate properly. So I am making the issue a DISCUSS. As Mirja mentioned, this statement in the Introduction opens the door for other configurations: "Any 6TiSCH compliant device SHOULD implement this mode of operation." The question to answer for this "SHOULD" (and others) is what are the particular circumstances when ignoring this recommendation is ok. The document doesn't elaborate at all on details. I understand that there are in fact other posible configurations, but if this document is describing the Best Current Practice then I think it should be explicit as to what that BCP is. Another example of the lack of clarity (besides those already mentioned by Mirja) is the use of RPL: The Introduction mentions that "RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network.", but Section 5 (RPL Settings) makes it optional: "In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used."
s/I-D.ietf-6lo-routing-dispatch/I-D.ietf-roll-routing-dispatch
- Substantive Comments -- Section 4, 2nd paragraph, "A node MAY use different values": Is that intended to weaken the RECOMMENDED in the previous sentence? (If not, then is the MAY needed at all?) -- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you articulate why it might be reasonable to make other choices? -- 4.5.2, 3rd paragraph, "It MAY be necessary..." That seems like a statement of fact. Please consider non-2119 language. --- 4th paragraph: It's not clear to me if the MUST in "MUST be sent as per the 802.15.4 specification..." is constraining options from that specification, or just referring to requirements that exists in that specification. If the latter, please consider descriptive rather than normative language. (e.g. "The 802.15.4 specification requires...." -- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make sense not to follow those rules? - Editorial Comments -- Abstract: Please expand 6TICH on first mention
While reading, I frowned upon the same MAY & RPL issue as mentioned by Alvaro: The Introduction mentions that "RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network.", but Section 5 (RPL Settings) makes it optional: "In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used."
Thanks for responding to the SecDir review, it looks like the updates needed are planned for the next version. There were a number of significant findings, so this placeholder is to make sure those happen (protocol and security). https://www.ietf.org/mail-archive/web/secdir/current/msg07162.html For some reason, the SecDir review isn't linked off of the document.
A couple of comments mostly on the use of normative language: 1) The following sentence contradict a little all other normative language in this document (basically making everything a SHOULD): "Any 6TiSCH compliant device SHOULD implement this mode of operation." Why is this a upper case SHOULD? Is this sentence needed at all? 2) Here the usage of normative language is also not clear to me: "The default values of the TSCH Timeslot template (defined in [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. A node MAY use different values by properly announcing them in its Enhanced Beacon." 3) Is it correct that these are SHOULDs? "EB Destination Address field SHOULD be set to 0xFFFF (short broadcast address). The EB Source Address field SHOULD be set as the node's short address if this is supported. Otherwise the long address SHOULD be used." 4) What the recommended value for EB_PERIOD?: "In a minimal TSCH configuration, a node SHOULD send an EB every EB_PERIOD." 5) This is also a weird SHOULD for me: "EBs SHOULD be used to obtain information about local networks, ..." What else should be used? Or you just don't obtain the information you need. I actually guess that you should simply use a lower case should in this sentence. Should it be?: "The default values of the TSCH Timeslot template (defined in [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. If a node uses different values, it MUST properly announcing them in its Enhanced Beacon." Or is this sentence just duplicating the SHOULD of the previous sentence slightly differently? 6) Maybe also name the recommended values for MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT in section 6.2 or give a forward reference to section 7.3? 7) "At any time, a node MUST maintain connectivity to at least one time source neighbor. " How can you ensure that you can maintain connectivity? I guess this must be a SHOULD... or what do you mean exactly by 'maintain connectivity'? 8) I think this sentence is confusing given the recommended value for NUM_UPPERLAYER_PACKETS is 1: "One entry in the queue is reserved at all times for frames of type BEACON." I guess what you want to say it that if a BEACON should be send and there is no space in the queue one frame should be drop and the BEACON should be queued instead? 9) I'm a little surprised to not see anything about 6LoWPAN in the body of the document (besides the intro in section 1). Shouldn't there also be some normative language on the use of 6LoWPAN? One editorial comment (from the abstract): I don't really understand this sentence "A minimal mode of operation is a baseline set of protocols, ..." I guess you want to say something like "This minimal mode of operation specifies the baseline set of protocols that need to be supported, .."
sounds like 20 works for us thanks.
draft-ietf-sidr-rpki-rtr-rfc6810-bis
This looks like it obsoletes RFC6810 or perhaps updates it. The draft header should show this so RFC meta-data is accurate.
Review based on diff. [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc6810&url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt - 5.1: To get around the hard-coded-sha1 thing could we do the same with the 20 byte SKI value as we did on some other recent RPKI spec? (IIRC, that was to say that if actual SKI is longer truncate left, and if shorter pad left with zero, but please check.) - section 9: What's the background to removing the statement that one of TCP-AO ssh etc SHOULD be used? What is the reality of deployments here? I assume it is not TCP-AO anyway but does TLS or SSH get used? - various places: I think 6810 was correct in using "that" and not "which" in many places. I realise that's a fairly frequent style thing that gets toggled though, but I bet the RFC editor sets a load of those back to "that" :-)
Thank you for a well written document. I share Mirja's concern about versioning, her concern is related to my comment below. Regarding obsoleting the original RFC: I am Ok with not doing that if both are going to be used at the same time, but I would like to hear from the WG whether this is the case. I have one small issue I would like to discuss: In section 7: what are the conditions for bumping the version number to 2? I think the document is missing some criteria for what would require a version change.
I have read through the document and I still was unable to figure out what the Max Len field for the IPvX PDUs is being used for. It is defined as Max Length: An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element. but I was not able to find any processing rules for this. i.e. what it is actually used for. An example would greatly help.
I share Mirja's questions about versioning, and whether this updates or obsoletes 6810. - 5, 2nd paragraph: Why is the SHOULD not a MUST? When might it make sense not to ignore the contents of a reserved field? - 5.1, 6th paragraph: I'm not sure I understand the use of the word "commensurate" in this context. - 9.2: Seems like a reference to RFC 7525 would be useful here.
On top of the OPS DIR feedback from Stefan at https://datatracker.ietf.org/doc/review-ietf-sidr-rpki-rtr-rfc6810-bis-08-opsdir-lc-winter-2017-02-07/, one editorial remark. Periodically, the router sends to the cache the most recent Serial Number for which it has has received data from that cache s/has has/has
Thanks for your work on this draft. The first question is more of a nit, the second is more important. Section 9.1 I suggest saying man-in-the-middle instead of monkey-in-the-middle as we use the latter typically in documents and I don't think there's anything particularly unique to a monkey-in-the-middle attack, but correct me if I am wrong. I think it's just an alternate name for man-in-the-middle as result of Dug Song's tool sniff on monkey.org. If monkey-in-the-middle is important for some reason, could you include a reference? Section 9.3 Why isn't MD5 deprecated or discouraged more in this section?
This is a general discuss on the principle of using extension mechanisms (like versioning) and how and when to use it. This document increases the version number to add one new PDU type as well as to clarify some questions on timing parameters. However, versioning is just one extensibility mechanism out-of a whole set of option. In this case the protocol also has an (8 bit) type field to define new PDU types. Only 8 types are used so far (in version 0 of the protocol) out of 2^8 which leaves another option for extending the protocol. The usually specification here is that the receiver will ignor unknown types which is exactl what you want. There in this case I don't see that a new version necessary. Further there is an issue on how the versioning is done. This document looks like a bis document and used to obsolete the old spec till the last version (-07) but now neither updates nor obsolete it. If you actually decide to have a new version, that might be right (also updating might be an option which I would actually recommend in this case because I believe the expectation is that new implementation should always implement this version) but I don't really see in this case that doublicating all the text is the best option. I would actually not recommend to increase the version because I really don't see a need for this, given the (much easier) extensibily mechanism you have with the type. If you'd only would like add the new type, then actually a short draft that defines the type and updates rfc6810 would be sufficient. Regarding the other calrification, I think this could also be done in a short (potentially the same) updating draft. If you still think it better to copy all the text and have one clean draft than obsoleting is the right choice.
draft-ietf-oauth-jwsreq
- intro: "attacks... have been identified." yells out for a reference - it'd be a good bit better if implementers could easily find details of some such attacks, so I hope you add some refs here. - section 3; WAP? Really? I'm surprised any WAP technology would still be in use, even on feature-phones. Do you really need this? - section 4: I think it will turn out to be an error to allow for mixing query parameters and protected parameters (in a Request Object) in a single request. Do you really need that level of flexibility? It'd be simpler and less likely to be attackable to insist that all parameters be in the Request Object if one is used. (See also section 11.2.1 below.) - section 10: Is there nothing to be said about the new indirection caused by the request_uri? I'd have thought there were some corner cases that'd warrant a mention, e.g. if some kind of deadlock or looping could happen, or if one client (in OAuth terms) could use a request_uri value as a way to attempt attacks (to be assisted by an innocent browser) against some resource owner. - section 11: thanks for that, it's good. - section 11: Saying that an ISO thing is "good to follow" is quite weak IMO. (And is that ISO spec accessible? Hmm... it seems that one needs to accept cookies to get it which is wonderfully ironic;-) If the authors have the energy, I'd suggest trying to find better guidance that's more publically available in a privacy-friendly manner. (Or just drop the ISO reference if 6973 is good enough.)
When referencing RFC 6125 you need to provide more details. In particular, you need to pretty much answer every question in section 3 of RFC 6125: <https://tools.ietf.org/html/rfc6125#section-3> One example of how this might look like is in Section 9.2 of <https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/?include_text=1>. For your convenience the relevant text is pasted below: Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS. Certification authorities which issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates. DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*". rpki-rtr implementations which use TLS MUST NOT use CN-ID identifiers; a CN field may be present in the server certificate's subject name, but MUST NOT be used for authentication within the rules described in [RFC6125]. The only thing missing from the above is explicit mentioning that SRV-ID and URI-ID are not used. (I think the same should apply to your document.)
In 5.2: a document defining HTTPS URI needs to be a normative reference. In 5.2.3: can you show an example of response (with relevant HTTP Header Fields)? Or update example in 5.2 to include HTTP Header Fields.
- 4, "Since it is a JWT, JSON strings MUST be represented in UTF-8. ": Is that a new requirement, or a statement of fact about an existing JWT requirement? - 5.2: I'm not sure all readers will understand the meaning of "feature phone". Also, WAP and 2G don't seem all that relevant in 2017. - 5.2.1, first sentence, "The URL MUST be HTTPS URL.": Is that redundant to the similar requirement in the previous section? That instance had an "unless" clause, but this one does not. --2nd paragraph: "... MUST have appropriate entropy for its lifetime." Can you offer discussion (or a reference) for what constitutes "appropriate entropy"? -- 3rd paragraph: Is it reasonable that one would know if TLS would offer adequate authentication at the time of the signing decision? - 5.2.3, 2nd paragraph: "SHOULD use a unique URI": Why not MUST? Would it ever be reasonable to not do this? - 6.1, 2nd paragraph: What if validation fails? - 13: Do you want this in the final RFC? If not, it would be wise to add a note to the RFC editor to that effect.
Should this document maybe update rfc6749?
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
Thanks for a clear and well-written specification.
I think it would make sense if this doc updates RFC 3633 because someone who (newly) implements RFC 3633 should really also read this document and hance needs this pointer. Also, I would move section 3.6 to the beginning but that doesn't really matter.
From the draft: [RFC3633] is unclear about how the client and server should act in different situations involving the prefix-length hint. From the shepherd write-up This document specifies information that is useful to DHCPv6 client and server implementers to support allowing clients to specify a prefix length hint when requested delegated prefixes. It clarifies this concept introduced in RFC 3633. => that implies an UPDATE, no? Obviously, this document publication should go forward (so not a DISCUSS), but I would like to understand why this is not an update. Editorial nit (by Sue Hares, part of her OPS DIR review): Page 3 section 3.1 section under problem. Second paragraph. Second sentence The best way to assure a completely new delegated prefix is to send a new IAID in the IA_PD. IAID – abbreviation has not been indicated prior to this use Old:/IAID/ New: /IAID (IA_PD unique identifier)/
I'm okay with the reasoning for the security considerations section, but think it might be good if a general reference for security of DHCP was listed as well. Since an older RFC is referenced, any references from that one might be out-of-date.
Please expand IA_PD on first use.
draft-ietf-dmm-4283mnids
I'll watch the DISCUSSions from other ADs ...
I don't consider that merely mentioning that there are some privacy issues (maybe) is nearly sufficient here. Instead I would argue that any of these identifier types that could have privacy implications need to be specifically justified or else dropped. By specifically justified, I mean that there ought be an argument (and a fairly holistic one) that the Internet is better, and not worse, if we define a codepoint that allows MIPv6 (and later, other protocols) to use that identifier. I do accept that my position is perhaps innovative, in terms of IETF processes, so I'll split the discuss into two parts, one process oriented and mostly for the IESG, and the second relating to the content of the draft. (1) For the IESG: is it ok that we introduce (codepoints for) a slew of new long-term stable privacy-sensitive identifiers just because they might someday be needed, or do we need to have specific justification for defining such things? I would argue the latter, but that may need us to validate that there is IETF consensus for that somehow, and perhaps in the meantime hold on to this draft. Part of my reasoning is that once we define such codepoints (e.g. for IMSIs) then that inevitably means that other protocols, and not just MIPv6, will do the same eventually, so accepting this draft basically means accepting that we end up commonly and perhaps carelessly, passing such highly-sensitive information about on the Internet in many protocols and in many contexts. My argument here I think does adhere to various of our BCPs that do argue for security and privacy, but I do also accept that this may be novel and to some extent goes against another of our generally accepted ideas which is that we benefit from folks documenting things even if those things are sub-optimal in various ways. So I'd argue this is a real case for an IESG discussion - I know what I think, but what do the rest of you think? (2) For the authors: to the extent you are willing to, and want to get ahead of the discussion on point (1) above, can you in fact provide an argument, for each of the identifiers here that have privacy-sensitivity, that the Internet is better overall if we define these codepoints knowing that if we do define a way to represent e.g. an IMSI in MIPv6 that is likely to be copied elsewhere? Note for the authors: I think it's entirely fine for you to do nothing pending the discussion of point (1) above, if that's your preference.
While I'm entirely sympathetic to Mirja's discuss point, I don't think that a statement here can really constrain how these identifiers, once they are defined, are used in other protocols. While there is a chance that some IESG sometime might say "hold on, RFCxxxx (this doc) says you SHOULD encrypt if <that> identifier is used" the chances that a future IESG notice this isn't that high, but it's also even more likely that the designers of future protocols will successfully argue that since not all identifiers are privacy sensitive, their specific protocol need not adhere to the SHOULD. In the end, I think that should or SHOULD will be ineffective.
Author agreed to do the following change in the security considerations section: OLD "If used in the MNID extension as defined in this document, the packet including the MNID extension should be encrypted so that personal information or trackable identifiers would not be inadvertently disclosed to passive observers." NEW "If used in the MNID extension as defined in this document, the packet including the MNID extension MUST be encrypted so that personal information or trackable identifiers would not be inadvertently disclosed to passive observers."
The security considerations says some of these identifiers can carry sensitive information, and when they do you should encrypt. This leaves it to the reader to decide which might be sensitive. The draft should tell the reader which ones the working group thinks are sensitive, keeping in mind that if an identifier is sometimes sensitive, it usually needs to be treated as if always sensitive. (It's hard for deployed code to figure out when it is or isn't sensitive.)
I agree with Stephen's, Alissa's, and Mirja's discusses. I especially agree that we should not standardize new identifiers without justifying each one. Section 5 says this document does not impact existing security mechanisms. But it does add new data elements, and acknowledges some of them may be sensitive. Thus I think the "does not impact" assertion needs some supporting discussion. Are the existing mechanisms still adequate? Why? There are a bunch of acronyms that would benefit from expansion on first mention.
The discussion resulting from Dale's excellent Gen-ART review probably needs to move forward before this document is ready to be made an RFC.
Thanks for the changes per the SecDir review and Mirja's discuss. https://www.ietf.org/mail-archive/web/secdir/current/msg07164.html
I support Stephen's DISCUSS. I'm also wondering, if all of these identifiers are already in common use in MIPv6 without a standard, if there is some privacy improvement that standardization could contribute (e.g., encrypting the identifiers, or requiring transport encryption, or limiting their transmission to the initial binding, or ... other ideas the community may come up with). The benefit of just standardizing the options as-is seems outweighed by the potential privacy risks as this spec is defined. I'm also confused about the identifier types that do not uniquely identify one node, since I thought that was the point of these options. How are they meant to be used in MIPv6? Would you have multiple mobile node identity options in a single packet that, together, uniquely identify a node? I think this requires some elaboration in the text.
draft-ietf-ccamp-flexible-grid-ospf-ext
1) Is it really necessary to define a sub-TLV to a sub-TLV? The Interface Switching Capability Descriptor is already a sub-TLV of the Link TLV and now you define another sub-sub-TVL for the Frequency availability bitmap. Is it really necessary to have another sub-TLV system here and a new/own registry, given you only define one (!) sub-sub-TLV? I would say you should remove this sub-sub-TLV system and the registry and simply define the bitmap as fixed part of the new Flexi-Grid-LSC sub-TLV. And if you every need another sub-sub-TLV you simply define another ISCD sub-TLV instead. I really don't think the additional complexity of this sub-sub-TLV system and the registry is justified! 2) The Port Label Restriction field as specified in RFC7579 is not a sub-TLV but a field; see section 4.2: "The Port Label Restriction sub-TLV is defined in [RFC7579]. " 3) Section 3 does not specify any requirements (as the title indicates) but only given some quite extensive background information. I don't think this is needed (anymore) for the final published document and could be completely removed or compressed to a few paragraphs in the intro.
Thanks for your work on this draft. I don't see a response to the SecDir review that asks for more clarity in the draft on OSPF Opaque LSAs, mentioned in the security considerations section, but not elsewhere. https://www.ietf.org/mail-archive/web/secdir/current/msg07120.html Could some text be added to help with this request?
draft-ietf-dnsop-edns-key-tag
I am doubtful that this will deploy, considering that there are 2 mechanism. Are there existing or planned implementations of both approaches? I am sorry if I missed that in the shepherding writeup.
It's unfortunate that the working group couldn't agree on one mechanism, but that's not enough to stand in the way of publication.
Discussion engaged between the Mahesh (OPS DIR reviewer) and the author. https://www.ietf.org/mail-archive/web/ops-dir/current/msg02457.html
- abstract: referring to section 1.1 from here seems wrong, the abstract ought be readable by itself - section 5: Is the key tag query only and solely intended to allow the authoritative to track how clients are paying attention (or not) to key rollovers? If there's another purpose I'm not clear about it. - 5.3: "I believe that to be..." seems like the wrong language to use with >1 author. - section 7/8: Is there a missing security/privacy consideration here, in that an authoritative server here could arrange to hand out key tags that are specific to (in the limit) each query, so that when the resolver queries a sub-domain, and thereafter, the client will be identifiable to the authoritative server? One could do this by generating new keys per querier so that if I ask about example.com I get given a tag that's unique to me, and then some web content pushes me to ask about www.example.com and every time I do that I emit that user-specific key tag. While that'd be unlikely for a large zone, it might be feasible as a tracker if some "bad" domain sets up a specific subdomain for such purposes. That said, I'm not clear how much better this is for the attacker compared to simply using a tracking name in the authority component of the URL for e.g. some 1x1 gif.
draft-ietf-mpls-tp-linear-protection-mib
Some editorial changes are agreed upon, triggered by our OPS DIR reviewer Qin Wu.
draft-ietf-mmusic-sctp-sdp
Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?
This spec is really well-done. Thanks to the authors and working group for that.
draft-ietf-bmwg-ipv6-nd
* Section 2 What does this mean in real life? "Furthermore, Link A and Link B must be lossless." * Section 2.1.2 The Router advertisements need to contain some values in the M and O bits. I think the values for these bits need to be specified in this section. * Section 2.2.5 Why does the tester have counters for RS packets received and RA packets sent? It is unclear why this would be useful as both should always be zero.
Minor clarification comments: 1) section 2.2.4: "This stream contains two flows, each contributing 500 packets per second to the 1,000 packet per second aggregate." Are these packets send alternating or in a block or does that not matter? 2) section 3.1.1: "When the timer expires, stop the test stream, wait sufficient time for any queued packets to exit, ..." That's the sending queue at the tester? I guess you'd also want to give it some time to make sure the packets send out can still be received. Does it makes sense to recommend a time here that's safe? 3) And a more general but even less important question: Isn't the base test included in the scaling test? And if so, do you still need to define the base test separately?
Just an idle thought... Given what we've learned about tests, car manufs and diesel engines recently, I wonder if it'd be a good idea for the security considerations sections of this kind of RFC to consider how a DUT implementer might cheat? In this case, I guess there could be a scenario where the "clear the NC" operation is not really done (for a short time, after a test pattern has been observed recently) so that the DUT appears to perform better during tests. I'd guess that some of the folks designing these tests thought about some of that, but it might be no harm to start writing that down as well. (Note this really is just a suggestion, I'm not complaining at all. OTOH, while it'd be a bit of work, it might be fun of a kind:-)