Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On Mon, 2021-05-10 at 22:09 +0100, Tony Finch wrote: > Peter van Dijk wrote: > > Also in section 3.2, I do not think responding with the option should > > be limited to NOERROR. Specifically, I'd very much also want it to work > > for NXDOMAIN, > > Isn't the SOA record usually present in a negati

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Peter van Dijk wrote: > > Also in section 3.2, I do not think responding with the option should > be limited to NOERROR. Specifically, I'd very much also want it to work > for NXDOMAIN, Isn't the SOA record usually present in a negative response? > and I can imagine some cases of it being useful

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On Mon, 2021-05-10 at 12:37 -0400, Hugo Salgado wrote: > Hello everyone. Thanks for the comments, I just uploaded an unchanged > version (just to revive it) at: > https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/ Thanks Hugo, that is useful. In section 3.2, 'the resource record of

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I agree with what Hugo said I would also like to point out that this draft spirit is aiming to be a debugging tool to be used by humans and not in between servers. If we start introducing all these new use cases in-between servers (like authoritativ

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hi Vladimir, On 10 May 2021, at 04:32, Vladimír Čunát wrote: > On 10. 05. 21 10:19, Petr Špaček wrote: >> I think the proper solution should be a real multi-query option, which >> incidentally provides a superset of RRSERIAL capabilities. > > If multi-queries require the records being in sync

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hello everyone. Thanks for the comments, I just uploaded an unchanged version (just to revive it) at: https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/ I agree RRSERIAL doesn't have much relevance in zones that don't give serial versioning a meaning to its content. We can add a para

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On 10. 05. 21 10:19, Petr Špaček wrote: I think the proper solution should be a real multi-query option, which incidentally provides a superset of RRSERIAL capabilities. If multi-queries require the records being in sync (if from the same zone), I really dislike the implications of them being

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On 27. 01. 20 16:08, Hugo Salgado wrote: Dear DNSOPers, as an operator I tend to have this need to couple an answer for a query to an auth server, with the actual "SOA zone version" used. So I think it'll be valuable to have an EDNS option for it. Here I'm proposing it with this new draft. The '

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On Mon, 27 Jan 2020 at 10:09, Hugo Salgado wrote: > > Dear DNSOPers, as an operator I tend to have this need to couple > an answer for a query to an auth server, with the actual "SOA zone > version" used. So I think it'll be valuable to have an EDNS option > for it. I also missed this the first t

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Seems like a good idea to me. I think the WG should adopt it. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Mon, Jan 27, 2020 at 10:09 AM Hugo Salgado wrote: > > Dear DNSOPers, as

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On Fri, May 7, 2021 at 10:03 AM Joe Abley wrote: > Hi Hugo, > > On 7 May 2021, at 12:47, Hugo Salgado wrote: > > > I'll upload a new version to revive it, and ask for a slot > > in IETF111 for further discussion! > > Just to add my voice to the chorus, I missed this the first time around so > th

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On 7 May 2021, at 13:39, John Levine wrote: > It appears that Hugo Salgado said: >> -=-=-=-=-=- >> >> I'll upload a new version to revive it, and ask for a slot >> in IETF111 for further discussion! > > It looks like it's worth considering, but I also wonder how > relevant it is for DNS serve

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On Fri, May 07, 2021 at 01:39:56PM -0400, John Levine wrote: > It appears that Hugo Salgado said: > >-=-=-=-=-=- > > > >I'll upload a new version to revive it, and ask for a slot > >in IETF111 for further discussion! > > It looks like it's worth considering, but I also wonder how > relevant it i

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

It appears that Hugo Salgado said: >-=-=-=-=-=- > >I'll upload a new version to revive it, and ask for a slot >in IETF111 for further discussion! It looks like it's worth considering, but I also wonder how relevant it is for DNS servers that don't use AXFR/IXFR and SOA serial numbers to keep ver

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hi Hugo, On 7 May 2021, at 12:47, Hugo Salgado wrote: > I'll upload a new version to revive it, and ask for a slot > in IETF111 for further discussion! Just to add my voice to the chorus, I missed this the first time around so thanks, Mauricio, for mentioning it. I haven't read the draft in d

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

I'll upload a new version to revive it, and ask for a slot in IETF111 for further discussion! Thanks, Hugo On 22:02 06/05, Mauricio Vergara Ereche wrote: > Hi Hugo, > > I just want to bring back to life this topic as it solves an issue that > several operators (like me) seem to be in need to so

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hi Hugo, I just want to bring back to life this topic as it solves an issue that several operators (like me) seem to be in need to solve while debugging issues. Mauricio On Mon, Jan 27, 2020 at 7:09 AM Hugo Salgado wrote: > Dear DNSOPers, as an operator I tend to have this need to couple > an

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hi Duane. On 20:49 27/01, Wessels, Duane wrote: > Hi Hugo, > > I like this proposal and think that DNSOP should adopt it. I agree that it > will prove valuable in debugging. > Great. > A couple of comments and suggestions: > > Sections 2 and 3 could be clarified regarding the value for OPTI

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hi Hugo, I like this proposal and think that DNSOP should adopt it. I agree that it will prove valuable in debugging. A couple of comments and suggestions: Sections 2 and 3 could be clarified regarding the value for OPTION-LENGTH. I gather the intention is that OPTION-LENGTH is zero for quer

[DNSOP] Adoption of new EDNS opcode "rrserial"

Dear DNSOPers, as an operator I tend to have this need to couple an answer for a query to an auth server, with the actual "SOA zone version" used. So I think it'll be valuable to have an EDNS option for it. Here I'm proposing it with this new draft. The 'camel index' for its implementation/hack/pr

Re: [DNSOP] Adoption of as a WG work item?

Joe Abley wrote: > > Once we have confidence that the AS112.ARPA zone is being hosted > adequately, we could re-provision 10.IN-ADDR.ARPA, 168.192.IN-ADDR.ARPA > and 16.172.IN-ADDR.ARPA and friends with DNAME and the old AS112 system > can be retired. What will be the consequences of this for val

Re: [DNSOP] Adoption of as a WG work item?

On 03/15/2013 03:34 PM, Steve Crocker wrote: > > On Mar 15, 2013, at 11:21 AM, Hugo Salgado wrote: > >> >> On 03/14/2013 07:44 PM, Joe Abley wrote: >>> (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, >>> we could sign it and install a DS RRSet in the ARPA zone. This w

Re: [DNSOP] Adoption of as a WG work item?

On 2013-03-15, at 14:34, Steve Crocker wrote: > It feels like there are two distinct issues here. If the signatures expire, > all copies of those records will be affected, so diversity of name servers > won't help. My assumption was that this was a reference to the "signatures expired becaus

Re: [DNSOP] Adoption of as a WG work item?

On Mar 15, 2013, at 11:21 AM, Hugo Salgado wrote: > > On 03/14/2013 07:44 PM, Joe Abley wrote: >> (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we >> could sign it and install a DS RRSet in the ARPA zone. This would have the >> side benefit that we could track from

Re: [DNSOP] Adoption of as a WG work item?

On 03/14/2013 07:44 PM, Joe Abley wrote: > (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we > could sign it and install a DS RRSet in the ARPA zone. This would have the > side benefit that we could track from ICANN's distribution masters who is > retrieving the zone,

Re: [DNSOP] Adoption of as a WG work item?

On Mar 14, 2013, at 6:55 PM, Joe Abley wrote: > > On 2013-03-14, at 18:52, George Michaelson wrote: > >> how many of the deployed resolvers can understand DNAME > > Good question, it would interesting to design an experiment to measure that. > >> and whats the outcome for dns lookups where

Re: [DNSOP] Adoption of as a WG work item?

I've got no objections to experimenting with DNAME like this. DNAME and NXDOMAIN are QTYPE agnostic whereas NOERROR/NODATA is not. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _

Re: [DNSOP] Adoption of as a WG work item?

FWIW, this was first broached on the AS112 operators ML. Thread here: https://lists.dns-oarc.net/pipermail/as112-ops/2011-July/000209.html Hope this contributes to the discussion. On Thu, 14 Mar 2013, Joe Abley wrote: On 2013-02-22, at 15:14, "Dickson, Brian" wrote: Instead of delegatin

Re: [DNSOP] Adoption of as a WG work item?

On 2013-03-14, at 18:52, George Michaelson wrote: > how many of the deployed resolvers can understand DNAME Good question, it would interesting to design an experiment to measure that. > and whats the outcome for dns lookups where the intermediate systems dont > understand DNAME. CNAME synth

Re: [DNSOP] Adoption of as a WG work item?

On 2013-02-22, at 15:14, "Dickson, Brian" wrote: > Instead of delegating to omniscient AS112 servers, what about doing a > DNAME to a specific target "foo" (replace "foo" with what you will) in the > DNS tree? I've thought about this a bit, and I've decided that I quite like it. So, if I can p

Re: [DNSOP] Adoption of as a WG work item?

On Feb 22, 2013, at 8:52 PM, P Vixie wrote: > Sorry to be late on this, missed it earlier. > > Nxd says there is no such name, no matter what the type was, and there are no > children. RCODE=3 states that the name does not exist. "no children" might be implied from that, but that is just it,

Re: [DNSOP] Adoption of as a WG work item?

On Feb 26 2013, Tony Finch wrote: [...] I just remembered another problem, that many unices have antediluvian stub resolvers that write to syslog when they see a DNAME record, e.g. gethostby*.getanswer: asked for "42.143.232.128.in-addr.arpa IN PTR", got type "39" Apart from logging, the code

Re: [DNSOP] Adoption of as a WG work item?

On Feb 26 2013, Tony Finch wrote: Dickson, Brian wrote: [...] Instead of delegating to omniscient AS112 servers, what about doing a DNAME to a specific target "foo" (replace "foo" with what you will) in the DNS tree? Like this? We have had (afaik) one interop problem with this setup: there

Re: [DNSOP] Adoption of as a WG work item?

Dickson, Brian wrote: > > While mail servers doing PTR look-up having problems is a potential > concern, keep in mind that AS112 is meant to be used for "local"-ish > zones, like 10.in-addr.arpa. Right. I probably should have said more clearly that it works pretty well if that is the worst intero

Re: [DNSOP] Adoption of as a WG work item?

On 2/25/13 7:29 PM, "Tony Finch" wrote: >Dickson, Brian wrote: >> >> However, there is another UGLY, EVIL way that might achieve what you're >> thinking of: >> >> Instead of delegating to omniscient AS112 servers, what about doing a >> DNAME to a specific target "foo" (replace "foo" with what yo

Re: [DNSOP] Adoption of as a WG work item?

Hi Peter, Stephen, At 14:48 25-02-2013, Warren Kumari wrote: Yup -- the call for adoption on Saturday the 9th, and ended on Monday the 18th, which was a public holiday / long weekend in the USA. This means that US folk only had 4 or 5 working days to read and comment. If it had been run for th

Re: [DNSOP] Adoption of as a WG work item?

... Paul Vixie wrote: > ... > > Tony Finch wrote: >> ... >> Why not something like Paul's metazone idea to automate the configuration >> of which zones the server should answer for? > for reference: > http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html > that message's pdf attachment

Re: [DNSOP] Adoption of as a WG work item?

... Tony Finch wrote: > ... > Why not something like Paul's metazone idea to automate the configuration > of which zones the server should answer for? for reference: http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html paul ___ DNSOP mailin

Re: [DNSOP] Adoption of as a WG work item?

Joe Abley wrote: > > I too have always preferred the idea of specifying configuration for > standard software over custom code (neat though the custom code Warren is > running is). We just couldn't figure out how to do it. Why not something like Paul's metazone idea to automate the configuration

Re: [DNSOP] Adoption of as a WG work item?

Dickson, Brian wrote: > > However, there is another UGLY, EVIL way that might achieve what you're > thinking of: > > Instead of delegating to omniscient AS112 servers, what about doing a > DNAME to a specific target "foo" (replace "foo" with what you will) in the > DNS tree? Like this? We have h

Re: [DNSOP] Adoption of as a WG work item?

On Feb 25, 2013, at 4:52 PM, SM wrote: > Hi Joe, > At 14:35 24-02-2013, Joe Abley wrote: >> The most recent decision that I saw from the chairs was that it should >> not be adopted. I do not agree that that is the best path forward. > > The draft might have crossed the review threshold after th

Re: [DNSOP] Adoption of as a WG work item?

Hi Joe, At 14:35 24-02-2013, Joe Abley wrote: The most recent decision that I saw from the chairs was that it should not be adopted. I do not agree that that is the best path forward. The draft might have crossed the review threshold after the deadline. Authors are usually given an opportunit

Re: [DNSOP] Adoption of as a WG work item?

On Feb 22, 2013, at 3:47 PM, P Vixie wrote: > Sounds like you want it to return the nxd with no 2308 proof which means most > receives will cache it because the erroneous delegation isn't present. Bind > calls this a minimal response I think. … Paul Hmmm… 'minimal-responses yes' doesn't seem

Re: [DNSOP] Adoption of as a WG work item?

On Feb 22, 2013, at 4:25 PM, P Vixie wrote: > I think your requirement is wrong, or misstated. > > You ought not want to imply there could be other types, except at the apex. > > The semantics of an empty riot zone in a disconnected name space suit you > perfectly. > > If I get ambitious an

Re: [DNSOP] Adoption of as a WG work item?

The most recent decision that I saw from the chairs was that it should not be adopted. I do not agree that that is the best path forward. Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-24, at 13:15, SM wrote: > At 11:27 22-02-2013, Warren Kumari wrote: >> If the WG consensus is NXDOMAIN,

Re: [DNSOP] Adoption of as a WG work item?

At 11:27 22-02-2013, Warren Kumari wrote: If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. The subject line says "Adoption as WG item". Has draft-wkumari-dnsop-omniscient-as112-01 been adopted yet? Regards

Re: [DNSOP] Adoption of as a WG work item?

I think your requirement is wrong, or misstated. You ought not want to imply there could be other types, except at the apex. The semantics of an empty riot zone in a disconnected name space suit you perfectly. If I get ambitious and revive resimprove then the no children exist signaling will

Re: [DNSOP] Adoption of as a WG work item?

We want the absence of (qname, qtype) to be cached by resolvers who follow a delegation to an omniscient as112 server for all (qname, qtype). Given that requirement the thought was that NOERROR/no data and NXDOMAIN were equally plausible. However, I see now that the lack of "no children" signallin

Re: [DNSOP] Adoption of as a WG work item?

Sounds like you want it to return the nxd with no 2308 proof which means most receives will cache it because the erroneous delegation isn't present. Bind calls this a minimal response I think. ... Paul Joe Abley wrote: >Hi Paul, > >That was our starting point; however, it turned out that res

Re: [DNSOP] Adoption of as a WG work item?

Sorry to be late on this, missed it earlier. Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to foll

Re: [DNSOP] Adoption of as a WG work item?

Hi Paul, That was our starting point; however, it turned out that resolvers wouldn't cache the name error, I think because the SOA returned with the name error in the authority section was clearly bogus (i.e. conflicted with the root zone SOA presumably already cached by the resolver client). I t

Re: [DNSOP] Adoption of as a WG work item?

I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname. Paul Warren Kumari wrote: > >On Feb 22, 2013, at 6:57 AM, Paul Vixie

Re: [DNSOP] Adoption of as a WG work item?

On 2/22/13 2:27 PM, "Warren Kumari" wrote: > >(If folk feel sufficiently strongly we *could* even strip a label off, so >that the synthesized SOA is not the same as the NXD. *This* feel really >hacks, but putting it out there...) Uh, definitely not. The whole point is you don't know from where

Re: [DNSOP] Adoption of as a WG work item?

On Feb 22, 2013, at 6:57 AM, Paul Vixie wrote: > if we can't return nxdomain, then i'm opposed to the omniscient spec, > and we should continue as before, enumerating on the responding servers > every zone to which we wish to delegate. > If the WG consensus is NXDOMAIN, we can do that. *We* fe

Re: [DNSOP] Adoption of as a WG work item?

On Feb 22, 2013, at 8:49 AM, Joe Abley wrote: > > On 2013-02-22, at 09:39, Mark Andrews wrote: > >> I can well imagine a machine doing a reverse lookup on a proposed >> address and not proceeding with that address if it doesn't get a >> NXDOMAIN. >> >> NODATA -> unsafe >> NXDOMAIN

Re: [DNSOP] Adoption of as a WG work item?

Good point, indirectly referencing RFC 2308 (I always seem to forget about that one). So, other than SOA TTL going into the draft, I think it's all good, and please ignore everything else I said (e.g. 900). Brian On 2/22/13 11:43 AM, "Joe Abley" wrote: > >On 2013-02-22, at 12:33, "Dickson, Bri

Re: [DNSOP] Adoption of as a WG work item?

On Feb 22 2013, Mark Andrews wrote: I can well imagine a machine doing a reverse lookup on a proposed address and not proceeding with that address if it doesn't get a NXDOMAIN. NODATA -> unsafe NXDOMAIN -> may be safe So when I do a reverse lookup of 255.255.255.255 or ::0, an

Re: [DNSOP] Adoption of as a WG work item?

On 2013-02-22, at 12:33, "Dickson, Brian" wrote: > One question/caveat: > > What would the practical impact be, if the TTL on the SOA were the same as > the default negative caching TTL (for the NXDOMAIN)? The longevity of the negative answer in the cache is defined as min(SOA TTL, SOA MINIMU

Re: [DNSOP] Adoption of as a WG work item?

One question/caveat: What would the practical impact be, if the TTL on the SOA were the same as the default negative caching TTL (for the NXDOMAIN)? I think it would be slightly less sniffy, to have the NXDOMAIN and the synthesized SOA both disappear at the same time. IIRC, the TTL would then ne

Re: [DNSOP] Adoption of as a WG work item?

On 2013-02-22, at 10:42, Nick Hilliard wrote: > I agree we should be cautious. So why not run it on some as112 servers on > a pilot basis and see what happens? Full logging would be required, as > well as some idea of what sort of problems to look for (e.g. multiple > repeated queries from the

Re: [DNSOP] Adoption of as a WG work item?

On 22/02/2013 13:39, Mark Andrews wrote: > The problem is that we don't know what changing the status quo will > do. We have to be very cautious about doing that. I agree we should be cautious. So why not run it on some as112 servers on a pilot basis and see what happens? Full logging would be

Re: [DNSOP] Adoption of as a WG work item?

On 2013-02-22, at 09:39, Mark Andrews wrote: > I can well imagine a machine doing a reverse lookup on a proposed > address and not proceeding with that address if it doesn't get a > NXDOMAIN. > > NODATA -> unsafe > NXDOMAIN -> may be safe So, out of interest, do you think it's legi

Re: [DNSOP] Adoption of as a WG work item?

In message <51274721.1030...@inex.ie>, Nick Hilliard writes: > On 22/02/2013 05:47, Mark Andrews wrote: > > For much the same reason that *.COM was bad. > > *.com was certainly evil, but I don't think it's necessarily fair to > compare the two, given the different usage scope of forward and rever

Re: [DNSOP] Adoption of as a WG work item?

On 2013-02-22, at 07:57, Paul Vixie wrote: > if we can't return nxdomain, then i'm opposed to the omniscient spec, > and we should continue as before, enumerating on the responding servers > every zone to which we wish to delegate. > > noerror/nodata is the wrong answer. It does smell a bit wr

Re: [DNSOP] Adoption of as a WG work item?

Subject: Re: [DNSOP] Adoption of as a WG work item? Date: Fri, Feb 22, 2013 at 03:57:45AM -0800 Quoting Paul Vixie (p...@redbarn.org): > if we can't return nxdomain, then i'm opposed to the omniscient spec, > and we should continue as before, enumerating on the responding serv

Re: [DNSOP] Adoption of as a WG work item?

if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. ___ DNSOP mailing list DNSOP@ietf.o

Re: [DNSOP] Adoption of as a WG work item?

On 2013-02-22, at 01:47, Mark Andrews wrote: > In message , George > Michaels > on writes: > >> On 21/02/2013, at 6:46 AM, Mark Andrews wrote: >> >>> * it changes the response from NXDOMAIN to NOERROR NODATA. >> >> And why is that "wrong" ? I dont understand what you see as the outcomes. >

Re: [DNSOP] Adoption of as a WG work item?

On 22/02/2013 05:47, Mark Andrews wrote: > For much the same reason that *.COM was bad. *.com was certainly evil, but I don't think it's necessarily fair to compare the two, given the different usage scope of forward and reverse domains. > You *will* break things that you are unaware of. can you

Re: [DNSOP] Adoption of as a WG work item?

In message , George Michaels on writes: > > On 21/02/2013, at 6:46 AM, Mark Andrews wrote: > > > > > While I think we should adopt the document I have grave concerns > > about it. > > > > * there is no demonstrated need for it. > > thats opinion, not fact Mark. 'demonstrated need' stems from

Re: [DNSOP] Adoption of as a WG work item?

On 21/02/2013, at 6:46 AM, Mark Andrews wrote: > > While I think we should adopt the document I have grave concerns > about it. > > * there is no demonstrated need for it. thats opinion, not fact Mark. 'demonstrated need' stems from other people's desires. you might as well come out and say

Re: [DNSOP] Adoption of as a WG work item?

While I think we should adopt the document I have grave concerns about it. * there is no demonstrated need for it. * it is likely to interact badly with validating resolvers especially when there are lots of labels in the qname below the delegation to these servers. * it changes the response

Re: [DNSOP] Adoption of as a WG work item?

[ Quoting in "Re: [DNSOP] Adoption of I know I'm late, but for what it's worth I'd support this. +1 I've skimmed the document and support it being a wg doc. I also volunteer as a reviewer. Kind regards, Miek Gieben signature.asc Descr

Re: [DNSOP] Adoption of as a WG work item?

I know I'm late, but for what it's worth I'd support this. I'm happy to help, if possible. Perhaps I can sync with Warren et alia in person in Orlando. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption of as a WG work item?

Dear WG, > Please respond by the end of next week, so that we could ask future > editors to submit a renamed -00 version by Monday, Feb 18. thanks to all who responded and especially to those three volunteer reviewers. However, we've not met the 5 reviewer threshold, so your chairs agreed the WG

Re: [DNSOP] Adoption of as a WG work item?

On 9 feb 2013, at 21:45, Peter Koch wrote: > the topic of AS112 has been addresses in the DNSOP WG resulting in > RFCs 6304 and 6305 and is also related to 'local zones' as described in > RFC 6303. > > The question of extending AS112 service to IPv6 (as in "transport") > as well as the maintain

Re: [DNSOP] Adoption of as a WG work item?

Sure, looks good. I'll review drafts. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption of as a WG work item?

On Fri, Feb 15, 2013 at 5:05 PM, Paul Ebersman wrote: > > nick> I like this and think it should be adopted as a WG doc. Am not > nick> going to volunteer for formal document review, but would be happy > nick> to run + provide feedback for this sort of code in a live > nick> environment. > > I als

Re: [DNSOP] Adoption of as a WG work item?

nick> I like this and think it should be adopted as a WG doc. Am not nick> going to volunteer for formal document review, but would be happy nick> to run + provide feedback for this sort of code in a live nick> environment. I also support this being adopted as a WG document.

Re: [DNSOP] Adoption of as a WG work item?

> The question of extending AS112 service to IPv6 (as in "transport") > as well as the maintainability of the list of zones served by AS112 > systems has been discussed before. We have a proposal in > > draft-wkumari-dnsop-omniscient-as112-01.txt > > to make the AS112 served zone set exten

Re: [DNSOP] Adoption of as a WG work item?

On Wed, Feb 13, 2013 at 12:34:09PM -0500, Warren Kumari wrote: > The last day for submission of a -00 is Feb18th, but the last day for > adoption was the 11th. > So, if this is adopted, the authors can resubmit with a new name, but it > approved till the cycle restarts? > > ? 2013-02-11 (

Re: [DNSOP] Adoption of as a WG work item?

On Feb 9, 2013, at 3:45 PM, Peter Koch wrote: > Dear WG, > > the topic of AS112 has been addresses in the DNSOP WG resulting in > RFCs 6304 and 6305 and is also related to 'local zones' as described in > RFC 6303. > > The question of extending AS112 service to IPv6 (as in "transport") > as wel

Re: [DNSOP] Adoption of as a WG work item?

I support adoption. I am volunteering for document review. -G On 10/02/2013, at 6:45 AM, Peter Koch wrote: > Dear WG, > > the topic of AS112 has been addresses in the DNSOP WG resulting in > RFCs 6304 and 6305 and is also related to 'local zones' as described in > RFC 6303. > > The question o

[DNSOP] Adoption of as a WG work item?

Dear WG, the topic of AS112 has been addresses in the DNSOP WG resulting in RFCs 6304 and 6305 and is also related to 'local zones' as described in RFC 6303. The question of extending AS112 service to IPv6 (as in "transport") as well as the maintainability of the list of zones served by AS112 sys

[DNSOP] Adoption of "DNSSEC Key Timing Considerations"

Dear WG, "DNSSEC Key Timing Considerations", draft-morris-dnsop-dnssec-key-timing-02.txt, and its predecessors were presented to the working group in Anaheim the last time. There was discussion on the document itself as well as its relation to draft-ietf-dnsop-rfc4641bis. The authors asked for a

Re: [DNSOP] Adoption of

On Thu, Nov 12, 2009 at 07:07:13AM +0100, $me wrote: [adoption of ...] > DNSSEC Signing Policy & Practice Statement Framework > > > This mail is to confirm the adoption on the WG list. Unless we hear > disagreement

[DNSOP] Adoption of

Dear WG, during the session on Wednesday, the authors of DNSSEC Signing Policy & Practice Statement Framework asked for the adoption of the draft as a working group item. The sense of the room was in favour o

[DNSOP] Adoption of

Dear DNSOP WG, just to let everybody know: given that was a design team deliverable and there was considerable support during the DNSOP meeting today, this draft is now an accepted deliverable as a starting point for future work and therefore adopted as a working group document. We'll figure out