Subject: [DNSOP] draft new charter

From: Suzanne Woolf <[email-masked]>
Date: Thu, 3 Apr 2014 17:39:58 -0400

Colleagues,

Here is draft text for the new charter we've been talking about for DNSOP.

When we have something the WG is comfortable with, we get to ask our AD to take it to the IESG, so please review and comment.

(If you want to comment off-list, please send to [email-masked], cc'd above, so we both see it….but on-list is preferable.)

best,
Tim & Suzanne

==========
The DNS Operations Working Group will develop guidelines for the
operation of DNS software and services and for the administration of DNS zones.
These guidelines will provide technical information
relating to the implementation of the DNS protocol by the
operators and administrators of DNS zones. The group will
perform the following activities:

1. Define the processes by which Domain Name System (DNS) software
   may be efficiently and correctly administered, configured, and
   operated on Internet networks. This will include root zone
   name servers, TLD name servers, name servers for other DNS
   zones, iterative DNS resolvers, and recursive DNS resolvers.
   As part of this effort, the group will produce documents
   explaining to the general Internet community what processes
   and mechanisms should be employed for the effective management
   and operation of DNS software and services, including root, TLD,
   and recursive servers.

2. Publish documents concerning DNSSEC operational procedures.

3. Publish documents concerning DNS operational
   procedures in IPv6 and mixed IPv6-IPv4 networks, and provide documentation 
   and guidance on DNS-related IPv6 transition and coexistence
   issues.

4. Publish documents on extensions or protocol maintenance to the DNS
   Protocol, with a focus on the operational impacts of
   such changes. Act as clearinghouse for discussion or provide advice to ADs
   and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record
   synthesis, or other mechanics of extending DNS to support other
   applications.

5. Serve as a clearinghouse for DNS-related issues where people can
   bring drafts that document the problem space around these issues.
   The group will then decide whether these issues belong in DNSOP and, if not,
   will work with the authors and appropriate ADs to determine the
   appropriate group for the work.

6. Publish documents that attempt to better define the overlapping
   area among the public DNS root, DNS-like names as used in local or restricted
   naming scopes, and the 'special names' registry that IETF
   manages, and how they will interact moving forward.  Work in a
   liaison capacity to ICANN to assist in this.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Apr 2014 17:50:20 -0400

>    zones, iterative DNS resolvers, and recursive DNS resolvers.

Is there a reason to call out these particular functions, or not to
include something like, "or any other resolver or server functioning
as part of the global DNS"?  I'm just worried, for instance, that
stubs don't appear there, even though there might be advice I can
imagine the WG providing.

>    liaison capacity to ICANN to assist in this.

Given that "liaison" is a term of art around the IETF, perhaps the
latter sentence needs to be phrased another way?  I'm not sure exactly
what you have in mind, or I'd suggest something.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 Apr 2014 15:42:26 -0700

> imagine the WG providing.

+1 to at least calling out stub resolvers, but Andrew's non-list formulation is better.

> what you have in mind, or I'd suggest something.

Let me be more blunt than Andrew: an IETF WG cannot work as a "liaison" to anyone. The IETF has liaisons to ICANN (and bless them for doing that somewhat thankless task!). ICANN should not expect that any WG would be a direct point of contact for ICANN work at all.

--Paul Hoffman

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 3 Apr 2014 19:00:11 -0400

Paul (and Andrew),

> Let me be more blunt than Andrew: an IETF WG cannot work as a "liaison" to anyone. The IETF has liaisons to ICANN (and bless them for doing that somewhat thankless task!). ICANN should not expect t…

Understood that wordsmithing is needed, and getting the wording right is an important detail, but I think we're even more interested in whether the item should be there at all: should DNSOP, in appropriate collaboration with all relevant parties by whatever mechanism applies, be taking on special names/RFC 6761 issues?

thanks,
Suzanne

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 Apr 2014 16:30:22 -0700

> Understood that wordsmithing is needed, and getting the wording right is an important detail, but I think we're even more interested in whether the item should be there at all: should DNSOP, in app…

In all seriousness, the WG might not get a choice. I've heard from two folks in the I* leadership that they're watching our threads. I replied to both of them that I thought that might not be a good idea, but they indicated that it was better than it being done in the smoke-filled telechats.

Having said that, I would be happy to propose ripping that out of our charter. Yes, we're all into politics and such (and law...), but we don't offer much expertise other than "yes, there is a difference between these different places that should block or resolve those names".

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 4 Apr 2014 10:59:06 +0200

On Thu, Apr 03, 2014 at 05:39:58PM -0400,
 Suzanne Woolf <[email-masked]> wrote 

>    synthesis, or other mechanics of extending DNS to support other

Do we all agree that it may cover, in the future, the work which is
currently discussed on the dns-privacy mailing list?
 
>    liaison capacity to ICANN to assist in this.

I strongly dislike "the public DNS root" as if there were only one
(technically, any root is a root and, for dnsop, it does not matter if
it is the USG root or any other, the DNS operational issues are the
same) and I dislike even more "DNS-like names", which seems to imply
there are inferior names. www.foobar.local is a domain name, even if
it is not resolved through the DNS.

I suggest: Publish documents that attempt to better define the
overlapping area among the DNS and other resolution protocols which
use domain names (and may have gateways to the DNS), especially in the
context of the 'special names' registry that IETF manages (RFC 6761).

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 4 Apr 2014 14:53:37 +0200

op 04-04-14 10:59, Stephane Bortzmeyer schreef:

> same) and I dislike even more "DNS-like names", which seems to
> imply there are inferior names. www.foobar.local is a domain name,
> even if it is not resolved through the DNS.

I tend to disagree to this marketing definition of a domain name.
For me, a domain name is a name that consists of labels seperated by a
dot that is resolvable through the DOMAIN name system.

Any name that consists of labels seperated by dots but is not present
in a domain name system is just that: A name with dots in them. Maybe
that same name scheme is used in other protocols as well, but that
does not make a name a domain name.

I don't considder these other names with dots in them inferior, but
they are simply not domain names.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Apr 2014 09:09:08 -0400

> they are simply not domain names.

Whether you are right or not, I think Stephane's interpretation is technically correct.   I don't mean that it _is_, I just mean that I think it is.   So we aren't going to get to the truth of the matter by casting slogans at each other, because it's just a matter of opinion.   It's not wrong to describe the names the way Stephane has, and it's not wrong to describe them the way you have.   So we should choose based on what meaning more clearly expresses the policy we ultimately decide on, rather than trying to drive the policy choice on the basis of what name we prefer.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Apr 2014 10:56:26 -0400

> Whether you are right or not, I think Stephane's interpretation is technically correct.   I don't mean that it _is_, I just mean that I think it is.   So we aren't going to get to the truth of the…

My observation is that there is a world out there and name are applied to things (in the sense, the answer to the questions a toddler asks “what is that?”).  These names transcend oral and written forms, are not always universal, and are some times applied with a heavy cultural bias.  In short, the names can be in conflict with each other, there’s no sense of order to naming.

And that there’s this DNS which enables a representation of the world.  The DNS contains a mapping of the world into a hierarchy of domain names (and I’ll keep the adjective here to “scope” what is meant by “name").  Mapping means a transference of one reality onto another, it doesn’t guarantee a perfect copy, but a representation for a particular purpose.  The point is, domain names are a proper subset of all names.

It’s tempting to also comment on the quality of the mapping.  The DNS itself “is what it is” - a system which imposes various and sometime seemingly arbitrary impingements on a smooth mapping.  With it today we can only do so much.  That shouldn’t stop us, but, it makes the work harder up to the point that it becomes necessary to overhaul the system.

DNSOP WG has been convened around the DNS.  The expertise present is expected to be knowledgeable about the protocol as it stands (and where it can “go”) and the set of requirements that are placed against it[0].  To this end, the work is to manage how domain names are operated, what is delegated and what kind of data is associated with each node.  So, I think it is a non-starter to get into “inferior” names and whatever that means.  We should stick to working with domain names and how they are operated.

For example, in some cases, domain names could be barred from the protocol.  These might be names that fail some test of what names should be mapped into domain names.  You might think of content censorship here or you might think of visibly confusing combinations of different writing scripts (those are ratholes the WG is arguable not prepared to discuss).  In other cases, some domain names can be restricted or scoped because in contexts, two names might mean different things and result in confusion and delay[1] or worse yet, a security concern.

Oh, and as  PS - in direct response to Antoin’s message, “Will.i.am” is a singer, not a domain name. ;)  That is meant as a joke.  However, I do not think a domain name is label.label.label. (Yes, despite STD 13 documenting the presentation format.)  That is just a textual representation of the “byte count” “value” “byte count” “value” … “byte count=0” you see "on the wire.”  I regret that people think of the “dot” as the official, burned-in-to-the protocol separator - it’s just what is thrown into representations in the Latin character set world (because back then, that’s all that was considered in the documents).  There’s no reason why a special character native to the Han glyph set could be used in Chinese-Japanese-Korean representations of domain names, and when it comes to right-to-left scripts like Arabic, the “problem” of directionality would be solved.  Sigh, the DNS “is what it is."

[0] I say this having spent time trying to determine the official name of some governments in various, local scripts.  Although this is “naming” it is not anything like understanding the DNS.
[1] After a few Thomas the Tank Engine books, you can’t get that phrase out of your head.

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 06 Apr 2014 19:25:00 -0400

(catching up, and I'll jump into the middle of things)

> currently discussed on the dns-privacy mailing list?

Short Answer: yes. Long Answer: if what comes out is a new protocol or a 
major spin of the protocol, the idea is to delegate that to a new 
working group.

The idea is to keep this specifically vague that allows new things that 
come up to be addressed, rather than being constrained by the charter.
> context of the 'special names' registry that IETF manages (RFC 6761).
This isn't a bad option, but this whole line item is a giant ball of 
pain but something we've been asked to help facilitate.   We have some 
ways to go it seems.

tim

---

From: joel jaeggli <[email-masked]>
Date: Sun, 06 Apr 2014 16:37:58 -0700

> major spin of the protocol, the idea is to delegate that to a new

As with the rapid spinup of dnssd I think we can be confident that the
internet area remains the right place and has the will to do new DNS
work, and we can and should address the undertaking of new protocol work
through that channel.

> pain but something we've been asked to help facilitate.   We have some

from my vantage point documenting the attracive nuisance that exists
today is one problem.  what to do about the existing problems is
another. how to allow for future inovation without tha same consequences
as before is the third.

> tim
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 7 Apr 2014 18:12:15 +0100

sent from Google nexus 4
kindly excuse brevity and typos.
On 4 Apr 2014 13:53, "Antoin Verschuren" <[email-masked]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
May I know what a domain name system (by IETF) definition mean? Because me
thinks any name that resolves (either through public DNS, private or local
to pc) is a domain name.

So if your definition of domain name system include all those 3 categories,
then I agree to your view.

Regards
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJTPqtKAAoJEDqHrM883Agnd3cH/0q+hZ6q7gmBF73GGTORUkt7
> uOphjZs3hEr0d4n29NVc6Un06Bx3nxQa3bD+HwlZgObwklI5BafXqsUyRYkY5qWA
> 5Ik/T1O5U9/sjKnWv5bL790yObKeY4WYR1O9teCDVU4IBmockK2is33bXQ2sW/7S
> O/wZnE6kU3pYcPCrjmrUCGagvCYHRWEa4yUvq7gaMop/hDnqswhIxvp+MDPHx7fE
> D4mTtVZTY73WwwtmrC/ayIYUg5sXyODeQOZjo2Re8cJG3rtqgYkzmVTy7hNh69a6
> iCuLugKYFensweHFwgu55EUHFcf3IwfO2TpdSZvRVYCDTxP9/F5qE4bMgabXsOo=
> =8KYt
> -----END PGP SIGNATURE-----
>

---

From: Petr Spacek <[email-masked]>
Date: Tue, 08 Apr 2014 13:38:20 +0200

On 4.4.2014 00:42, Paul Hoffman wrote:
> On Apr 3, 2014, at 2:50 PM, Andrew Sullivan<[email-masked]>  wrote:
>

I agree that including stub-resolvers and other DNS-related software sounds 
like a good idea.

There were long threads about DNSSEC handling in stub-resolvers on dane-list 
[0] but dnsop seems like a better place to discuss this matter.

Note that this discussion is not over so we can move it to dnsop if dnsop agrees.

[0] http://www.ietf.org/mail-archive/web/dane/current/msg06658.html

-- 
Petr Spacek  @  Red Hat

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Apr 2014 09:20:05 -0400

From the linked message:

1) DNS-Architecturally speaking, this statement is incorrect:

*Local validating resolver is strongly recommended.*

What  is needed is: 

*Local validator is strongly recommended.*

Well, this is better:

*Local validator is required.*

Or "local validation is required in order to assess the level of trust in what is received”.  If the goal is being able to trust what is received, you have to have validation, it’s not just a good idea.

2) /etc/sresolv.conf.

- System-wide configuration format (e.g. modify resolv.conf vs. add a new file)

In 1998 I used “/etc/sresolv.conf” in the first prototype validator.  It had configuration lines for trust anchors and all the rest of /etc/resolv.conf.

There’s no reason you can’t reuse the existing file or soft link (/etc/resolv.conf -> ../var/run/resolv.conf)

3) As far as AD bit stripping….

The question to ask is whether you trust the stub resolver’s (set of) sources or not.  If you trust the sources for all things other than DANE, why not trust them for DANE too?  Conversely, if you don’t trust them for DANE, why trust the sources for anything?

One can view DNSSEC as a standalone application.  The “server” is the dnssec signer, the “client” is the validator.  Those two act like IPSEC tunnel endpoints.  What goes in one comes out the other unmolested.  The fact that “below” the DNSSEC plane is plain old DNS is irrelevant.  I could take the results of the signer and FTP them to the validator, rsync them, etc.  DNSSEC only allows the validator to determine if what it got was produced by an authorized(-by-the DNS-zone-administrator) signer, operated in an authorized manner.

It is (or was) possible to tweak the DNSSEC to have the signer be in the hands of whomever is responsible for DANE but not the DNS.  That would be by attaching RRSIGs generated by keys that are identified as DANE-not-DNS.  (This is in the concept, don’t know if it is in the software anymore.)

On Apr 8, 2014, at 7:38, Petr Spacek <[email-masked]> wrote:

> I agree that including stub-resolvers and other DNS-related software sounds like a good idea.
> 
> There were long threads about DNSSEC handling in stub-resolvers on dane-list [0] but dnsop seems like a better place to discuss this matter.
>

---

From: Jonne Soininen <[email-masked]>
Date: Tue, 8 Apr 2014 13:24:09 +0000

Hello everybody,

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Suzanne Woolf
Sent: Friday, April 04, 2014 2:00 AM
To: DNSOP WG
Cc: <[email-masked]>
Subject: Re: [DNSOP] draft new charter

Paul (and Andrew),

On Apr 3, 2014, at 6:42 PM, Paul Hoffman <[email-masked]> wrote:

>> latter sentence needs to be phrased another way?  I'm not sure 
>> exactly what you have in mind, or I'd suggest something.
> 

JSo: yes, I think DNSOP should. I think this is one of the major short/medium term issues the IETF should address and I believe DNSOP has the expertise to do it. I also do find the word "liaison" a bit difficult here. I think we should describe what we get done (I think there was another thread on this) rather than the activity. 

So, my proposal is (maybe somebody can translate this to English, though): 

"6. Update or replace RFC6761 to specify the usage of the 'special names' registry in a way fitting today's requirements. Gather adequate input from the ICANN community to ensure compatibility with ICANN policies. Specify a solution or solutions to address overlapping name spaces between the public DNS root and the DNS-like names used in the Internet."

My feeble attempt is to focus more on the outcome than on the "liaising".  I personally believe that we get the right outcome of key people from the ICANN community come to the DNSOP to work on this rather than the WG tries to pull the information from ICANN. This is my experience with working together with different organizations and the IETF - for instance, in the case of 3GPP and IETF in the good old days... (No, they weren't actually that good).

Cheers,

Jonne.

thanks,
Suzanne

---

From: Petr Spacek <[email-masked]>
Date: Tue, 08 Apr 2014 15:54:00 +0200

Let me quote very first part of the message to put it into context:
>>>>>>>> People start to disagree when it comes to questions like "Is it feasible to
>>>>>>>> rely on a local validating resolver in the near future? How can applications
>>>>>>>> detect that a validating resolver is not configured and that DNS responses
>>>>>>>> can't be trusted?"
>>>>>>>>
>>>>>>>> Aim of the proposal below is to enable applications to stay safe on systems
 >>>>>>>> without a validating resolver.

In other words, we are looking for a way how to augment current APIs to move 
DNSSEC-related knobs from applications to system-wide level (so you don't need 
to tweak OpenSSH config and Postfix config separately, for instance).

> Or "local validation is required in order to assess the level of trust in what is received”.  If the goal is being able to trust what is received, you have to have validation, it’s not just a good…

Sure, I think that nobody opposes that. The problem is more about "How can an 
application detect that validating resolver is in place?"

Note that this proposal is about declaring that answer is untrusted, never the 
other way around. Declaring answer as trusted is *always* done by validator.

> One can view DNSSEC as a standalone application.  The “server” is the dnssec signer, the “client” is the validator.  Those two act like IPSEC tunnel endpoints.
Sure. The question is "How can an application detect that the IPSEC tunnel is 
in place?"

I hope this clarifies purpose of the proposal.

Have a nice day!

Petr Spacek  @  Red Hat

 > What goes in one comes out the other unmolested.  The fact that “below” the 
DNSSEC plane is plain old DNS is irrelevant.  I could take the results of the 
signer and FTP them to the validator, rsync them, etc.  DNSSEC only allows the 
validator to determine if what it got was produced by an authorized(-by-the 
DNS-zone-administrator) signer, operated in an authorized manner.

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Apr 2014 10:10:19 -0400

On 8 Apr 2014, at 9:54, Petr Spacek <[email-masked]> wrote:

> In other words, we are looking for a way how to augment current APIs to move DNSSEC-related knobs from applications to system-wide level (so you don't need to tweak OpenSSH config and Postfix config separately, for instance).

I think introducing a new API to inform applications as to what security measures are in place is going to be messy and complex. The better approach is surely to let applications decide what features they want and specify them through the same API they use to perform DNS resolution, e.g.

http://www.vpnc.org/getdns-api/

Joe

---

From: Petr Spacek <[email-masked]>
Date: Tue, 08 Apr 2014 16:27:54 +0200

> http://www.vpnc.org/getdns-api/

I definitely agree that new API is necessary, but I'm afraid that it is long 
term effort. Unfortunately, many (non-DNS-related projects) have roadmaps 
filled with more interesting stuff (for them) than a new fancy DNS API.

I would rather see RFC 4025, RFC 4255, draft-wouters-dane-openpgp and 
draft-wouters-dane-openpgpkey-usage to be practically implemented and widely 
used sooner than later.

Thank you for your time.

-- 
Petr Spacek  @  Red Hat

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Apr 2014 10:40:58 -0400

On 8 Apr 2014, at 10:27, Petr Spacek <[email-masked]> wrote:

> I would rather see RFC 4025, RFC 4255, draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage to be practically implemented and widely used sooner than later.

I would like to see those things too. But they're a bit useless without a solid way for applications to retrieve and validate the signed records.

Time spent making the API available and promoting its use amongst developers would bring us closer to DANE being useful.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Apr 2014 11:01:05 -0400

But isn’t that example (below) a new API? ;)

Back in the earliest days of my security work I recall reading about “mandatory” versus “discretionary” security.  The former was security enforced by a controlling system that was untouchable by the entities involved, the latter the security enforcement could be altered by the entities.

Googling for that, I found these slides (https://wiki.engr.illinois.edu/download/attachments/183272958/mandatory-security-policy.pdf?version=2&modificationDate=1318258701000) on the 4th slide is “MAC vs. DAC.”  I include that reference just to help define my terminology.

If the question is how to enforce that software is “running secure” in this context, the question is whether you want to let the application developer decide that or take away the option.  I can see this being done by specifying (the only tool the IETF has) and the verifying via code reviews/testing that an turn-key (for security) API is used over a specified set of libraries.  That’s if I don’t have a tight control loop over the developer community.

One one extreme, applications can be left to their own devices to do all they need.  I’d argue that over the long haul we will wind up with an unmanageable spectrum of code “doing security” in various not-so-consistent ways.  There comes a time when things ought  to be tightened up.  (Examples, what’s going on in EPP, places where developers have had a decade or two to extend protocols.)

I’m not sold on sticking with a current API.  Perhaps build a more restrictive API for domain-specific security - based on some current API?

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Apr 2014 12:02:42 -0400

> But isn’t that example (below) a new API? ;)

I wasn't reacting to the newness of the API, but rather the dual approaches of (a) provide a new DNS API for applications, or (b) leave applications using the existing/archaic API for name resolution, and introduce an additional API that characterises the security characteristics of their use.

Amongst the problems with (b) is the lack of fine-grained (e.g. DNSSEC-specific) message passing to the application, so that it can react to the various failure modes in a manner that allows users to be informed and the application generally to make good choices.

Joe

---

From: Petr Spacek <[email-masked]>
Date: Fri, 11 Apr 2014 12:29:55 +0200

> Amongst the problems with (b) is the lack of fine-grained (e.g. DNSSEC-specific) message passing to the application, so that it can react to the various failure modes in a manner that allows users…

I should clarify that the proposal sent to dane-list is just a temporary 
solution. *It doesn't prevent us from inventing a completely new shiny API.*

The purpose of the proposal is to ease transition from non-DNSSEC aware 
applications/security models to DNSSEC-aware ones (without polluting every 
application with validation logic and related configuration).

Sure, we can throw all existing APIs out of the window and wait few 
years/decades until a new shiny API is available everywhere and upstream 
developers decide to use it instead of old APIs...

Personally, I think it it is better to give application developers some really 
easy way how to use data from DNS(SEC) tree today and let them gradually 
migrate to new APIs later.

Once again: A new API definitely has value (e.g. better error handling etc.), 
I'm not opposing it.

I just don't want to wait too long. From my perspective, it is much easier to 
make/review/push patches which add one new flag to existing DNS library calls. 
Compare it with replacing existing name resolution code with new shiny library.

I hope this clarifies my intent.

-- 
Petr Spacek  @  Red Hat

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 12 Apr 2014 10:40:24 -0400

On 4/8/14, 7:38 AM, Petr Spacek wrote:
> There were long threads about DNSSEC handling in stub-resolvers on 
> dane-list [0] but dnsop seems like a better place to discuss this matter.
>
The wording in Item #1 is essentially intact from the current charter.  
So it could take some updating.  We can change that sentence to say:

     This will include root zone name servers, TLD name servers, or any
     other resolver or server functioning as part of the global DNS.

That would address the lack of stub resolvers, but also allow the 
flexibility for anything we may fail to specifically mention.

tim