[DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Christopher Wood]

(I joined the list late so I don't have the thread to use for a direct reply. 
Sorry!)

On Tue, Sep 24, 2019 at 3:19 PM Erik Nygren wrote:
> Following discussions around the "HTTPSSVC" record proposal in Montreal
with the DNSOP, HTTP and TLS WGs, we've updated what was previously
"draft-nygren-httpbis-httpssvc-03".  The new version is
"draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
feedback from the WG discussions, as well as feedback from discussions with
the TLS WG (as we'd like to see this replace the need for a separate ESNI
record).

> We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs
can go against:  https://github.com/MikeBishop/dns-alt-svc

I would also like to see this adopted by the WG. Thanks to Erik, Ben, and Mike 
for their work!

Best,
Chris

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Tommy Pauly]

> On Sep 24, 2019, at 6:17 AM, Erik Nygren  wrote:
> 
> Following discussions around the "HTTPSSVC" record proposal in Montreal with 
> the DNSOP, HTTP and TLS WGs, we've updated what was previously 
> "draft-nygren-httpbis-httpssvc-03".  The new version is 
> "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the 
> feedback from the WG discussions, as well as feedback from discussions with 
> the TLS WG (as we'd like to see this replace the need for a separate ESNI 
> record).
> 
> In particular, it generalizes the record into a new "SVCB" record which 
> doesn't have any protocol-specific semantics.  It also defines an "HTTPSSVC" 
> record that is compatible with SVCB (sharing a wire-format and parameter 
> registry) and which defines the HTTP(S)-specific semantics such as bindings 
> to Alt-Svc.  Other protocols can either define bindings directly to SVCB or 
> can define their own RR Type (which should only ever be needed if there is a 
> need to use the record at a zone apex).
> 
> We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs 
> can go against:  https://github.com/MikeBishop/dns-alt-svc 
> 
> Major changes from "draft-nygren-httpbis-httpssvc-03" include:
> 
> * Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the 
> HTTPS-specific functionality and text to its own portion of the document).
> * Elimination of the SvcRecordType field (and making the SvcRecordType 
> implicit)
> * Changing the wire format of parameters from being in Alt-Svc text format to 
> a more general binary key/value pair format (with a mapping to Alt-Svc for 
> HTTPSSVC).
> * Adding optional "ipv4hint" and "ipv6hint" parameters.
> * Quite a few cleanups and clarifications based on input (and we undoubtedly 
> have more left to go)
> 
> This retains support for all of the use-cases that the previous HTTPSSVC 
> record had (such as for covering the ANAME / CNAME-at-the-zone-apex use-case).
> 
> Feedback is most welcome.  If the TLS WG is going to use this instead of a 
> separate ESNI record, there is a desire to make progress on this fairy 
> quickly.

I wanted to express support for getting this work adopted in DNSOP, and ideally 
doing so relatively soon so that we can unblock work on ESNI. From an OS 
implementor perspective, I'd really prefer to have an RR type that can be used 
for ESNI defined from DNSOP, and done so in a way (as this proposal does) that 
can be expanded to include other information like Alt-Svc, and even properties 
like support for DoH, etc.

I'd also ask that if this work is adopted, an early IANA allocation be made for 
the RR type once the basic record content and format is agreed upon.

Thanks to the authors for their work on this solution!

Best,
Tommy

> 
>Erik
> 
> -- Forwarded message -
> From: mailto:internet-dra...@ietf.org>>
> Date: Mon, Sep 23, 2019 at 7:01 PM
> Subject: New Version Notification for draft-nygren-dnsop-svcb-httpssvc-00.txt
> To: Mike Bishop mailto:mbis...@evequefou.be>>, Erik 
> Nygren mailto:erik%2bi...@nygren.org>>, Benjamin 
> Schwartz mailto:bem...@google.com>>
> 
> 
> 
> A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
> has been successfully submitted by Benjamin Schwartz and posted to the
> IETF repository.
> 
> Name:   draft-nygren-dnsop-svcb-httpssvc
> Revision:   00
> Title:  Service binding and parameter specification via the DNS (DNS 
> SVCB and HTTPSSVC)
> Document date:  2019-09-22
> Group:  Individual Submission
> Pages:  33
> URL:
> https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt 
> 
> Status: 
> https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/ 
> 
> Htmlized:   
> https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 
> 
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc 
> 
> 
> 
> Abstract:
>This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
>types to facilitate the lookup of information needed to make
>connections for origin resources, such as for HTTPS URLs.  SVCB
>records allow an origin to be served from multiple network locations,
>each with associated parameters (such as transport protocol
>configuration and keying material for encrypting TLS SNI).  They also
>enable aliasing of apex domains, which is not possible with CNAME.
>The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP
>origins.  By providing more information to the client before it
>attempts to establish a connection, these records offer potential

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Loganaden Velvindron  writes:

> I'm ok with the latest revision.

Awesome, thanks!

> Just a small request: John Todd from quad9 sent his feedback, so it's
> fair to credit him in the next revision of the draft.

Yep, fixed.  Thanks for that.
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Extended DNS Errors
Authors : Warren Kumari
  Evan Hunt
  Roy Arends
  Wes Hardaker
  David C Lawrence
Filename: draft-ietf-dnsop-extended-error-10.txt
Pages   : 13
Date: 2019-09-27

Abstract:
   This document defines an extensible method to return additional
   information about the cause of DNS errors.  Though created primarily
   to extend SERVFAIL to provide additional information about the cause
   of DNS and DNSSEC failures, the Extended DNS Errors option defined in
   this document allows all response types to contain extended error
   information.  Extended DNS Error information does not change the
   processing of RCODEs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-10
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-ietf-dnsop-extended-error status

[Wes Hardaker]

I've gone through everyone's (wonderful) comments and have addressed
almost all of them, and published a -10.  Please let me know if you
think I missed anything.  Responses to the comments will be sent out
shortly.

(and sorry for the delay on this ; day-job hit me over the head hard in
the last three weeks )

Two outstanding topics:

1) A number of people have suggested adding references to other
RFCs/documents to many of the error codes.  This is probably a good
idea.  A beer or other drink in Singapore to anyone willing to do the
work to give me a list of references to add for each code.

2) One outstanding topic of discussion that I think we need to decide to
handle or table till a future document: how do we handle forwarding,
chained resolvers, and caching.  Puneed brought this up most recently in
his comments.  In the past we've pseudo-agreed that it will be rather
complex to document how to handle forwarding, etc, when some of the
error context will change upon a forward, for example.  IE,
forwarding/caching/whatever rules may end up being code specific and may
require a *lot* more thought.  So, IMHO, we have choices:

A) Label these situations as "undefined behavior" and define it in a
future document after we get more experience with deployment.  This is
typically where I've landed opinion-wise in the past, and still do
mostly now.

B) Document globally how to handle various cases (and we'll need to
enumerate them)

C) Document how to handle each one independently (or as an override if
needed to a global policy)

D) Your option here

So really, this first comes down to how important is it we handle this
case set before it goes out the door?

-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Puneet Sood  writes:

Hi Puneet,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.5 TODO Puneet Sood
~

  I got around to review the draft only recently and have made an
  attempt to avoid points of discussion that have been resolved since
  IETF Prague. Apologies in advance for any duplicates.


* 14.5.0.1 DONE 1. Introduction and background

  Para 2: "A good example of issues that would benefit ..."  Comment:
  The paragraph leads up to the conclusion that the EDE codes will be
  helpful to a client to decide between retry and stopping.  Since the
  consensus is that the EDEs are purely diagnostic, it would be good to
  reiterate that at the end of this paragraph.

  + Response from Viktor: For the record, while that was
  "diagnostic" was my take on the purpose of these codes, reading other
  responses, I am not sure that's yet the consensus view...  I could
  also live with these being actionable, provided the text is then more
  clear on how to do that correctly

  If the actions based on these codes are arbitrary choices for each
  implementation, with not even a clear correspondence with associated
  RCODEs, that feels like too much rope to me...

  Eric Orth's comment from Sept 17 is also relevant here (no one has
  responded to it yet). Quoting the last bullet from his response here
  for reference:
  [https://mailarchive.ietf.org/arch/msg/dnsop/GTg8wa7lQ-VoBFcp_P5tT4VuQhE]
  *Something like "applications MUST NOT act on EDE" or "applications
  MUST NOT change rcode processing" does not seem reasonable to me.  Way
  too unclear what "diagnostic" processing is reasonable and allowed or
  not.  And potentially limits applications from doing processing based
  on very reasonable or obvious interpretations of the received
  rcode/EDE combinations."

  + Response: Paul H. gave us language to put in both the abstract and
introduction to address this.  Let me know if you think it doesn't
address this issue.


* 14.5.0.2 TODO 2. Extended Error EDNS0 option format / forwarding /etc/

  Final para: "The Extended DNS Error (EDE) option can be included in
  any response (SERVFAIL, NXDOMAIN, REFUSED, and even NOERROR, etc) to a
  query that includes OPT Pseudo-RR [RFC6891]. ..."

  Comment: Given the level of discussion around behavior when
  sending/receiving the EDE option, there should be some more text
  giving guidance on behavior.

  a. For recursive resolvers, it may be worth pointing that it is not
  expected to copy/forward EDE values received from authoritative
  nameservers to their clients.  b. What is the expectation on caching
  for the EDE code generated by a recursive resolver in response to a
  query? My expectation is that it will be cached (if the answer itself
  is cached) so the next response has the same EDE code.  c. Truncation:
  In case a response including the EDE option with EXTRA-TEXT filled in
  exceeds the effective UDP payload size, what is the desired behavior
  for the EDE option? Should the EXTRA-TEXT field be left empty in favor
  of filling in other RR types? Should the response be marked truncated
  to require a re-query over TCP?

  This is unlikely for failures but could happen when DNSSEC validation
  could not be performed due to unsupported digest type.

  + Response: good questions, and I think the WG needs to think about
whether to add that much more data.


* 14.5.0.3 DONE 3.14 Extended DNS Error Code 13 - Cached Error

  The resolver has cached SERVFAIL for this query.

  Comment: To match the text the name should be "Cached SERVFAIL".


* 14.5.0.4 NOCHANGE 5. Security Considerations

  Para 2: "This information is unauthenticated information, and an
 attacker (e.g a MITM or malicious recursive server) could insert an
 extended error response into already untrusted data ..."  Comment:
 Agree with some other comments that this is not relevant since no
 action is expected to be taken based on EDEs.  Comment: There are
 ideas in the thread to have links to info in the EXTRA-TEXT and
 possibly display it to users. I guess the usual warnings to not
 click on potentially unsafe links apply.

  + Yeah, it really would be remiss to leave out that point.  There may
be nothing we can do, but the whole point of a security
consideration is to properly disclose any known threats/issues.

  Thanks, Puneet




-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Stephane Bortzmeyer  writes:

Thanks Stephane,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.3 DONE Stephane Bortzmeyer
~

  IMHO, the document is good. I like the fact there is no longer a
  limitation of a given EDE to some RCODEs (it makes things simpler).

  Some details, all editorial:


14.3.1 DONE it could be a good idea to add more specific references for the
---

  EDE. For instance, 3 "Stale Answer" could have a reference to
  draft-ietf-dnsop-serve-stale.

  + Rseponse that seems popular; I'll try to do this where I can.


14.3.2 DONE I think that many people will be confused with 15, 16, 17 and 18.
-

  Suggestions:

  * remove 18, which is redundant with 15 (if the user chooses the
  resolver, and he should have the right to do so, 15 and 18 are the
  same). 18 is meaningful only if the user does have a simple way to
  change this behaviour.
  * Add to the definition of 15 "The policy was decided by the server
  administrators"
  * Add to the definition of 16 "This means that the policy was
  not decided by the server administrators, and it is probably useless
  to complain to them".

  + Response: Those three codes were supplied in a previous comment
round and they are supposed to indicate policies being applied from
different sources.  Can you check the new text of them to see if
they are more understandable now?


-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

[Wes Hardaker]

Paul Hoffman  writes:

Thanks Paul,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.8 DONE Paul Hoffman previously
~

14.8.1 DONE Proposal: add the following sentence to the end of the abstract:


  "Extended error information does not change the processing of RCODEs."


14.8.2 DONE Proposal: add to the end of the Introduction: Applications MUST NOT
---

  change the processing of RCODEs in messages based on extended error
  codes.



-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

[Wes Hardaker]

Tony Finch  writes:

> Some questions about the intended meanings...

Thanks Tony,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.9 DONE Tony Finch in a sub thread to Paul


  Some questions about the intended meanings...


14.9.1 DONE 3.6.  Extended DNS Error Code 5 - DNSSEC Indeterminate
--

  If I remember correctly, there isn't a consistent definition of what
  "indeterminate" means. Perhaps it's worth adding a reference to the
  intended definition.

  [ actually maybe all the codes could have citations to where the error
  cases are mentioned in existing specifications, perhaps with a comment
  that the citations are not intended to be exhausive ]

  + Response: good point.  I'll use a reference to 4035.  We'll have to
collect references for the rest...  That's a good (and painful)
idea.


14.9.2 DONE 3.5.  Extended DNS Error Code 4 - Forged Answer
---

  3.16.  Extended DNS Error Code 15 - Blocked 3.17.  Extended DNS Error
  Code 16 - Censored 3.19.  Extended DNS Error Code 18 - Filtered

  I don't understand the shades of meaning that these are supposed to
  distinguish.

  wrt "filtered", the description implies vaguely RPZ flavoured
  filtering, but it mentions a REFUSED RCODE which isn't what a sensible
  implementation would use for that purpose, so I am more confused.

  3.18.  Extended DNS Error Code 17 - Prohibited

  If I understand correctly, the four above are about the qname whereas
  this is about the client? The ordering is a bit confusing.

  + Response: Those three codes were supplied in a previous comment
round and they are supposed to indicate policies being applied from
different sources.  Can you check the new text of them to see if
they are more understandable now?


14.9.3 DONE 3.21.  Extended DNS Error Code 20 - Lame


  This needs to be split into two: server doesn't know about the zone
  queried for (typically RCODE=REFUSED), and server knows about the zone
  but it has expired (typically RCODE=SERVFAIL).

  Resolvers handling RD=0 queries typically answer from cache or would
  answer REFUSED/Prohibited, I would have thought.

  + Response: I created an "Invalid Data" error code to handle this.
Does this work for you?


-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.txt

[Wes Hardaker]

Viktor Dukhovni  writes:

Thanks Viktor,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.1 DONE Viktor Dukhovni
~~~

14.1.1 DONE Introduction 3rd paragraph (missing verb, extra period):


  [...] These extended DNS error codes [are?] described in this document
  and can be used by any system that sends DNS queries and receives a
  response containing an EDE option.. [...]


14.1.2 DONE With respect to the much discussed caveat:
--

  This document does not allow or prohibit any particular extended error
  codes and information be matched with any particular RCODEs.  Some
  combinations of extended error codes and RCODEs may seem nonsensical
  (such as resolver-specific extended error codes in responses from
  authoritative servers), so systems interpreting the extended error
  codes MUST NOT assume that a combination will make sense.  Receivers
  MUST be able to accept EDE codes and EXTRA-TEXT in all messages,
  including even those with a NOERROR RCODE.

  My take is that when the (12 bit EDNS) RCODE and new extended error
  are in apparent conflict, I should treat the RCODE as definitive, and
  ignore the extended error code.  That is, the extended error can
  *refine* but not contradict the status indicated by the RCODE.  If
  that's correct, perhaps it should be stated explicitly.  If not
  correct, then a clarification is perhaps still in order.

  + Response: there seems to be consensus around this and I adopted
Paul's text to clarify this


14.1.3 DONE Section 2, 3rd bullet:  s/index to/index into/
--

  The INFO-CODE serves as an index to the "Extended DNS Errors" registry
  Section 4.1.


14.1.4 DONE Section 2, 4th bullet: s/be take/be taken/
--

  Care should be take not to leak private information that an observer
  would not otherwise have access to, such as account numbers.


14.1.5 NOCHANGE account numbers and privacy
---

  I find "such as account numbers" a bit of a non sequitur (what account
  numbers?) I'd drop this, or produce a more transparent example.

  + Response: I agree, it's a bit of an unusual statement.  But it was
suggested by Shane Kerr in the summer and if you want to suggest
better text for replacing it, I need a real suggestion as deleting
it would delete his desire to have an example in there (which I
agree with, FWIW).  Maybe "account name" would be a middle ground?


14.1.6 DONE Section 3.2 (code 2), may warrant more guidance on when this is
---

  appropriate.  AFAIK, there is nothing wrong with all DNSKEY algorithms
  being unsupported, provided the same holds for the DS RRset.  So,
  while I see a use-case for code 3 (all DS unsupported, perhaps to
  signal why the AD bit is not set, despite the non-empty DS RRset), I
  don't understand when one would use code 2.

  + Vladimír Čunát adds

I do fail to understand the split codes 1 and 2 for all DS/DNSKEY
algorithms being unsupported, and it actually makes me wonder how to
exactly write the resolver code that would set this pair.  For
validation I need at least one usable DS RR, i.e. one where *both*
the DS and DNSKEY algorithms are supported.  I believe that's the
exact condition to be able to extend the trust chain. (and that's
how I implemented it for Knot Resolver)  It may theoretically even
happen that there is a supported DS algorithm and a supported DNSKEY
algorithm but never paired together in the DS RRset - IIRC it's not
perfectly correct to generate such an RRset but that's probably not
something a validator should care for.

  + Response: Error 1 (unsupported DNSKEY alg) could be included in any
message where the DNSKEY algorithm (say 1 RSA/MD5) isn't
supported. A servfail would be returned with EDE-1 as well.

For DS unsupported, a similar case occurs when chaining from the
parent and a DS Digest Type of 1 (MD5) is hit that the validator
doesn't support.  I *think* the problem is that the text should
really say "Unsupported DS Digest Type", which I'll go change it to.
Let me know if that's wrong.


14.1.7 DONE Section 3.6, code 6 (indeterminate answer) needs clarification,
---

  since there is no single defintion of "indeterminate" in DNSSEC.  In
  particular different definitions are given in RFCs 4034 and 4035 (as
  explained in [https://tools.ietf.org/html/rfc7672#section-2.1.1]).

  My take is that with the root zone signed, the 4033 definition is
  obsolete, and the correct one is 4035.  This should probably be made
  explicit:

  4035 "indetermi

Re: [DNSOP] Unsupported algorithm or unknown algorithm in draft-ietf-dnsop-extended-error

[Wes Hardaker]

Mats Dufberg  writes:

> Error codes 1 and 2, respectively, says "unsupported algorithm" in the
> headline but "unknown algorithm" in the description. It should be
> consistent, and I think unsupported makes most sense.

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.7 DONE Mats Dufberg
~~

  Error codes 1 and 2, respectively, says "unsupported algorithm" in the
  headline but "unknown algorithm" in the description. It should be
  consistent, and I think unsupported makes most sense.

  + Response: Good catch!  fixed.

-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

"Michael J. Sheldon"  writes:

Thanks Michael,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.4 DONE Michael J. Sheldon" 


14.4.1 DONE In section 3.21
---

  3.21.  Extended DNS Error Code 20 - Lame

  An authoritative server that receives a query (with the RD bit clear)
  for a domain for which it is not authoritative SHOULD include this EDE
  code in the SERVFAIL response.  A resolver that receives a query (with
  the RD bit clear) SHOULD include this EDE code in the REFUSED
  response.

  The above case is not consistent with current authoritative server
  behavior.

  The authoritative servers I have tested all return REFUSED, not
  SERVFAIL, regardless of the query RD bit, when the server does not
  allow recursion, and the server is not authoritative for the zone.

  I would change to:


  3.21.  Extended DNS Error Code 20 - Not Authoritative

  An authoritative server that receives a query (with the RD bit clear,
  or when not configured for recursion) for a domain for which it is not
  authoritative SHOULD include this EDE code in the REFUSED response.  A
  resolver that receives a query (with the RD bit clear) SHOULD include
  this EDE code in the REFUSED response.



  IMO, while "lame" is a valid term, quite frankly, it's not nearly as
  clear in meaning as just saying "not authoritative". To me, "lame" is
  at the delegation (referring server), not the targeted server.

  + Response: good catch and I like (and have put in) you replacements.
I've never liked the "lame" name either, as I don't think it's
descriptive to someone that isn't in the inner circle of DNS.

-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop