Subject: [dns-dir] FW: DISCUSS: draft-hoffman-dac-vbr

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 2 Feb 2009 18:54:59 +0100

DNS-DIR folks,

 This is the answer from Paul on draft-hoffman-dac-vbr in case you did
not see it. 

Dan

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, January 29, 2009 9:05 PM
To: Romascanu, Dan (Dan); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: DISCUSS: draft-hoffman-dac-vbr

At 7:50 PM +0100 1/29/09, Romascanu, Dan (Dan) wrote:
>There has been quite a lot of traffic on this. Can you send again the 
>response that you consider being the 'official' answer (may be more 
>than
>one) so that we make sure the DNS-DIR has seen it?
>

To: Russ Housley <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: FW: [dns-dir] Question about draft-hoffman-dac-vbr
Cc: John Levine <[email-masked]>, Arvel Hathcock
<[email-masked]>
Bcc:
X-Attachments:

>Please generate a response to this review.

Done. This is approved by both my co-authors as well. You may pass it to
the IESG. I also spoke with Liman and we have agreed to disagree on the
TXT record issue. He did not know why the DNS-DIR review was not
requested earlier, nor why Peter Koch did not bring it to the DNS-DIR
when we spoke with him probably a year ago about the document.

=====================================================================

>I took myself through this document, and I must say that without
fundamental knowledge in modern mailology, more specifically sender
authentication, it seems like "dancing around the issue but never
getting there". There is lots of talk of "certify the owner" and
"valitdation of the identity" and stuff, but little explanation of the
overall process going from A to B. I would like to see something that
starts with "mail going out here" and ends with "and by validating that
signature, the authenticity can be established. QED.".

The document purposely doesn't do that because different mail systems
will do the certification at different times. For example, some mail
systems would do this between the time a message is received and when it
is put in the user's mail store; others would do it when reading the
file from the mail store but before displaying it to the user. The
timing truly doesn't matter to the protocol: what matters is that it is
done using the steps given in the document.

We carefully designed VBR so it can be used in conjunction with any of
the widely used domain authentication schemes, so it can be applied at
or after the time the authentication scheme is evaluated.  Note that VBR
does not provide authentication; that is the job of the underlying
authentication scheme.  It provides certification, which is a different
thing.

>I saw two cases of "X MUST/SHOULD be Y; and if X _isn't_ Y, the result
is undefined.". To me, that is a recipe for misunderstanding,
incompatible implementations, and quarrel about interpretation of the
spec.

These are both good catches.

The first says this:

   All
   of the VBR-Info header fields in a single message MUST have identical
   mc= values.  The semantics of a message with non-identical mc=
   categories are undefined.

We agree that this could lead to incompatible implementations. The last
sentence can be dropped.

The second says this:

   If more than one TXT record exists at a name from a VBR record, the
   results are unspecified.

We agree that this could lead to incompatible implementations. The
sentence can be changed to:

   The VBR record MUST have only one TXT record.

>I also cannot wrap my brain around the concept that some third party 
>could "vouch" for e-mail coming out of someones laptop - if it's of a 
>certain type - and what if it isn't? It me took all through to the 
>"Changes" section before I fully realized that sender domain 
>authentication is a strict prerequisite for this, and I still don't 
>fully comprehend the value it would add (although I saw in the IETF 
>tools document tracker that Chris Newman really likes it, so it can't 
>be all bad ... ;-), but never mind, that's not the task at hand. ;-)

Vouching services will have different business models for how they
assure people that their vouching is worthwhile. That is definitely out
of scope for this document. Some models are like the ones we see today
with Return Path and Constant Contact; others will spring up, such as
trade groups vouching for their members. Another example might be that
the bank regulator in a country (such as the FDIC in the US) might
choose to vouch for the banks that it oversees. We do not expect that
every email user will want to use one or more vouching services, just
that, if they do, there should be a single interoperable protocol.

>Looking at the DNS parts of this, a few things caught my eye, and I
would at least like to make sure they are lifted up for closer
inspection.
>
>1) TXT record. Again! Needs to be fixed, unless they can provide a
>   _REALLY_ good explanation why TXT creates a better overall
>   architecture compared to defining a new record type. (Speed of
>   deployment has very little to do with good architecture in my
>   world, and usually means the opposite.)

We have been through this many times. The use case here is exactly the
same as for DKIM. The underscore used on the _vouch label prevents there
from being any possibility of collision with TXT records for actual
domain names. The paragraph near the end of section 5 ("Verifiers MUST
then check...") deals with the issue of wildcards and TXT records.

>2) It seems to make use of DNS "because it's there", rather than
>   because it's the optimal database mechanism for this, but that
>   said, it does fit ... for some not too negative value of "fit".

We don't understand this objection at all. As stated throughout the
document, VBR is for vouching for mail from a *domain name*. The lookups
are based on a domain name, and the responses are small single replies.
DNS seems like a perfect fit for that.

>3) It combines 3 semantically different entities in the lookup domain
>   name. You seem to have
>
>   a) The sender domain,
>   b) The separator "_vouch", and
>   c) The service locator.
>
>   While that strikes me as kind of "not how DNS was originally
>   intended to be used", at least the service locator is "to the
>   right" (closer to the root), which means that the client can
>   actually make good use of DNS caching, and they avoid hitting the
>   higher DNS echelons (root, TLD, ...) with subsequent queries. The
>   servers that will be hammered, will be the servers of the "vouching
>   service", which is as it should be. Basically, it's not worse than
>   any DNS based RBL list alreay in use.

We designed VBR the way we did because we knew that similar designs had
acceptable DNS characteristics.  There is no "service locator": there's
just the domain name of the vouching service.

>4) The DNS language is pretty sloppy, and needs to go through "boot
>   camp with a DNS sergeant". ;-)

We asked for such input during the development of the document, and we
heard no comments from the sergeants who said they would review it other
than a disagreement about TXT records.

>I note that there is no information
>   about how one goes from "the service locator" to the actual IP
>   address of the vouching service DNS server. It's "a list of domain
>   names of certification providers that the sender asserts will vouch
>   for this particular message." (sect 4.) Aha? And how do I use these
>   "domain names"? Is the service locator to be interpreted as a
>   lookup key for an A record? An AAAA record?  An SRV record? (If the
>   latter, what are the other parameters?) Or, do I pass it through a
>   NAPTR to obtain ... what? I would like to see that process
>   described in a more formal way.

The document says that the string queried is a domain name, and that the
domain name is queried for a TXT record. If it would help, we can add
"The recipient looks up the domain name in the DNS in the exact same
manner it looks up all other domain names." The protocol is agnostic to
whether A or AAAA records are returned.

>From his comment, we think that Liman maybe supposed that there had to
be some way to auto-discover vouching services. There is deliberately no
intention that vouching services can be found automatically. VBR is
about reputation, and the mail system's management has to decide for
itself what vouching service(s) it wants to use. One uses a vouching
service that one trusts, not just "one that is there".

>5) I notice that the document doesn't mention DNSSEC at all, which may
>   be intentional. It could be that they don't want to force people
>   into using DNSSEC (I can fully respect that), of that this is
>   intended to be an alternative to using DNSSEC, but this really
>   seems like an application where DNSSEC could actually be of some
>   use, and I would at least like to see a discussion section on that.

The protocol is agnostic to DNSSEC. There is no more reason to force a
user to use DNSSEC for this protocol than for any other protocol. DNSSEC
would indeed be of some use, just as it would be for any other protocol.

>6) In sec 5, par 9, the authors assert that the choice of the
>   separator label "_vouch" leads to "There will never be any
>   accidental overlap with a valid domain name."  That is not only
>   incorrect from a DNS perspective, it is bad terminology, and also a
>   questionable statement, even if you take the language aside. "will
>   never" are strong words, and however unlikely, it is _possible_
>   that the underscore will be made koscher in host names (which is
>   what they mean) in a distant future.

We can change "valid domain name" to "currently-valid domain name" or
"host names". _vouch is indeed a valid domain name, which is why we use
it in the DNS.

>7) At the end of section 5. we have one of the two "unspeifieds"
>   mentioned above: "If more than one TXT record exists at a name from
>   a VBR record, the reults are unspecified."  Why is that? Why not
>   specify "considered it to be an error - ignore it!" or "concatenate
>   them and treat them as one record", or at least something well
>   defined?

Agree; see above.

>On the non-DNS side, there are also questions in section 7: "Senders 
>SHOULD use DKIM (and MAY use DomainKeys, SPF, or SenderID)...". That 
>little "and" in the parenthesis - is that "DKIM _and_ any of the 
>following" or is it really "DKIM _or_ any of the following"? (It may be

>obvious to a native English speaker, but it's not to me. ;-)

We truly meant "and".

>... and in 7.1, where it's required that the VBR header lines be put
"immediately below the corresponding DKIM-Signature header field". What
if you have competing such requirements from other mail sub-protocols?

It is not required, it is recommended. The exact words are:

   o  The VBR-Info header field SHOULD be added in the header
      immediately below the corresponding DKIM-Signature header field.

>To be frank, since this is a Standards Track document, my view is that
it needs some "shaping up". I don't necessarily disapprove of the basic
idea, but I want more information to be able to judge better, and I want
better DNS language.

We hope the changes and explanations above cover all the issues.

>... and a different record type than TXT. :-)

We see no difference between the use in VBR and other standards-track
documents. We looked at the objections to re-use of TXT carefully and
found that none of them apply to VBR, given the way we purposely
designed the protocol.

>My assessment is that this exact document isn't ready for publication,
but may become so in a future revision, given more and wider review.

This document was informally reviewed by a WG (DKIM), by a group of
vendors with a great deal of technical knowledge (the Domain Assurance
Council), and went through a four-week IETF Last Call that generated
review. We are not sure what more we could have asked.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

Date: Wed, 04 Feb 2009 18:24:09 +0100
From: Mark Townsley <[email-masked]>
To: IETF DNS Directorate <[email-masked]>
Subject: [dns-dir] BIND config in an RFC

Do we have any RFCs with example config, say, from BIND? Would it be 
kosher to include that or not, just as a non-normative illustrative 
example for something.

Thanks,

- Mark

From: Olaf Kolkman <[email-masked]>
To: Mark Townsley <[email-masked]>
Date: Wed, 4 Feb 2009 13:25:30 -0500
Cc: IETF DNS Directorate <[email-masked]>
Subject: Re: [dns-dir] BIND config in an RFC

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-33--85823330
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On Feb 4, 2009, at 12:24 PM, Mark Townsley wrote:

> Do we have any RFCs with example config, say, from BIND? Would it be  
> kosher to include that or not, just as a non-normative illustrative  
> example for something.

I do not think that would be kosher. Speaking as an implementer it  
would almost feel like IETF endorsement of a product.

A 'pseudo-config' would be different.

--Olaf

--Apple-Mail-33--85823330
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-33--85823330--

Date: Wed, 4 Feb 2009 19:37:05 +0100
From: Peter Koch <[email-masked]>
To: Mark Townsley <[email-masked]>
Sender: Peter Koch <[email-masked]>
Cc: IETF DNS Directorate <[email-masked]>
Subject: Re: [dns-dir] BIND config in an RFC

On Wed, Feb 04, 2009 at 06:24:09PM +0100, Mark Townsley wrote:
> 
> Do we have any RFCs with example config, say, from BIND? Would it be 
> kosher to include that or not, just as a non-normative illustrative 
> example for something.

not sure what you're after here.  More often than not, people confuse
snippets of a standard DNS zone file with "BINBD config".  Zone file is
perfectly OK -- BIND config was maybe years ago, but there's enough diversity
today and not only, as Olaf said, should the IETF avoid the perception of
andorsing a specific product, nor should it support the misconception that
"DNS == BIND".  Any more conrete pointers?

-Peter

From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Olaf Kolkman <[email-masked]>
Date: Wed, 4 Feb 2009 23:38:42 +0100
Cc: IETF DNS Directorate <[email-masked]>
Subject: Re: [dns-dir] BIND config in an RFC

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-190--70631596
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 4 feb 2009, at 19.25, Olaf Kolkman wrote:

> On Feb 4, 2009, at 12:24 PM, Mark Townsley wrote:
>
>> Do we have any RFCs with example config, say, from BIND? Would it  
>> be kosher to include that or not, just as a non-normative  
>> illustrative example for something.
>
>
>
> I do not think that would be kosher. Speaking as an implementer it  
> would almost feel like IETF endorsement of a product.
>
> A 'pseudo-config' would be different.

Zone file format is defined (started in 1034, right(?)), but not the  
configuration of the software itself.

    Patrik

--Apple-Mail-190--70631596
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-190--70631596--

Content-class: urn:content-classes:message
Date: Thu, 5 Feb 2009 13:33:02 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
Subject: [dns-dir] BOF proposals for IETF-74

I apologize for the late warning. The IAB and IESG will be meeting in a
few hours to review the BOF requests for IETF-74. The information about
the BOFs and links to the relevant documents can be found at
http://trac.tools.ietf.org/bof/trac/wiki. If there are any comments or
concerns please send them to Ron and me until today 11:30AM ET.=20

Thanks and Regards,

Dan

From: Olaf Kolkman <[email-masked]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Date: Thu, 5 Feb 2009 08:08:00 -0500
Cc: IETF DNS Directorate <[email-masked]>
Subject: Re: [dns-dir] BIND config in an RFC

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-49--18473191
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

>>
>>
>> I do not think that would be kosher. Speaking as an implementer it  
>> would almost feel like IETF endorsement of a product.
>>
>> A 'pseudo-config' would be different.
>
> Zone file format is defined (started in 1034, right(?)), but not the  
> configuration of the software itself.

Correct. Zonefile format is defined.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

NB: The street at which our offices are located has been
renamed to the above.

--Apple-Mail-49--18473191
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-49--18473191--

Date: Thu, 5 Feb 2009 08:13:30 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dns-dir] BOF proposals for IETF-74

On Thu, Feb 05, 2009 at 01:33:02PM +0100, Romascanu, Dan (Dan) wrote:
> I apologize for the late warning. The IAB and IESG will be meeting in a
> few hours to review the BOF requests for IETF-74. The information about
> the BOFs and links to the relevant documents can be found at
> http://trac.tools.ietf.org/bof/trac/wiki. If there are any comments or
> concerns please send them to Ron and me until today 11:30AM ET. 

Note to DNS Mavens: the MIF proposal appears to encompass some tricky
split-brain processing.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

To: Andrew Sullivan <[email-masked]>
Comments: In-reply-to Andrew Sullivan <[email-masked]> message dated "Thu, 05 Feb 2009 08:13:30 -0500."
Date: Thu, 05 Feb 2009 09:03:53 -0500
From: Thomas Narten <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-dir] BOF proposals for IETF-74

> Note to DNS Mavens: the MIF proposal appears to encompass some tricky
> split-brain processing.  

Yes. One of the key "problems" associated with multihoming is how to
handle being multihomed into different administrative domains, where
you have differing DNS servers and split DNS. I.e., so it matters
which DNS server you query for a name (the one behind your VPN may
know about private names). And then, if your corporate DNS server
returns A records with private addresses, you want to force outgoing
connections to use use the interface associated with the VPN.

This is stuff that the current internet architecture just doesn't do,
and can't easily. I.e., when doing address selection or routing
packets, you don't always know about address realms and factor them in
to the degree that is needed to solve the "problem".

I am sympathetic to there being a real problem here. But I think most
people don't fully understand how difficult (impossible? ugly?)  a
solution would be.

Thomas

Date: Thu, 05 Feb 2009 15:07:13 +0100
From: Mark Townsley <[email-masked]>
To: Olaf Kolkman <[email-masked]>
Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, IETF DNS Directorate <[email-masked]>
Subject: Re: [dns-dir] BIND config in an RFC

Thanks guys... On context, this was prompted by an upcoming ID on how 
Google did its Google over IPv6 stuff (I know some of you are already 
quite familiar with how that was done).

- Mark

PS. The -00 *might* indeed have some bind config just for illustrative 
example, with clear indication that it will be removed in a future rev.

Olaf Kolkman wrote:
>>>
>>>
>>> I do not think that would be kosher. Speaking as an implementer it 
>>> would almost feel like IETF endorsement of a product.
>>>
>>> A 'pseudo-config' would be different.
>>
>> Zone file format is defined (started in 1034, right(?)), but not the 
>> configuration of the software itself.
>
>
>
> Correct. Zonefile format is defined.
>
> --Olaf
>
> -----------------------------------------------------------
> Olaf M. Kolkman                        NLnet Labs
>                                        Science Park 140,
> http://www.nlnetlabs.nl/               1098 XG Amsterdam
>
> NB: The street at which our offices are located has been
> renamed to the above.
>
>
>
>

To: Mark Townsley <[email-masked]>
Comments: In-reply-to Mark Townsley <[email-masked]> message dated "Thu, 05 Feb 2009 15:07:13 +0100."
Date: Thu, 05 Feb 2009 09:11:53 -0500
From: Thomas Narten <[email-masked]>
Cc: Olaf Kolkman <[email-masked]>, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, IETF DNS Directorate <[email-masked]>
Subject: Re: [dns-dir] BIND config in an RFC

> Thanks guys... On context, this was prompted by an upcoming ID on how 
> Google did its Google over IPv6 stuff (I know some of you are already 
> quite familiar with how that was done).

This sounds like a non-IETF individual submission.

BIND config would be fine there, IMO.

I.e., forcing them to provide a config file in psuedo-code that they
didn't use would seem a bit like make-work.

Thomas

Date: Thu, 05 Feb 2009 15:19:51 +0100
From: Mark Townsley <[email-masked]>
To: Thomas Narten <[email-masked]>
Cc: Olaf Kolkman <[email-masked]>, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6?=, =?ISO-8859-1?Q?m?= <[email-masked]>, IETF DNS Directorate <[email-masked]>
Subject: Re: [dns-dir] BIND config in an RFC

Thomas Narten wrote:
>> Thanks guys... On context, this was prompted by an upcoming ID on how 
>> Google did its Google over IPv6 stuff (I know some of you are already 
>> quite familiar with how that was done).
>>     
>
> This sounds like a non-IETF individual submission.
>   
Absolutely for the -00... who knows what happens to it in the future, 
but I don't think they have any sort of aspirations in any direction 
other than to provide the information to the community and get feedback.
> BIND config would be fine there, IMO.
>
> I.e., forcing them to provide a config file in psuedo-code that they
> didn't use would seem a bit like make-work.
>   
This is why I told them it would be OK (IMHO) for the -00, so I agree 
with you here.

Anyone object to Thomas' statement - that as long as the document 
remains within the "this is what Google did" space, then illustrative 
bind config is fine.... In any case, that question doesn't have to be 
answered right away, we can see what happens to the course of the 
document to decide.

Thanks,

- Mark
> Thomas

Date: Thu, 5 Feb 2009 10:00:49 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dns-dir] BOF proposals for IETF-74

On Thu, Feb 05, 2009 at 09:03:53AM -0500, Thomas Narten wrote:

> I am sympathetic to there being a real problem here. But I think most
> people don't fully understand how difficult (impossible? ugly?)  a
> solution would be.

Well, ugly anyway.

Lately I keep running into areas where real problems are being solved
by baling wire and spit.  I am coming to think that the central
problem is that we want to maintain the protocol's view of zones: they
are an administrative conveience that are visible in the
data-distribution parts of the protocol, but that are mostly invisible
to the DNS client and in any case are not signifiers of any real
administrative boundary other than, "This group of machines answers for
this part of the namespace."

The basic problem that I perceive is that people need either to know
_that_ there is some important administrative boundary (and what it
is); or they need to know that plus the status of certain propositions
about things inside those boundaries.

So, for instance, the publicsuffix.org people have a genuine problem
they're trying to solve (although, IMO, in a completely braindead
way), because they're trying to delineate between delegation-centric
and non-delegation-centric name spaces.  That's not a stupid problem:
knowing that different sites inside sun.com (and, heck, mysql.com) are
likely related to one another in a way that sun.com and ra.com are not
is a useful piece of information.  It is a natural extension of what
people use names for, and insisting that the name of a location
doesn't connote certain other things is probably a mistake.  If there
were some way to stake the DNS namespace to say, "here's what I'm a
part of," I think it would help.  I am aware, however, that the
publicsuffix.org fanboys aren't that interested in this idea.

The IDNAbis work has a different, but related problem.  One of the
things that seems to come out of the IDNAbis effort is that
internationalization isn't enough: one needs _localization_.  But to
do that, one needs to know the relevant locales.  That's all but
impossible at the moment.  However, if there were some easy way to
state one's administrative boundaries and to include in that
information a pointer to the policies of the domain, then the policy
could include some rules about locale (which, in this case, just means
which Unicode code-points are allowed in the zone, and maybe what the
mapping rules are from one set of code points to another if such a
mapping is needed).

Finally, the example that got me started in this thread seems to be a
namespace declaration problem: more than one DNS server will answer
authoritatively for the namespace, and you want to know which of them
you ought to prefer given other preferences you have about that
namespace.  Again, a policy could help.  For instance, a split-brain
system may answer queries for privatenames.example.com only to hosts
on some RFC 1918 network.  That policy information could be included
such that a client could look it up, discover that it has an interface
with an address in that range, and then send its queries for things in
that namespace on the appropriate interface.

What I've imagined is an SRV record in the zone for some underscore
name, and that points off to the policy service.  The policy thing is,
I imagine, something like IRIS (maybe it is IRIS).

The reason the above (well, something less hand-wavy) isn't in an I-D
yet is that every time I float this idea in front of anyone, I hear
unenthusiastic responses.  Some complain that it'll take a long time
to develop and deploy.  Others observe that something similar will
solve their own problem, so why would they bother with this elaborate
framework?  Finally, some wince because of the abuse of DNS, the
underscore name, or even the fact that this opens the door to the
publication of administrative boundaries (and that the DNS doesn't
make such boundaries explicit is regarded as a good thing).

Therefore, I havent' pursued it.  But if anyone thinks this is worth
attempting to write down in more detail, I suppose I'm willing.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Date: Thu, 05 Feb 2009 10:24:26 -0500
To: IETF DNS Directorate <[email-masked]>
From: Olafur Gudmundsson <[email-masked]>
Subject: Re: [dns-dir] BIND config in an RFC

--=====================_764666892==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Mark,
Having an illustration in an appendix of how X was done by product Y is fine by
me as long as the same information is in the main body of the document.

         Olafur

At 09:07 05/02/2009, Mark Townsley wrote:

>Thanks guys... On context, this was prompted by an upcoming ID on 
>how Google did its Google over IPv6 stuff (I know some of you are 
>already quite familiar with how that was done).
>
>- Mark
>
>PS. The -00 *might* indeed have some bind config just for 
>illustrative example, with clear indication that it will be removed 
>in a future rev.
>
>Olaf Kolkman wrote:
>>>>
>>>>
>>>>I do not think that would be kosher. Speaking as an implementer 
>>>>it would almost feel like IETF endorsement of a product.
>>>>
>>>>A 'pseudo-config' would be different.
>>>
>>>Zone file format is defined (started in 1034, right(?)), but not 
>>>the configuration of the software itself.
>>
>>
>>
>>Correct. Zonefile format is defined.
>>
>>--Olaf
>>
>>-----------------------------------------------------------
>>Olaf M. Kolkman                        NLnet Labs
>>                                        Science Park 140,
>>http://www.nlnetlabs.nl/               1098 XG Amsterdam
>>
>>NB: The street at which our offices are located has been
>>renamed to the above.
>>
>>
>>
>
>_______________________________________________
>dns-dir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dns-dir
>

--=====================_764666892==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<font size=3>Mark, <br>
Having an illustration in an appendix of how X was done by product Y is
fine by<br>
me as long as the same information is in the main body of the document.
<br><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Olafur<br>
<br>
At 09:07 05/02/2009, Mark Townsley wrote:<br><br>
<blockquote type=cite class=cite cite="">Thanks guys... On context, this
was prompted by an upcoming ID on how Google did its Google over IPv6
stuff (I know some of you are already quite familiar with how that was
done).<br><br>
- Mark<br><br>
PS. The -00 *might* indeed have some bind config just for illustrative
example, with clear indication that it will be removed in a future
rev.<br><br>
Olaf Kolkman wrote:<br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><br><br>
I do not think that would be kosher. Speaking as an implementer it would
almost feel like IETF endorsement of a product.<br><br>
A 'pseudo-config' would be different.</blockquote><br>
Zone file format is defined (started in 1034, right(?)), but not the
configuration of the software itself.</blockquote><br><br>
<br>
Correct. Zonefile format is defined.<br><br>
--Olaf<br><br>
-----------------------------------------------------------<br>
Olaf M.
Kolkman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NLnet Labs<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Science Park 140,<br>
<a href="http://www.nlnetlabs.nl/%A0%A0%A0%A0%A0%A0%A0%A0%A0%A0%A0%A0%A0%A0" eudora="autourl">
http://www.nlnetlabs.nl/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</a> 1098 XG Amsterdam<br><br>
NB: The street at which our offices are located has been<br>
renamed to the above.<br><br>
<br><br>
</blockquote><br>
_______________________________________________<br>
dns-dir mailing list<br>
[email-masked]<br>
<a href="https://www.ietf.org/mailman/listinfo/dns-dir" eudora="autourl">
https://www.ietf.org/mailman/listinfo/dns-dir</a><br><br>
</font></blockquote></body>
</html>

--=====================_764666892==.ALT--

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 10:51:33 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for February 12, 2009 Telechat

Please find below the preliminary agenda of the 2/12 IESG telechat.
Please review the relevant documents and send me your comments and
concerns until 2/11 COB the latest.=20

Thanks and Regards,

Dan

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-idr-flow-spec-05.txt
    Dissemination of flow specification rules (Proposed Standard) - 1 of
2
=20
    Token: David Ward
  o draft-ietf-ippm-duplicate-07.txt
    A One-Way Packet Duplication Metric (Proposed Standard) - 2 of 2=20
    Token: Lars Eggert

2.1.2 Returning Item
  o draft-ietf-forces-protocol-21.txt
    ForCES Protocol Specification (Proposed Standard) - 1 of 2=20
    Token: Ross Callon
  o draft-ietf-pim-rpf-vector-08.txt
    The RPF Vector TLV (Proposed Standard) - 2 of 2=20
    Token: David Ward

2.2 Individual Submissions
2.2.1 New Item
  o draft-arkko-arp-iana-rules-05.txt
    IANA Allocation Guidelines for the Address Resolution Protocol (ARP)

    (Proposed Standard) - 1 of 1=20
    Token: Russ Housley

2.2.2 Returning Item
NONE
2.2.3 For Action
  o draft-atlas-icmp-unnumbered-06.txt
    Extending ICMP for Interface and Next-hop Identification (Proposed=20
    Standard) - 1 of 1=20
    Note: Needs to go back to the WG due to the IPR declaration=20
    Token: Jari Arkko

3. Document Actions

3.1 WG Submissions
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.1.1 New Item
  o draft-ietf-eai-downgrade-11.txt
    Downgrading mechanism for Email Address Internationalization
(Experimental)=20
    - 1 of 3=20
    Note: Harald Alvestrand is document shepherd=20
    Token: Chris Newman
  o draft-ietf-ccamp-pc-and-sc-reqs-06.txt
    Requirements for the Conversion Between Permanent Connections and
Switched=20
    Connections in a Generalized Multiprotocol Label Switching (GMPLS)
Network=20
    (Informational) - 2 of 3=20
    Token: Ross Callon
  o draft-ietf-ccamp-gr-description-04.txt
    Description of the RSVP-TE Graceful Restart Procedures
(Informational)
- 3=20
    of 3=20
    Token: Ross Callon

3.1.2 Returning Item
  o draft-ietf-l2vpn-vpls-mcast-reqts-07.txt
    Requirements for Multicast Support in Virtual Private LAN Services=20
    (Informational) - 1 of 1=20
    Note: Bringing back to telechat to get attention on remaining
discusses.=20
    Token: Mark Townsley

3.2 Individual Submissions Via AD
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.2.1 New Item
NONE
3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor
	The IESG will use RFC 3932 responses: 1) The IESG has not
	found any conflict between this document and IETF work; 2) The
	IESG thinks that this work is related to IETF work done in WG
	<X>, but this does not prevent publishing; 3) The IESG thinks
	that publication is harmful to work in WG <X> and recommends
	not publishing at this time; 4) The IESG thinks that this
	document violates the IETF procedures for <X> and should
	therefore not be published without IETF review and IESG
	approval; 5) The IESG thinks that this document extends an
	IETF protocol in a way that requires IETF review and should
	therefore not be published without IETF review and IESG
approval.

	The document shepherd must propose one of these responses in
	the Data Tracker note and supply complete text in the IESG
	Note portion of the write-up. The Area Director ballot positions
	indicate consensus with the response proposed by the
	document shepherd.

	Other matters may be recorded in comments, and the comments will
	be passed on to the RFC Editor as community review of the
document.

3.3.1 New Item
  o draft-irtf-routing-history-09.txt
    Analysis of Inter-Domain Routing Requirements and History (Historic)
-
1 of=20
    2=20
    Token: Ross Callon
  o draft-irtf-routing-reqs-10.txt
    A Set of Possible Requirements for a Future Routing Architecture
(Historic)=20
    - 2 of 2=20
    Token: Ross Callon

Content-class: urn:content-classes:message
Date: Sun, 15 Feb 2009 12:43:09 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

Paul,

I still did not see a resolution to the issue of the TXT records. I know
that you and Lars-Johan Liman agreed to disagree on this, but other
folks on dns-dir seem to agree this is still a problem even with the
newly proposed text - see the messages from Patrik Falstrom and Andrew
Sullivan.  =20

http://www.ietf.org/mail-archive/web/dns-dir/current/msg00240.html
http://www.ietf.org/mail-archive/web/dns-dir/current/msg00239.html

I did not see a response to these on DNS-DIR.=20

Beyond this, there are a number of issues that were agreed to be fixed
by edits. I need to see either a revised I-D or RFC Editor notes that
include these edits before I can clear my DISCUSS.

DNS-DIR folks,

Please state your remaining objections if any to the answers provided by
Paul in the message I forwarded to the list

http://www.ietf.org/mail-archive/web/dns-dir/current/msg00241.html

Dan

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]=20
> Sent: Friday, February 13, 2009 7:29 PM
> To: Romascanu, Dan (Dan)
> Cc: John Levine; Arvel Hathcock
> Subject: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt
>=20
> According to=20
> <https://datatracker.ietf.org/idtracker/ballot/2922/>, you=20
> still have a discuss on draft-hoffman-dac-vbr-05.txt.
>=20
> You said "The DNS-Directorate review issues need a complete=20
> answer.", we replied with what we thought was a complete=20
> answer, and have not heard anything since then.
>=20
> Could you either remove your DISCUSS or let us know what else=20
> we need to do to resolve this? Thanks!
>=20
> --Paul Hoffman, Director
> --Domain Assurance Council
>=20

Content-class: urn:content-classes:message
Date: Sun, 15 Feb 2009 19:05:48 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

In-line.=20

Dan
=20

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]=20
> Sent: Sunday, February 15, 2009 8:00 PM
> To: Romascanu, Dan (Dan)
> Cc: John Levine; Arvel Hathcock; [email-masked]; Russ Housley
> Subject: RE: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt
>=20
> At 12:43 PM +0100 2/15/09, Romascanu, Dan (Dan) wrote:
> >Paul,
> >
> >I still did not see a resolution to the issue of the TXT records. I=20
> >know that you and Lars-Johan Liman agreed to disagree on this, but=20
> >other folks on dns-dir seem to agree this is still a problem=20
> even with=20
> >the newly proposed text - see the messages from Patrik Falstrom and=20
> >Andrew Sullivan.
> >
> >http://www.ietf.org/mail-archive/web/dns-dir/current/msg00240.html
> >http://www.ietf.org/mail-archive/web/dns-dir/current/msg00239.html
> >
> >I did not see a response to these on DNS-DIR.
>=20
> That's because we were not made aware that we were supposed=20
> to be following DNS-DIR. If you told us that and I lost the=20
> message, I apologize. I will start reading it now and will=20
> respond there.

I apologize, it's my fault I guess. I assumed that you are following the
DNS-DIR discussions. =20

>=20
> >Beyond this, there are a number of issues that were agreed=20
> to be fixed=20
> >by edits. I need to see either a revised I-D or RFC Editor=20
> notes that=20
> >include these edits before I can clear my DISCUSS.
>=20
> That works for me. Some ADs want us *not* to revise drafts,=20
> others insist on it. FWIW, I prefer your way (make edits so=20
> the AD in question can see them). I will also wind in the=20
> changes we agreed to for Lisa and Chris.

Just to be clear, the change control is with the shepherding AD - Russ
in this case. So please get his advice about whether and when to publish
a new I-D.=20

>=20
> --Paul Hoffman, Director
> --Domain Assurance Council
>=20

Date: Sun, 15 Feb 2009 14:26:18 -0500
From: Andrew Sullivan <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, John Levine <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

On Sun, Feb 15, 2009 at 12:43:09PM +0100, Romascanu, Dan (Dan) wrote:

> folks on dns-dir seem to agree this is still a problem even with the
> newly proposed text - see the messages from Patrik Falstrom and Andrew
> Sullivan.   

I think perhaps I wasn't as clear as I might have been in that
discussion.  The point of the bit,

> we've already given in on the brain-dead approach of using TXT records
> for DKIM.  So I guess we're stuck with it here.

was supposed to be that I think TXT records are an awful approach, but
now that it's all over DKIM anyway, this additional bit of horror
doesn't make things any worse.  So I'm not going to object out loud.
My apologies for being imprecise.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Date: Sun, 15 Feb 2009 10:00:22 -0800
To: "Romascanu, Dan (Dan)" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

At 12:43 PM +0100 2/15/09, Romascanu, Dan (Dan) wrote:
>Paul,
>
>I still did not see a resolution to the issue of the TXT records. I know
>that you and Lars-Johan Liman agreed to disagree on this, but other
>folks on dns-dir seem to agree this is still a problem even with the
>newly proposed text - see the messages from Patrik Falstrom and Andrew
>Sullivan.  
>
>http://www.ietf.org/mail-archive/web/dns-dir/current/msg00240.html
>http://www.ietf.org/mail-archive/web/dns-dir/current/msg00239.html
>
>I did not see a response to these on DNS-DIR.

That's because we were not made aware that we were supposed to be following DNS-DIR. If you told us that and I lost the message, I apologize. I will start reading it now and will respond there.

>Beyond this, there are a number of issues that were agreed to be fixed
>by edits. I need to see either a revised I-D or RFC Editor notes that
>include these edits before I can clear my DISCUSS.

That works for me. Some ADs want us *not* to revise drafts, others insist on it. FWIW, I prefer your way (make edits so the AD in question can see them). I will also wind in the changes we agreed to for Lisa and Chris.

--Paul Hoffman, Director
--Domain Assurance Council

Content-class: urn:content-classes:message
Date: Mon, 16 Feb 2009 12:26:49 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, John Levine <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

My question is whether there is any change in text that would improve or
better document the current status.=20

Dan
=20

> -----Original Message-----
> From: Andrew Sullivan [mailto:[email-masked]]=20
> Sent: Sunday, February 15, 2009 9:26 PM
> To: Romascanu, Dan (Dan)
> Cc: Paul Hoffman; Arvel Hathcock; Russ Housley;=20
> [email-masked]; John Levine
> Subject: Re: [dns-dir] Removing your DISCUSS on=20
> draft-hoffman-dac-vbr-05.txt
>=20
> On Sun, Feb 15, 2009 at 12:43:09PM +0100, Romascanu, Dan (Dan) wrote:
>=20
> > folks on dns-dir seem to agree this is still a problem even=20
> with the=20
> > newly proposed text - see the messages from Patrik Falstrom=20
> and Andrew
> > Sullivan.  =20
>=20
> I think perhaps I wasn't as clear as I might have been in=20
> that discussion.  The point of the bit,
>=20
> > we've already given in on the brain-dead approach of using=20
> TXT records=20
> > for DKIM.  So I guess we're stuck with it here.
>=20
> was supposed to be that I think TXT records are an awful=20
> approach, but now that it's all over DKIM anyway, this=20
> additional bit of horror doesn't make things any worse.  So=20
> I'm not going to object out loud.
> My apologies for being imprecise.
>=20
> A
>=20
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
>=20

Content-class: urn:content-classes:message
Date: Mon, 16 Feb 2009 16:39:45 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, John Levine <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: [dns-dir] FW: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

 DNS-DIR,

Please see the relevant parts of Paul Hoffman's response to the latest =
comments from Andrew and Patrik.=20

Dan

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]=20
Sent: Monday, February 16, 2009 5:36 PM
To: Romascanu, Dan (Dan)
Cc: Russ Housley; John Levine; Arvel Hathcock
Subject: RE: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

At 10:28 AM +0100 2/16/09, Romascanu, Dan (Dan) wrote:
>DNS-DIR is a directorate list, and  the access is restricted to members =

>of the directorate. Are you interested to become part of this=20
>directorate?

No. You said "I did not see a response to these on DNS-DIR." I tried to =
join the mailing list because I could not read the messages that you =
said I had to respond to unless I was a list member.

>If you are not interested I will just relay the relevant messages.=20
>Sorry for not catching this situation earlier.

OK. FWIW, you may want to review your other DISCUSSes and see if any of =
them are blocked by a similar deadly embrace.

>In the meantime, I am attaching the two relevant mails and will relay=20
>any other relevant messages.

Sounds good. Please let us know if these meet your needs. We fully =
understand that many people in the DNS Directorate have a strong style =
preference for using new RRTYPEs. However, based on well-established =
operational reasons, we chose to use the same technical methods that are =
used in the DKIM standard.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Andrew Sullivan said:

>we've already given in on the brain-dead approach of using TXT records =
for DKIM.  So I guess we're stuck with it here.

We fully agree. We use the exact same semantics that DKIM used so that =
we have the same DNS properties that the DKIM standard uses.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Patrik F=E4ltst=F6m said:

>One day you have a TXT record that by definition MUST have the same =
owner as another RR. And if that RR is also of type TXT, then you have a =
problem. Two TXT with same owner.

The only way for this to happen is for a future standard to define a =
different semantic for domain names that have _domainkey or _vouch =
labels in them. If the IETF allows such re-use of namespaces, then of =
course there can be problems in the future. We assume that will not =
happen for things on standards track, just as we assume that the IETF =
will issue a future standard to define a different semantic for an =
existing RRTYPE.

--Paul Hoffman, Director
--Domain Assurance Council

Content-class: urn:content-classes:message
Date: Mon, 16 Feb 2009 22:13:26 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: Paul Hoffman <[email-masked]>
Subject: [dns-dir] FW: I-D Action:draft-hoffman-dac-vbr-06.txt

 Folks who reviewed the I-D, please let me now if there are still
critical concerns left.=20

Thanks and Regards,

Dan

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]=20
Sent: Monday, February 16, 2009 11:10 PM
To: Cullen Jennings; Romascanu, Dan (Dan); Chris Newman
Cc: John Levine; Arvel Hathcock; Russ Housley
Subject: Fwd: I-D Action:draft-hoffman-dac-vbr-06.txt

Greetings again. We have just updated the VBR draft with the changes we
have sent to the IESG to date. We think this clears all of your DISCUSS
desires (other than maybe Dan needing to hear back from the DNS
Directorate). Please let us know if you still have open issues; if not,
please feel free to update your votes.

--Paul Hoffman

>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>	Title           : Vouch By Reference
>	Author(s)       : P. Hoffman, et al.
>	Filename        : draft-hoffman-dac-vbr-06.txt
>	Pages           : 14
>	Date            : 2009-02-16
>
>This document describes the Vouch By Reference (VBR) protocol.  VBR is=20
>a protocol for adding third-party certification to email.  It permits=20
>independent third parties to certify the owner of a domain name that is

>associated with received mail.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-dac-vbr-06.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader=20
>implementation to automatically retrieve the ASCII version of the=20
>Internet-Draft.
>
>
>[The following attachment must be fetched by ftp.  Command-click the=20
>URL below to ask your ftp client to fetch it.]=20
><ftp://ftp.ietf.org/internet-drafts/draft-hoffman-dac-vbr-06.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html or=20
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Date: Tue, 17 Feb 2009 09:52:25 -0500
From: Andrew Sullivan <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, John Levine <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

On Mon, Feb 16, 2009 at 12:26:49PM +0100, Romascanu, Dan (Dan) wrote:
> My question is whether there is any change in text that would improve or
> better document the current status. 

I doubt it.  I'm unhappy to say that we passed, some time ago, the
point where it's even possible to discuss whether TXT records are a
good idea for this use-case.  I preduct any attempt even to address
the topic will result in unresolvable differences of opinion.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 08:04:03 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for February 26, 2009 Telechat

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99329.A0F9D755
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Please find below the preliminary agenda of the 2/26 telechat. Please =
send me your comments and concerns until 2/25 COB.=20

Thanks and Regards,

Dan

2. Protocol Actions
	Reviews should focus on these questions: "Is this document a
	reasonable basis on which to build the salient part of the Internet
	infrastructure? If not, what changes would make it so?"

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-mediactrl-vxml-04.txt
    SIP Interface to VoiceXML Media Services (Proposed Standard) - 1 of =
2

    Token: Jon Peterson
  o draft-ietf-dime-qos-parameters-09.txt
    Quality of Service Parameters for Usage with Diameter (Proposed
Standard) -=20
    2 of 2=20
    Token: Dan Romascanu

2.1.2 Returning Item
NONE

2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
	Reviews should focus on these questions: "Is this document a reasonable
	contribution to the area of Internet engineering which it covers? If
	not, what changes would make it so?"

3.1.1 New Item
  o draft-ietf-rserpool-mib-11.txt
    Reliable Server Pooling MIB Module Definition (Experimental) - 1 of =
3

    Token: Magnus Westerlund
  o draft-ietf-mediactrl-architecture-04.txt
    An Architectural Framework for Media Server Control (Informational) =
-
2 of=20
    3=20
    Token: Jon Peterson
  o draft-ietf-pcn-architecture-09.txt
    Pre-Congestion Notification (PCN) Architecture (Informational) - 3 =
of
3=20
    Note: Scott Bradner ([email-masked]) is the Document Shepherd.=20
    Token: Lars Eggert

------_=_NextPart_001_01C99329.A0F9D755
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>FW: PRELIMINARY Agenda and Package for February 26, 2009 Telechat =
</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Please find below the preliminary agenda of the 2/26 =
telechat. Please send me your comments and concerns until 2/25 COB.<BR>
<BR>
Thanks and Regards,<BR>
<BR>
Dan<BR>
<BR>
<BR>
2. Protocol Actions<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviews should focus on these =
questions: &quot;Is this document a<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reasonable basis on which to =
build the salient part of the Internet<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; infrastructure? If not, what =
changes would make it so?&quot;<BR>
<BR>
<BR>
2.1 WG Submissions<BR>
2.1.1 New Item<BR>
&nbsp; o draft-ietf-mediactrl-vxml-04.txt<BR>
&nbsp;&nbsp;&nbsp; SIP Interface to VoiceXML Media Services (Proposed =
Standard) - 1 of 2<BR>
<BR>
&nbsp;&nbsp;&nbsp; Token: Jon Peterson<BR>
&nbsp; o draft-ietf-dime-qos-parameters-09.txt<BR>
&nbsp;&nbsp;&nbsp; Quality of Service Parameters for Usage with Diameter =
(Proposed<BR>
Standard) -<BR>
&nbsp;&nbsp;&nbsp; 2 of 2<BR>
&nbsp;&nbsp;&nbsp; Token: Dan Romascanu<BR>
<BR>
2.1.2 Returning Item<BR>
NONE<BR>
<BR>
2.2 Individual Submissions<BR>
2.2.1 New Item<BR>
NONE<BR>
2.2.2 Returning Item<BR>
NONE<BR>
<BR>
3. Document Actions<BR>
<BR>
3.1 WG Submissions<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviews should focus on these =
questions: &quot;Is this document a reasonable<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contribution to the area of =
Internet engineering which it covers? If<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not, what changes would make =
it so?&quot;<BR>
<BR>
3.1.1 New Item<BR>
&nbsp; o draft-ietf-rserpool-mib-11.txt<BR>
&nbsp;&nbsp;&nbsp; Reliable Server Pooling MIB Module Definition =
(Experimental) - 1 of 3<BR>
<BR>
&nbsp;&nbsp;&nbsp; Token: Magnus Westerlund<BR>
&nbsp; o draft-ietf-mediactrl-architecture-04.txt<BR>
&nbsp;&nbsp;&nbsp; An Architectural Framework for Media Server Control =
(Informational) -<BR>
2 of<BR>
&nbsp;&nbsp;&nbsp; 3<BR>
&nbsp;&nbsp;&nbsp; Token: Jon Peterson<BR>
&nbsp; o draft-ietf-pcn-architecture-09.txt<BR>
&nbsp;&nbsp;&nbsp; Pre-Congestion Notification (PCN) Architecture =
(Informational) - 3 of<BR>
3<BR>
&nbsp;&nbsp;&nbsp; Note: Scott Bradner ([email-masked]) is the Document =
Shepherd.<BR>
&nbsp;&nbsp;&nbsp; Token: Lars Eggert<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C99329.A0F9D755--

Date: Fri, 20 Feb 2009 09:19:50 -0500
To: "Romascanu, Dan (Dan)" <[email-masked]>, <[email-masked]>
From: Olafur Gudmundsson <[email-masked]>
Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for February  26, 2009 Telechat

--=====================_763581171==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

No documents in the DNS-early-warning data base.

Olafur

At 02:04 20/02/2009, Romascanu, Dan (Dan) wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C99329.A0F9D755"
>
>Please find below the preliminary agenda of the 2/26 telechat. 
>Please send me your comments and concerns until 2/25 COB.
>
>Thanks and Regards,
>
>Dan
>
>
>2. Protocol Actions
>         Reviews should focus on these questions: "Is this document a
>         reasonable basis on which to build the salient part of the Internet
>         infrastructure? If not, what changes would make it so?"
>
>
>2.1 WG Submissions
>2.1.1 New Item
>   o draft-ietf-mediactrl-vxml-04.txt
>     SIP Interface to VoiceXML Media Services (Proposed Standard) - 1 of 2
>
>     Token: Jon Peterson
>   o draft-ietf-dime-qos-parameters-09.txt
>     Quality of Service Parameters for Usage with Diameter (Proposed
>Standard) -
>     2 of 2
>     Token: Dan Romascanu
>
>2.1.2 Returning Item
>NONE
>
>2.2 Individual Submissions
>2.2.1 New Item
>NONE
>2.2.2 Returning Item
>NONE
>
>3. Document Actions
>
>3.1 WG Submissions
>         Reviews should focus on these questions: "Is this document 
> a reasonable
>         contribution to the area of Internet engineering which it covers? If
>         not, what changes would make it so?"
>
>3.1.1 New Item
>   o draft-ietf-rserpool-mib-11.txt
>     Reliable Server Pooling MIB Module Definition (Experimental) - 1 of 3
>
>     Token: Magnus Westerlund
>   o draft-ietf-mediactrl-architecture-04.txt
>     An Architectural Framework for Media Server Control (Informational) -
>2 of
>     3
>     Token: Jon Peterson
>   o draft-ietf-pcn-architecture-09.txt
>     Pre-Congestion Notification (PCN) Architecture (Informational) - 3 of
>3
>     Note: Scott Bradner ([email-masked]) is the Document Shepherd.
>     Token: Lars Eggert
>
>
>
>_______________________________________________
>dns-dir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dns-dir

--=====================_763581171==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<font size=3><br>
No documents in the DNS-early-warning data base. <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
Olafur<br><br>
At 02:04 20/02/2009, Romascanu, Dan (Dan) wrote:<br>
<blockquote type=cite class=cite cite="">Content-class:
urn:content-classes:message<br>
Content-Type: multipart/alternative;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
boundary=&quot;----_=_NextPart_001_01C99329.A0F9D755&quot;<br><br>
</font><font size=2>Please find below the preliminary agenda of the 2/26
telechat. Please send me your comments and concerns until 2/25
COB.<br><br>
Thanks and Regards,<br><br>
Dan<br><br>
<br>
2. Protocol Actions<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviews should focus on these
questions: &quot;Is this document a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reasonable basis on which to
build the salient part of the Internet<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; infrastructure? If not, what
changes would make it so?&quot;<br><br>
<br>
2.1 WG Submissions<br>
2.1.1 New Item<br>
&nbsp; o draft-ietf-mediactrl-vxml-04.txt<br>
&nbsp;&nbsp;&nbsp; SIP Interface to VoiceXML Media Services (Proposed
Standard) - 1 of 2<br><br>
&nbsp;&nbsp;&nbsp; Token: Jon Peterson<br>
&nbsp; o draft-ietf-dime-qos-parameters-09.txt<br>
&nbsp;&nbsp;&nbsp; Quality of Service Parameters for Usage with Diameter
(Proposed<br>
Standard) -<br>
&nbsp;&nbsp;&nbsp; 2 of 2<br>
&nbsp;&nbsp;&nbsp; Token: Dan Romascanu<br><br>
2.1.2 Returning Item<br>
NONE<br><br>
2.2 Individual Submissions<br>
2.2.1 New Item<br>
NONE<br>
2.2.2 Returning Item<br>
NONE<br><br>
3. Document Actions<br><br>
3.1 WG Submissions<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviews should focus on these
questions: &quot;Is this document a reasonable<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contribution to the area of
Internet engineering which it covers? If<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not, what changes would make
it so?&quot;<br><br>
3.1.1 New Item<br>
&nbsp; o draft-ietf-rserpool-mib-11.txt<br>
&nbsp;&nbsp;&nbsp; Reliable Server Pooling MIB Module Definition
(Experimental) - 1 of 3<br><br>
&nbsp;&nbsp;&nbsp; Token: Magnus Westerlund<br>
&nbsp; o draft-ietf-mediactrl-architecture-04.txt<br>
&nbsp;&nbsp;&nbsp; An Architectural Framework for Media Server Control
(Informational) -<br>
2 of<br>
&nbsp;&nbsp;&nbsp; 3<br>
&nbsp;&nbsp;&nbsp; Token: Jon Peterson<br>
&nbsp; o draft-ietf-pcn-architecture-09.txt<br>
&nbsp;&nbsp;&nbsp; Pre-Congestion Notification (PCN) Architecture
(Informational) - 3 of<br>
3<br>
&nbsp;&nbsp;&nbsp; Note: Scott Bradner ([email-masked]) is the Document
Shepherd.<br>
&nbsp;&nbsp;&nbsp; Token: Lars Eggert<br><br>
<br><br>
</font><font size=3>_______________________________________________<br>
dns-dir mailing list<br>
[email-masked]<br>
<a href="https://www.ietf.org/mailman/listinfo/dns-dir" eudora="autourl">
https://www.ietf.org/mailman/listinfo/dns-dir</a></font></blockquote>
</body>
</html>

--=====================_763581171==.ALT--

Content-class: urn:content-classes:message
Date: Sun, 22 Feb 2009 15:53:14 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
Subject: [dns-dir] FW: Internal WG Review: Recharter of Routing Over Low power and Lossy networks (roll)

If there are any questions, comments or concerns please let me or Ron
know before COB 2/25.=20

Thanks and Regards,

Dan=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Saturday, February 21, 2009 12:29 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Internal WG Review: Recharter of Routing Over Low power and
Lossy networks (roll)=20

A new charter for the Routing Over Low power and Lossy networks working
group (roll) in the Routing Area of the IETF is being considered.  The
draft charter is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

Routing Over Low power and Lossy networks (roll)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Current Status: Active Working Group

Last Modified: 2009-02-04

Additional information is available at tools.ietf.org/wg/roll=20

Chair(s):

JP Vasseur [[email-masked]]
David Culler [[email-masked]]=20

Routing Area Director(s):

Ross Callon [[email-masked]]
David Ward [[email-masked]]=20

Routing Area Advisor:
David Ward [[email-masked]]=20

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: http://www.ietf.org/mailman/listinfo/roll
Archive: http://www.ietf.org/mail-archive/web/roll/

Description of Working Group:

Low power and Lossy networks (LLNs) are made up of many embedded devices
with limited power, memory, and processing resources. They are
interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
Low Power WiFi, wired or other low power PLC (Powerline Communication)
links. LLNs are transitioning to an end-to-end IP-based solution to
avoid the problem of non-interoperable networks ?interconnected by
protocol translation gateways and proxies.=20

Generally speaking, LLNs have at least five distinguishing
characteristics:=20
- LLNs operate with a hard, very small bound on state.
- In most cases, LLN optimize for saving energy.
- Typical traffic patterns are not simply unicast flows (e.g. in some
cases most if not all traffic can be point to multipoint).
- In most cases, LLNs will be employed over link layers with restricted
  frame-sizes, thus a routing protocol for LLNs should be specifically
adapted for such link layers.=20
- LLN routing protocols have to be very careful when trading off
efficiency for generality; many LLN nodes do not have resources to
waste.

These specific properties cause LLNs to have specific routing
requirements.=20
As shown in a protocol survey existing routing protocols (in their
current
form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific
routing requirements.

The Working Group is focused on routing issues for LLN.

There is a wide scope of application areas for LLNs, including
industrial
=20
monitoring, building automation (HVAC, lighting, access ?control, fire),
connected homes, healthcare, environmental monitoring, urban sensor
networks (e.g. Smart Grid), asset tracking. The Working Group focuses on
routing solutions for a subset of these: industrial, connected home,
building and urban? sensor networks for which routing requirements have
been specified. These application-specific routing requirement documents
will be used for protocol design.

The Working Group focuses only on IPv6 routing architectural framework
for these application scenarios. The Framework will take into
consideration various aspects including high reliability in the presence
of time varying loss characteristics and connectivity while permitting
low-power operation with
=20
very modest memory and CPU pressure in networks potentially comprising a
very large number (several thousands) of nodes.=20

The Working Group will pay particular attention to routing security and
manageability (e.g., self routing configuration) issues. It will also
need to consider the transport characteristic the routing protocol
messages will experience. Mechanisms that protect an LLN from congestion
collapse or that establish some degree of fairness between concurrent
communication sessions are out of scope of the Working Group. It is
expected that upper-layer applications utilizing LLNs define appropriate
mechanisms.

Work Items:

- Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for routing in
LLNs.

- Provide an architectural framework for routing and path selection at
  Layer 3 (Routing for LLN Architecture) that addresses such issues as
  whether LLN routing require a distributed and/or centralized path
computation
  models, whether additional hierarchy is necessary and how it is
applied.
=20
  Manageability will be considered with each approach, along with
various

  trade-offs for maintaining low power operation, including the presence

  of non-trivial loss and networks with a very large number of nodes.

- Produce a routing security framework for routing in LLNs.

- Protocol work: In light of the application specific routing
requirements, the Working Group will either specify a new protocol
and/or will select an existing routing protocol (with the appropriate
extensions in cooperation with the relevant Working Group).

- Documentation of applicability statement of ROLL routing protocols.

Goals and Milestones:

Done Submit Routing requirements for Industrial applications to the IESG
to be considered as an Informational RFC.

Done Submit Routing requirements for Connected Home networks
applications to the IESG to be considered as an Informational RFC.

Done Submit Routing requirements for Building applications to the IESG
to be considered as an Informational RFC.

Done Submit Routing requirements for Urban networks applications to the
IESG to be considered as an Informational RFC.

July 2009 Submit Routing metrics for LLNs document to the IESG to be
considered as a Proposed Standard.

Feb 2009 Submit Protocol Survey to the IESG to be considered as an
Informational RFC.

April 2009 Submit Security Framework to the IESG to be considered as an
Informational RFC

May 2009   Submit the Routing for LLNs Architecture document to the IESG
as an Informational RFC.

July 2009  Submit first draft of ROLL routing protocol specification as
Proposed Standard.

Nov 2009   Submit first draft of the MIB module of the ROLL routing
protocol specification.

Feb 2010   Submit the ROLL routing protocol specification to the IESG as
Proposed Standard.

March 2010 Submit the MIB module of the ROLL routing protocol
specification to the IESG as Proposed Standard.

April 2010 Evaluate WG progress, recharter or close.

Content-class: urn:content-classes:message
Date: Sun, 22 Feb 2009 16:08:32 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
Subject: [dns-dir] FW: Internal WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf)

If there are any questions, comments or concerns please let me or Ron
know before COB 2/25.=20

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Friday, February 20, 2009 8:31 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Internal WG Review: Recharter of Ad-Hoc Network
Autoconfiguration (autoconf)=20

A new charter for the Ad-Hoc Network Autoconfiguration working group
(autoconf) in the Internet Area of the IETF is being considered.  The
draft charter is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

Ad-Hoc Network Autoconfiguration (autoconf)
-------------------------------------------------------------
Last Modified: 2009-02-18=20
=20
Cuurent Status: Active Working Group=20
=20
Additional information is available at tools.ietf.org/wg/autoconf=20
=20
Chair(s):=20
Ryuji Wakikawa [[email-masked]] Thomas Clausen
[[email-masked]]=20
=20
Internet Area Director(s):=20
Jari Arkko [[email-masked]]
Mark Townsley [[email-masked]]=20
=20
Internet Area Advisor:=20
Jari Arkko [[email-masked]]=20
=20
Mailing Lists:=20
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
Archive:=20
http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html=20
=20
Description of Working Group:=20
=20
In order to communicate among themselves, ad hoc nodes (refer to RFC
2501) need to configure their network interface(s) with local addresses
that are valid within an ad hoc network. Ad hoc nodes may also need to
configure globally routable addresses, in order to communicate with
devices on the Internet. From the IP layer perspective, an ad hoc
network presents itself as a L3 multi-hop network formed over a
collection of links.=20
=20
The main purpose of the AUTOCONF WG is to describe the addressing model
for ad hoc networks and how nodes in these networks configure their
addresses. It is required that such models do not cause problems for ad
hoc-unaware parts of the system, such as standard applications running
on an ad hoc node or regular Internet nodes attached to the ad hoc
nodes. This group's effort may include the development of new protocol
mechanisms, should the existing IP autoconfiguration mechanisms be found
inadequate. However, the first task of the working group is to describe
one practical addressing model for ad hoc networks.=20
=20
Once this sole work item is completed, the group can be rechartered to
work on additional issues.=20
=20
Goals and Milestones:=20
=20
Apr 2009 Submit initial draft on address configuration in ad hoc
networks Sep 2009 Submit address configuration draft to IESG as
Informational or close WG