Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
Thanks Brian for your comments.
Currently the draft only allows zoneversion extension for records in
the ANSWER section of the response. But you're right that even there
we could have records from different zones.
For the sake of simplicity I'd prefer to clarify the text and declaring
such case as undefined, and it MUST NOT include a zoneversion if there's
no a single unequivocal zone.
Or at most, declare that it always referes to the first record of the
section.
Besides that, why are you including an "uncompressed domain name
of the zone" in your proposal? Is it not enough with the label count
and compression pointer to domain name of zone?
Regards,
Hugo
On 17:09 04/05, Brian Dickson wrote:
> Top-reply (to avoid adding to confusion by attempting to add in-line
> commentary of uncertain value):
> I also agree that this is very valuable and definitely helpful for
> diagnostics.
>
> I think there are a number of edge cases, for which disambiguation might be
> helpful.
> Apologies if this seems to add complexity, rather than the desired clarity
> on responses.
>
> The general edge case would be where a response includes multiple RRsets,
> which could be from different zones on the same server.
> Currently that would potentially occur if the response had CNAME, HTTPS, or
> SVCB records in addition to the RRTYPE matching/corresponding to the QTYPE.
>
> E.g. query: QNAME = foo.example.net, QTYPE = A;
>
> response contains
> foo.example.net CNAME bar.example.com
>
> bar.example.com A {example IP address}
>
> # server is authoritative for example.com and example.net, serves both zones
> # ZONEVERSION for both zones is valuable for diagnostic purposes
>
>
>
> Similarly, the Additional section could have records from multiple zones
> (served by the same server), possibly (I think, maybe more likely
> with HTTPS or SVCB responses).
>
> The disambiguation I'm about to suggest would uniquely identify an RRSet in
> the response by the location in the response message of the first record.
>
> With the proposed (below) disambiguation, it would then be possible to
> include multiple ZONEVERSIONs.
>
> The simplest way would be one ZONEVERSION per RRset.
> (There are other ways of having a single ZONEVERSION reference multiple
> RRsets, but I think that would be needlessly complex at that point.)
>
> If there are multiple RRsets from multiple zones, it would be necessary to
> specify the zone that corresponds to the ZONEVERSION for each RRset.
>
> Everything beyond this probably falls into the "bike shed" category.
> (Which method to implement any element is much less important than the
> existence of some method.)
> E.g.
>
>- Identify the first RR of an RRset:
> - 2-bit section (0,1,2,3 for query, answer, auth, add) plus RR
> ordinal (e.g. 1st RR in the section)
> - compression pointer
> - something else ???
>- Identify the zone that the ZONEVERSION applies to (i.e. the RRset):
> - label count
> - compression pointer to domain name of zone
> - uncompressed domain name of zone (no pointers)
>- (plus the actual zoneversion, and any flag(s))
>
> I think even in the single RR response this addresses Joe's issues, and
> allows the recipient to distinguish parent/child side of zone cuts (for NS
> records).
>
> Brian
>
>
> On Thu, May 4, 2023 at 1:58 PM Hugo Salgado wrote:
>
> > Hi Joe, thanks for your comments. Answers inline:
> >
> > On 14:16 27/04, Joe Abley wrote:
> > > On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On
> > Wed, Apr 26, 2023 at 23:07, Suzanne Woolf < wrote:
> > >
> > > > This email begins a Working Group Last Call for
> > draft-ietf-dnsop-zoneversion-02 (
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/).
> > > >
> > > > If you've reviewed this document and think it's ready for publication,
> > please let us and the WG know, by responding on-list to this message. We
> > particularly need to hear from implementers and operators whether this EDNS
> > option is implementable and useful.
> > > >
> > > > If you don't think it's ready, and have specific concerns or
> > suggestions, please let us know about those too.
> > > >
> > > > The Last Call will be two weeks, ending on Thursday 11 May.
> > >
> > > As I think I have said before, I like this idea and I think it is
> > genuinely useful. The draft is well-written and mainly clear but I have
> > some observations. I think some additional work would be beneficial before
> > we raise the draft up the IESG flagpole.
> > >
> > > In section 1 I see "Resolver and forwarder behaviour is undefined".
> > However, in section 3.2 the specification says that if various conditions
> > (including "server that is authoritative for the zone") are not met, the
> > answer "MUST NOT add an EDNS ZONEVERSION option to the response". This
> > seems inconsistent; 3.2 in fact does in fact seem to define the required
> > behaviour for at least some resolvers and
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
Top-reply (to avoid adding to confusion by attempting to add in-line
commentary of uncertain value):
I also agree that this is very valuable and definitely helpful for
diagnostics.
I think there are a number of edge cases, for which disambiguation might be
helpful.
Apologies if this seems to add complexity, rather than the desired clarity
on responses.
The general edge case would be where a response includes multiple RRsets,
which could be from different zones on the same server.
Currently that would potentially occur if the response had CNAME, HTTPS, or
SVCB records in addition to the RRTYPE matching/corresponding to the QTYPE.
E.g. query: QNAME = foo.example.net, QTYPE = A;
response contains
foo.example.net CNAME bar.example.com
bar.example.com A {example IP address}
# server is authoritative for example.com and example.net, serves both zones
# ZONEVERSION for both zones is valuable for diagnostic purposes
Similarly, the Additional section could have records from multiple zones
(served by the same server), possibly (I think, maybe more likely
with HTTPS or SVCB responses).
The disambiguation I'm about to suggest would uniquely identify an RRSet in
the response by the location in the response message of the first record.
With the proposed (below) disambiguation, it would then be possible to
include multiple ZONEVERSIONs.
The simplest way would be one ZONEVERSION per RRset.
(There are other ways of having a single ZONEVERSION reference multiple
RRsets, but I think that would be needlessly complex at that point.)
If there are multiple RRsets from multiple zones, it would be necessary to
specify the zone that corresponds to the ZONEVERSION for each RRset.
Everything beyond this probably falls into the "bike shed" category.
(Which method to implement any element is much less important than the
existence of some method.)
E.g.
- Identify the first RR of an RRset:
- 2-bit section (0,1,2,3 for query, answer, auth, add) plus RR
ordinal (e.g. 1st RR in the section)
- compression pointer
- something else ???
- Identify the zone that the ZONEVERSION applies to (i.e. the RRset):
- label count
- compression pointer to domain name of zone
- uncompressed domain name of zone (no pointers)
- (plus the actual zoneversion, and any flag(s))
I think even in the single RR response this addresses Joe's issues, and
allows the recipient to distinguish parent/child side of zone cuts (for NS
records).
Brian
On Thu, May 4, 2023 at 1:58 PM Hugo Salgado wrote:
> Hi Joe, thanks for your comments. Answers inline:
>
> On 14:16 27/04, Joe Abley wrote:
> > On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On
> Wed, Apr 26, 2023 at 23:07, Suzanne Woolf < wrote:
> >
> > > This email begins a Working Group Last Call for
> draft-ietf-dnsop-zoneversion-02 (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/).
> > >
> > > If you've reviewed this document and think it's ready for publication,
> please let us and the WG know, by responding on-list to this message. We
> particularly need to hear from implementers and operators whether this EDNS
> option is implementable and useful.
> > >
> > > If you don't think it's ready, and have specific concerns or
> suggestions, please let us know about those too.
> > >
> > > The Last Call will be two weeks, ending on Thursday 11 May.
> >
> > As I think I have said before, I like this idea and I think it is
> genuinely useful. The draft is well-written and mainly clear but I have
> some observations. I think some additional work would be beneficial before
> we raise the draft up the IESG flagpole.
> >
> > In section 1 I see "Resolver and forwarder behaviour is undefined".
> However, in section 3.2 the specification says that if various conditions
> (including "server that is authoritative for the zone") are not met, the
> answer "MUST NOT add an EDNS ZONEVERSION option to the response". This
> seems inconsistent; 3.2 in fact does in fact seem to define the required
> behaviour for at least some resolvers and forwarders (those that are not
> also authoritative servers).
> >
>
> You're right. That undefined behaviour for "not authoritatives" seems
> to be a source of concern. Maybe we can just drop that introductory
> phrase, wich otherwise talks about the transitive nature of EDNS
> options.
>
>
> > The draft refers to "the zone" in various places, as in one of the
> sentences quoted above. I think it's fairly obvious what this means, but I
> don't think it would hurt to be a little more specific about it. After all,
> if the whole point is to identify something specific about a zone, wouldn't
> it be good to be clear about which zone we are talking about? Should the
> option included in responses include the identity of the zone explicitly?
> >
>
> In the document, the first time we mention zone is "... with a
> token field representing the version of the zone which contains the
> answered Resource
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
Hi Joe, thanks for your comments. Answers inline: On 14:16 27/04, Joe Abley wrote: > On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On Wed, > Apr 26, 2023 at 23:07, Suzanne Woolf < wrote: > > > This email begins a Working Group Last Call for > > draft-ietf-dnsop-zoneversion-02 > > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > > > > If you've reviewed this document and think it's ready for publication, > > please let us and the WG know, by responding on-list to this message. We > > particularly need to hear from implementers and operators whether this EDNS > > option is implementable and useful. > > > > If you don't think it's ready, and have specific concerns or suggestions, > > please let us know about those too. > > > > The Last Call will be two weeks, ending on Thursday 11 May. > > As I think I have said before, I like this idea and I think it is genuinely > useful. The draft is well-written and mainly clear but I have some > observations. I think some additional work would be beneficial before we > raise the draft up the IESG flagpole. > > In section 1 I see "Resolver and forwarder behaviour is undefined". However, > in section 3.2 the specification says that if various conditions (including > "server that is authoritative for the zone") are not met, the answer "MUST > NOT add an EDNS ZONEVERSION option to the response". This seems inconsistent; > 3.2 in fact does in fact seem to define the required behaviour for at least > some resolvers and forwarders (those that are not also authoritative servers). > You're right. That undefined behaviour for "not authoritatives" seems to be a source of concern. Maybe we can just drop that introductory phrase, wich otherwise talks about the transitive nature of EDNS options. > The draft refers to "the zone" in various places, as in one of the sentences > quoted above. I think it's fairly obvious what this means, but I don't think > it would hurt to be a little more specific about it. After all, if the whole > point is to identify something specific about a zone, wouldn't it be good to > be clear about which zone we are talking about? Should the option included in > responses include the identity of the zone explicitly? > In the document, the first time we mention zone is "... with a token field representing the version of the zone which contains the answered Resource Record,...". So that's the meaning. If you think is better to repeat that clarification later, please tell me where and we'll add it! > For example, suppose I am doing a recursive lookup on an empty cache. I send > a query to a root server with the EDNS ZONEVERSION option and get a referral > response. Is it reasonable for that response to include a version token for > the root zone in its response? > Yes, we expect to have a zoneversion response at this point. The only thing that we might want to clarify is the zoneversion comes from the authoritative part of the Name Server doing the referral; in this particular case, from the root zone. In section 3.2. it's mentioned: If an EDNS ZONEVERSION option is sent to a server that is Authoritative for the zone, then a name server that understands the ZONEVERSION option [...] By using the definition of referrals [RFC8499] and the subtleties of the parent authority above the zone cut, maybe we could add a clarification in this point? Maybe something like: "In case of a downward referral response, even when the Authoritative Answer bit is not set, this specification considers that the Answer holds data that is authoritative for some portion of the QNAME (See "referrals" in RFC8499, Section 4). Given this, a ZONEVERSION option MUST be present as indicated in the paragraph above, with the zone versioning value that holds that portion of the QNAME where it is completely authoritative." > Is it sufficiently obvious to the receiver of such a response which zone's > version is being returned? > I hope so ;) A human operator could infer that information, based on the AUTHORITY section that is included in the same referral. And if the NS acts as authoritative in both sides, the AA flag in the answer below the cut can serve as differentiator of which serial we're receiving. But once again, if the group consider it necessary, we could adapt the extension to explicitly add the portion of the QNAME to which the version corresponds to the authoritative portion. If that's the case, and to avoid handling variable fields for such label, we could use something similar to RRSIG's "labels field" [RFC4034 section 3.1.3] in which we add a single byte indicating the number of labels in the QNAME. Does that sound like an overkill? Comments are welcome. > The draft contains phrases like "QNAME belongs to an authoritative zone of > the server" which I also feel has the potential to be misunderstood. > > The idea of omitting the option in a response which also includes
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
Yes, that's pretty succinct and clear. G On Sat, 29 Apr 2023, 04:26 Hugo Salgado, wrote: > Thanks a lot George for your comments. > About this suggestion: > > On 14:29 27/04, George Michaelson wrote: > > It's a debug tool. It isn't going to be something I expect to use, but > > I like the idea if something goes awry in the responses I am seeing I > > can ask the authority to tell me what SOA serial I should expect to > > see, that has the response state they're giving me for the specific > > query. Thats distinct from ZONEMD which is a DNSSEC signed state of an > > entire zone (assuming it can be done) which is a different class of > > check on zone state related to serial. I like both. They're different. > > That said, you COULD point to ZONEMD in this one in the security > > considerations, but I wouldnt make it normative. It's just another way > > to check the state of a zone. > > > > You're right that we can better state the differences with ZONEMD. > What do you think of adding a paragraph like this in the security > considerations? > >"Please note that ZONEVERSION option can not be used for checking >the correctness of an entire zone in a server. For such cases, the >ZONEMD record [RFC8976] might be better suited at such task. >ZONEVERSION can help identify and correlate a certain specific >answer with a version of a zone, but it has no special integrity or >verification function besides a normal field value inside a zone, as >stated above." > > Thanks, > > Hugo > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
Thanks a lot George for your comments. About this suggestion: On 14:29 27/04, George Michaelson wrote: > It's a debug tool. It isn't going to be something I expect to use, but > I like the idea if something goes awry in the responses I am seeing I > can ask the authority to tell me what SOA serial I should expect to > see, that has the response state they're giving me for the specific > query. Thats distinct from ZONEMD which is a DNSSEC signed state of an > entire zone (assuming it can be done) which is a different class of > check on zone state related to serial. I like both. They're different. > That said, you COULD point to ZONEMD in this one in the security > considerations, but I wouldnt make it normative. It's just another way > to check the state of a zone. > You're right that we can better state the differences with ZONEMD. What do you think of adding a paragraph like this in the security considerations? "Please note that ZONEVERSION option can not be used for checking the correctness of an entire zone in a server. For such cases, the ZONEMD record [RFC8976] might be better suited at such task. ZONEVERSION can help identify and correlate a certain specific answer with a version of a zone, but it has no special integrity or verification function besides a normal field value inside a zone, as stated above." Thanks, Hugo signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
(speaking as a chair) On Thu, Apr 27, 2023 at 5:22 PM John R Levine wrote: > On Thu, 27 Apr 2023, Miek Gieben wrote: > >> I think it's an interesting idea but I also don't want to spend time on > it > >> if it's just going to be filed and forgotten. > > > > I looked into this for https://github.com/miekg/dns > > > > The option is trivial to implemented (in an auth server). I.e. seems > similar > > to NSID. > > I agree that it's not hard to do. But the Camel reminds us that there is > an unlimited number of hacks that would be easy to implement, but not > necessarily that anyone would use. Hence my question about whether > anyone's implemented it. > ' John While you are correct on remembering the camel, the "OP" part of DNSOP stands for "Operations" (DNSOP for the Operators!), I try to judge new work with a another question "does this make it easier for operators to deploy and benefit from?" (now speaking as myself) In this case I do feel this would be useful and will be used by operators. And more so than ZoneMD, because as George point, it's a different class of checks. tim > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
On Thu, 27 Apr 2023, Miek Gieben wrote: I think it's an interesting idea but I also don't want to spend time on it if it's just going to be filed and forgotten. I looked into this for https://github.com/miekg/dns The option is trivial to implemented (in an auth server). I.e. seems similar to NSID. I agree that it's not hard to do. But the Camel reminds us that there is an unlimited number of hacks that would be easy to implement, but not necessarily that anyone would use. Hence my question about whether anyone's implemented it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
[ Quoting in "Re: [DNSOP] WGLC for draft-ietf-dns..." ] It appears that Suzanne Woolf said: Colleagues, This email begins a Working Group Last Call for draft-ietf-dnsop-zoneversion-02 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). If you've reviewed this document and think it's ready for publication, please let us and the WG know, by responding on-list to this message. We particularly need to hear from implementers and operators whether this EDNS option is implementable and useful. If you don't think it's ready, and have specific concerns or suggestions, please let us know about those too. Since it's a year old, has anyone implemented it beyond the one server listed in the draft? I think it's an interesting idea but I also don't want to spend time on it if it's just going to be filed and forgotten. I looked into this for https://github.com/miekg/dns The option is trivial to implemented (in an auth server). I.e. seems similar to NSID. "Resolver and forwarder behavior is undefined" is too weak IMO, and should point to the hop-by-hop nature for EDNS0 options, are explicitly say what's expected here wrt to this option. /Miek -- Miek Gieben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
It appears that Suzanne Woolf said: >Colleagues, > > >This email begins a Working Group Last Call for >draft-ietf-dnsop-zoneversion-02 >(https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > >If you've reviewed this document and think it's ready for publication, please >let us and the WG know, by responding on-list to this message. We particularly >need to hear >from implementers and operators whether this EDNS option is implementable and >useful. > >If you don't think it's ready, and have specific concerns or suggestions, >please let us know about those too. Since it's a year old, has anyone implemented it beyond the one server listed in the draft? I think it's an interesting idea but I also don't want to spend time on it if it's just going to be filed and forgotten. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf < wrote: > This email begins a Working Group Last Call for > draft-ietf-dnsop-zoneversion-02 > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > > If you've reviewed this document and think it's ready for publication, please > let us and the WG know, by responding on-list to this message. We > particularly need to hear from implementers and operators whether this EDNS > option is implementable and useful. > > If you don't think it's ready, and have specific concerns or suggestions, > please let us know about those too. > > The Last Call will be two weeks, ending on Thursday 11 May. As I think I have said before, I like this idea and I think it is genuinely useful. The draft is well-written and mainly clear but I have some observations. I think some additional work would be beneficial before we raise the draft up the IESG flagpole. In section 1 I see "Resolver and forwarder behaviour is undefined". However, in section 3.2 the specification says that if various conditions (including "server that is authoritative for the zone") are not met, the answer "MUST NOT add an EDNS ZONEVERSION option to the response". This seems inconsistent; 3.2 in fact does in fact seem to define the required behaviour for at least some resolvers and forwarders (those that are not also authoritative servers). The draft refers to "the zone" in various places, as in one of the sentences quoted above. I think it's fairly obvious what this means, but I don't think it would hurt to be a little more specific about it. After all, if the whole point is to identify something specific about a zone, wouldn't it be good to be clear about which zone we are talking about? Should the option included in responses include the identity of the zone explicitly? For example, suppose I am doing a recursive lookup on an empty cache. I send a query to a root server with the EDNS ZONEVERSION option and get a referral response. Is it reasonable for that response to include a version token for the root zone in its response? Is it sufficiently obvious to the receiver of such a response which zone's version is being returned? The draft contains phrases like "QNAME belongs to an authoritative zone of the server" which I also feel has the potential to be misunderstood. The idea of omitting the option in a response which also includes the SOA serial seems problematic. I feel like this could mask various kinds of implementation problems, and an explicit signal might be better. For example, what about the case where the SOA serial does not represent the zone version, and the response is omitted by error, e.g. because a member of an anycast cluster is badly configured? That should be interpreted by the receiver as a missing response option, not as a new version number that can safely be processed and compared with others. How would the receiver of the response know to do this? I fully confess I haven't thought about this in detail, but I think there are some lurking dragons here. Happy to suggest text around these various points if there is some kind of consensus that these are things that would merit from attention. Again, great idea though. I do like it and would definitely use it if it existed. Joe >___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
I've read this draft. I think its a simple and straightforward proposal. It explicitly notes the security issue that its not covered by DNSSEC, it has implementations, and it had a good discussion run 2021/2022 which was overwhelmingly positive. I had no problems understanding the intent. its really clear and straightforward. It's a debug tool. It isn't going to be something I expect to use, but I like the idea if something goes awry in the responses I am seeing I can ask the authority to tell me what SOA serial I should expect to see, that has the response state they're giving me for the specific query. Thats distinct from ZONEMD which is a DNSSEC signed state of an entire zone (assuming it can be done) which is a different class of check on zone state related to serial. I like both. They're different. That said, you COULD point to ZONEMD in this one in the security considerations, but I wouldnt make it normative. It's just another way to check the state of a zone. The non-transitive thing is about the only point of "well" -but its unsigned data: how could you trust it, if you can't verify through a third (transiting) party? And the draft says this: it's undefined behaviour. I truly think this is that very rare bird: "looks good to me ship it" in 2 WG adopted draft edits. On Thu, Apr 27, 2023 at 1:08 PM Suzanne Woolf wrote: > > Colleagues, > > > This email begins a Working Group Last Call for > draft-ietf-dnsop-zoneversion-02 > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > > If you've reviewed this document and think it's ready for publication, please > let us and the WG know, by responding on-list to this message. We > particularly need to hear from implementers and operators whether this EDNS > option is implementable and useful. > > If you don't think it's ready, and have specific concerns or suggestions, > please let us know about those too. > > The Last Call will be two weeks, ending on Thursday 11 May. > > Thanks to everyone who's offered comments and suggestions on the draft to > date. > > > Suzanne, Tim, and Benno > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] WGLC for draft-ietf-dnsop-zoneversion
Colleagues, This email begins a Working Group Last Call for draft-ietf-dnsop-zoneversion-02 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). If you've reviewed this document and think it's ready for publication, please let us and the WG know, by responding on-list to this message. We particularly need to hear from implementers and operators whether this EDNS option is implementable and useful. If you don't think it's ready, and have specific concerns or suggestions, please let us know about those too. The Last Call will be two weeks, ending on Thursday 11 May. Thanks to everyone who's offered comments and suggestions on the draft to date. Suzanne, Tim, and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
