Re: [DNSOP] "flagday" again, was Re: Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[Mark Andrews]

> On 3 Jul 2019, at 2:16 pm, Paul Wouters  wrote:
> 
> On Wed, 3 Jul 2019, Mark Andrews wrote:
> 
>> Defeating fragmentation attacks requires more than a BCP.
>> 
>> https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00
> 
> Sure, so you have an RFC already then. great. No need for a flag day
> event reference, as you will have a proper RFC reference.
> 
 Changing default EDNS buffer size is, I believe, in competency of
 individual implementations, so we as implementors will do a thing we
 deem sensible.
>>> 
>>> No one is saying you are not sensible. My point was that none of this
>>> is a flag day, and the promotion to reach a few implementations via
>>> "flag days" is better directed at writing a new or updated RFC that
>>> explains the issue and recommends implementors what (not) to do. That
>>> also helps downstream with customers wanting RFC ABC compliance, which
>>> is a much stronger signal than compliance to "dnsflagday.net/2020”.
>> 
>> Winding back the default EDNS buffer size will break interoperability
>> with servers that now send TC=1 responses that otherwise didn’t happen
>> and do not accept TCP.
>> 
>> The key point of a flag day is that it is the day after which
>> interoperability fails, not the rate at which it is deploy which
>> you appear to be concentrating on.
> 
> But again,
> 
> We turn off old things on the internet all the time. It breaks
> ancient stuff all the time too. We try to steer that process from the
> IETF by gradually obsoleting/replacing code. But we don't do that in a
> vaccum. We observe deployment statistics and try to push a little harder
> to move the market when it is being slow.

Observed misbehaviours over time 
https://ednscomp.isc.org/compliance/summary.html
You can drill down to specific failure modes.

> And it is not a "flag day" because it depends on downstream release schedules

Actually it is.  Nothing about “flag day” requires everything to be 
instantaneous.

>> The DNS 2019 not only had ON THE DAY changes (thanks to Google changing
>> their 8.8.8.8 service on the day)
> 
> So even pumping up the hype didn't actually help inform the people that
> needed it the most. To me that is more an argument that flagdaying does
> not do much good to begin with, and it is not woth the bad things it does
> to the reputation of DNS by making the DNS appear worse than it is.

Actually we reached lots of people that needed to be reached.

Did we reach everybody? No but no one expected to reach everybody.

Did we measurably improve the situation? Yes.

> Paul

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] "flagday" again, was Re: Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[Töma Gavrichenkov]

Peace,

On Wed, Jul 3, 2019, 7:17 AM Paul Wouters  wrote:

> On Wed, 3 Jul 2019, Mark Andrews wrote:
> > The DNS 2019 not only had ON THE DAY changes (thanks to Google changing
> > their 8.8.8.8 service on the day)
>
> So even pumping up the hype didn't actually help inform the people that
> needed it the most.
>

Err...
That's a strange conclusion.  I've personally seen dozens of server farms
being upgraded in less than a week in January, after another round of hype
hit the news.

Most of them could've done that a couple years ago.  Could as well have
stayed they way they were until right now.

--
Töma

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

Re: [DNSOP] "flagday" again, was Re: Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[Paul Wouters]

On Wed, 3 Jul 2019, Mark Andrews wrote:


Defeating fragmentation attacks requires more than a BCP.

https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00


Sure, so you have an RFC already then. great. No need for a flag day
event reference, as you will have a proper RFC reference.


Changing default EDNS buffer size is, I believe, in competency of
individual implementations, so we as implementors will do a thing we
deem sensible.


No one is saying you are not sensible. My point was that none of this
is a flag day, and the promotion to reach a few implementations via
"flag days" is better directed at writing a new or updated RFC that
explains the issue and recommends implementors what (not) to do. That
also helps downstream with customers wanting RFC ABC compliance, which
is a much stronger signal than compliance to "dnsflagday.net/2020”.


Winding back the default EDNS buffer size will break interoperability
with servers that now send TC=1 responses that otherwise didn’t happen
and do not accept TCP.

The key point of a flag day is that it is the day after which
interoperability fails, not the rate at which it is deploy which
you appear to be concentrating on.


But again,

We turn off old things on the internet all the time. It breaks
ancient stuff all the time too. We try to steer that process from the
IETF by gradually obsoleting/replacing code. But we don't do that in a
vaccum. We observe deployment statistics and try to push a little harder
to move the market when it is being slow.

And it is not a "flag day" because it depends on downstream release schedules


The DNS 2019 not only had ON THE DAY changes (thanks to Google changing
their 8.8.8.8 service on the day)


So even pumping up the hype didn't actually help inform the people that
needed it the most. To me that is more an argument that flagdaying does
not do much good to begin with, and it is not woth the bad things it does
to the reputation of DNS by making the DNS appear worse than it is.

Paul

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

Re: [DNSOP] "flagday" again, was Re: Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[Mark Andrews]

> On 3 Jul 2019, at 12:31 am, Paul Wouters  wrote:
> 
> On Tue, 2 Jul 2019, Petr Špaček wrote:
> 
>> Let me clarify that we (as DNS flag day organizers) are not even
>> touching any RFC language because all the necessary pieces are already
>> standardized (madatory TCP support + mechanism to handle EDNS buffer size).
> 
> If there is a security issue with fragmented DNS packets, perhaps that
> warrants a new RFC document, possibly a BCP, that instructs implementers
> what to do.

Defeating fragmentation attacks requires more than a BCP.

https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00

>> Some people claim that IETF cannot put requirements on operators, only
>> on implementations. We (as software and service vendors) are now saying
>> "if you want to interoperate, you as an operator have to follow
>> standards mandated for implementations", because in the end, what's
>> mandated for implementation does not matter if operators ignore these
>> requirements.
> 
> That is not different from the examples I gave earlier for those RFCs.
> You can encourage/discourage or obsolete features. The good thing of
> doing that in an RFC is that organizations and goverments and vendors
> can point to it for compliance or policy and explain why it is done
> a certain way.
> 
>> Of course it has to be explained to non-IETFers in many more words to
>> eliminate requirement to read all the RFCs, but that's it.
> 
> If you think that, you haven't properly informed implementers via
> existing RFCs. A new one is apparently needed. I don't see why this
> should not be done here. This is dnsops. If you find an operational
> issue, you write a clarifying or correcting RFC.

Awaiting last call

https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-13

>> Changing default EDNS buffer size is, I believe, in competency of
>> individual implementations, so we as implementors will do a thing we
>> deem sensible.
> 
> No one is saying you are not sensible. My point was that none of this
> is a flag day, and the promotion to reach a few implementations via
> "flag days" is better directed at writing a new or updated RFC that
> explains the issue and recommends implementors what (not) to do. That
> also helps downstream with customers wanting RFC ABC compliance, which
> is a much stronger signal than compliance to "dnsflagday.net/2020”.

Winding back the default EDNS buffer size will break interoperability
with servers that now send TC=1 responses that otherwise didn’t happen
and do not accept TCP.

The key point of a flag day is that it is the day after which
interoperability fails, not the rate at which it is deploy which
you appear to be concentrating on.

The DNS 2019 not only had ON THE DAY changes (thanks to Google changing
their 8.8.8.8 service on the day) but introduce interoperability changes
between servers that where not compliant (failed to answer) and clients
that no longer worked around the non compliance.

>> Let's continue discussion about dns flag day 2020 at mailing list
>> dns-operati...@lists.dns-oarc.net, please.
> 
> I'd rather not. Operational issues related to the DNS protocol
> (mis)implementations or standard behaviour are well within the
> charter of this group. DNS-OARC is a good venue to look at what
> is happening, discuss why certain operational things are happening,
> maybe brainstorm on how to fix it. Then coming to this group with
> a proposal for a document to inform everyone and improve everything
> is the right venue. It seems the problem and solution are already
> well defined. It just needs to be written down in an RFC, and then
> gradually software can implement the new behaviour. And again, if
> for reasons vendors decide to implement it all on the same day to
> ensure strict vendors are not unreasonably punished by being blamed
> for failures, that's a reasonable goal. But seeing how upstream
> vendors have no control over when downstream vendors pick up new
> versions, the term "flag day" is just not the correct term to use,
> and only brings up negative connotations in people being misled
> into thinking IETF protocols needs flag days to continue running.
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Obsoleting DLV

[Paul Vixie]

fine by me.

⁣Get BlueMail for Android ​

On 2 Jul 2019, 13:11, at 13:11, Dan York  wrote:
>
>
>> On Jul 2, 2019, at 3:31 PM, Jim Reid  wrote:
>>
>>
>>
>>> On 2 Jul 2019, at 19:12, Matthijs Mekking 
>wrote:
>>>
>>> I think it is time to move the protocol to Historic status as a
>clear signal to
>>> everyone that it should no longer be implemented or deployed.
>>
>> Agreed. Kill it with fire!
>
>Yes, please!  We can celebrate all it did to help get DNSSEC going, but
>that time is now long gone.
>
>Dan
>___
>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

Re: [DNSOP] Obsoleting DLV

[Dan York]

> On Jul 2, 2019, at 3:31 PM, Jim Reid  wrote:
> 
> 
> 
>> On 2 Jul 2019, at 19:12, Matthijs Mekking  wrote:
>> 
>> I think it is time to move the protocol to Historic status as a clear signal 
>> to
>> everyone that it should no longer be implemented or deployed.
> 
> Agreed. Kill it with fire!

Yes, please!  We can celebrate all it did to help get DNSSEC going, but that 
time is now long gone.

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

Re: [DNSOP] [Ext] WGLC for draft-ietf-dnsop-serve-stale

[Suzanne Woolf]

> On Jul 2, 2019, at 10:01 AM, Paul Hoffman  wrote:
> 
> On Jul 2, 2019, at 6:36 AM, Suzanne Woolf  wrote:
>> First, there have been several IPR disclosures against this document. The 
>> chairs believe all have been resolved.
> 
> Please clarify what "The chairs believe all have been resolved" means in this 
> context. There are seven IPR statements on the document.

The seven IPR statements relate to disclosures regarding IP of three companies, 
Google, Akamai, and Cisco. In all three cases, those companies appear to have 
put licensing terms regarding the patents referred to into the data tracker; 
there are no disclosures that haven’t been acknowledged by the stated holders 
of the IP, or that the holder has promised to update later. 

Please see 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-dnsop-serve-stale
 for the details. 

Note also the boilerplate at https://datatracker.ietf.org/ipr/. Neither the 
chairs nor the IETF has any opinion on the content of any of those statements, 
we do however note they exist.


Suzanne
(For the chairs)



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

Re: [DNSOP] Obsoleting DLV

[Erwin Lansing]

> On 2 Jul 2019, at 21.31, Jim Reid  wrote:
> 
> 
> 
>> On 2 Jul 2019, at 19:12, Matthijs Mekking  wrote:
>> 
>> I think it is time to move the protocol to Historic status as a clear signal 
>> to
>> everyone that it should no longer be implemented or deployed.
> 
> Agreed. Kill it with fire!
> 

Should have know last week, we had a nice big bonfire just for the occasion :-)

Yes, please put it out of its misery.

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

Re: [DNSOP] Obsoleting DLV

[Jim Reid]

> On 2 Jul 2019, at 19:12, Matthijs Mekking  wrote:
> 
> I think it is time to move the protocol to Historic status as a clear signal 
> to
> everyone that it should no longer be implemented or deployed.

Agreed. Kill it with fire!

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

Re: [DNSOP] Obsoleting DLV

[Joe Abley]

+1 to all of that which follows!

> On 2 Jul 2019, at 14:41, Paul Wouters  wrote:
> 
> On Tue, 2 Jul 2019, Matthijs Mekking wrote:
> 
>> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
>> time to move the protocol to Historic status as a clear signal to
>> everyone that it should no longer be implemented or deployed.
> 
> I agree with moving DLV to historic. It is no longer needed at large,
> and while it can serve a few corner cases, the only public DLV registry
> has been deactivated years ago, and DLV is not universally implemented
> to begin with, so one could not depend on a new to be launched DLV registry
> anyways.
> 
> The draft seems to explain it well.
> 
>> Title: Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> 
>> https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/
> 
>   "As of May 2019, the root zone is signed"
> 
> While it is correct that in May 2019, the root zone is signed, I don't
> think that's the information you are trying to relay :) :) :)
> 
> 
> 3.1.1.2.  I-D.lhotka-dnsop-iana-class-type-yang
> 
>   The draft "YANG Types for DNS Classes and Resource Record Types"
>   [I-D.lhotka-dnsop-iana-class-type-yang] refers to RFC 4431 to
>   describe the DLV entry in the YANG module iana-dns-class-rr-type.
>   This reference should be removed.
> 
> I think this does not need to be in this document, but the authors
> should be requested to remove it in an update to their document.
> In general, yang documents should not populate IANA registries, which
> is something I raised afew months ago and the yang community is looking
> at that. (and reference IANA registries instead)
> 
> And I think Ondej  should fix up his name :)
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Warren Kumari]

On Tue, Jul 2, 2019 at 11:13 AM Matthijs Mekking 
wrote:

> Hi,
>
>
> A while back I was asked why BIND 9 still had code to do DLV. Good
> question, and we asked our users if they would mind if we remove the
> code. Almost everyone was okay with that.
>
> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
> time to move the protocol to Historic status as a clear signal to
> everyone that it should no longer be implemented or deployed.
>
> Dan Mahoney cleared the only well-known DLV registry almost two years
> ago. Here's a draft with discussion why also the protocol should go
> away. We would like to hear what you think about it.
>

Yes please; DLV was a useful tool to get DNSSEC off the ground, but had
long outlived its usefulness, and is now just extra code to fail.

Rip it out,
W


>
> Best regards,
>
> Matthijs
>
>
>  Forwarded Message 
> A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
> has been successfully submitted by Matthijs Mekking and posted to the
> IETF repository.
>
> Name: draft-mekking-dnsop-obsolete-dlv
> Revision: 00
> Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> Pages:5
> Status:
>
>   https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/
>
> Abstract:
>This document obsoletes DNSSEC lookaside validation (DLV) and
>reclassifies RFCs 4431 and 5074 as Historic.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Paul Wouters]

On Tue, 2 Jul 2019, Matthijs Mekking wrote:


So ISC plans to deprecate the feature in BIND 9.  But also I think it is
time to move the protocol to Historic status as a clear signal to
everyone that it should no longer be implemented or deployed.


I agree with moving DLV to historic. It is no longer needed at large,
and while it can serve a few corner cases, the only public DLV registry
has been deactivated years ago, and DLV is not universally implemented
to begin with, so one could not depend on a new to be launched DLV registry
anyways.

The draft seems to explain it well.


Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status



 https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/


"As of May 2019, the root zone is signed"

While it is correct that in May 2019, the root zone is signed, I don't
think that's the information you are trying to relay :) :) :)


3.1.1.2.  I-D.lhotka-dnsop-iana-class-type-yang

   The draft "YANG Types for DNS Classes and Resource Record Types"
   [I-D.lhotka-dnsop-iana-class-type-yang] refers to RFC 4431 to
   describe the DLV entry in the YANG module iana-dns-class-rr-type.
   This reference should be removed.

I think this does not need to be in this document, but the authors
should be requested to remove it in an update to their document.
In general, yang documents should not populate IANA registries, which
is something I raised afew months ago and the yang community is looking
at that. (and reference IANA registries instead)

And I think Ondej  should fix up his name :)

Paul

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

Re: [DNSOP] Obsoleting DLV

[David Conrad]

I strongly support moving it to Historic.

Regards,
-drc

> On Jul 2, 2019, at 11:12 AM, Matthijs Mekking  wrote:
> 
> Hi,
> 
> 
> A while back I was asked why BIND 9 still had code to do DLV. Good
> question, and we asked our users if they would mind if we remove the
> code. Almost everyone was okay with that.
> 
> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
> time to move the protocol to Historic status as a clear signal to
> everyone that it should no longer be implemented or deployed.
> 
> Dan Mahoney cleared the only well-known DLV registry almost two years
> ago. Here's a draft with discussion why also the protocol should go
> away. We would like to hear what you think about it.
> 
> 
> Best regards,
> 
> Matthijs
> 
> 
>  Forwarded Message 
> A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
> has been successfully submitted by Matthijs Mekking and posted to the
> IETF repository.
> 
> Name:   draft-mekking-dnsop-obsolete-dlv
> Revision: 00
> Title:  Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> Pages:  5
> Status:
> 
>  https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/ 
> 
> 
> Abstract:
>   This document obsoletes DNSSEC lookaside validation (DLV) and
>   reclassifies RFCs 4431 and 5074 as Historic.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Obsoleting DLV

[Matthijs Mekking]

Hi,


A while back I was asked why BIND 9 still had code to do DLV. Good
question, and we asked our users if they would mind if we remove the
code. Almost everyone was okay with that.

So ISC plans to deprecate the feature in BIND 9.  But also I think it is
time to move the protocol to Historic status as a clear signal to
everyone that it should no longer be implemented or deployed.

Dan Mahoney cleared the only well-known DLV registry almost two years
ago. Here's a draft with discussion why also the protocol should go
away. We would like to hear what you think about it.


Best regards,

Matthijs


 Forwarded Message 
A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
has been successfully submitted by Matthijs Mekking and posted to the
IETF repository.

Name: draft-mekking-dnsop-obsolete-dlv
Revision: 00
Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status
Pages:5
Status:

  https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/

Abstract:
   This document obsoletes DNSSEC lookaside validation (DLV) and
   reclassifies RFCs 4431 and 5074 as Historic.

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

Re: [DNSOP] "flagday" again, was Re: Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[Paul Wouters]

On Tue, 2 Jul 2019, Petr Špaček wrote:


Let me clarify that we (as DNS flag day organizers) are not even
touching any RFC language because all the necessary pieces are already
standardized (madatory TCP support + mechanism to handle EDNS buffer size).


If there is a security issue with fragmented DNS packets, perhaps that
warrants a new RFC document, possibly a BCP, that instructs implementers
what to do.


Some people claim that IETF cannot put requirements on operators, only
on implementations. We (as software and service vendors) are now saying
"if you want to interoperate, you as an operator have to follow
standards mandated for implementations", because in the end, what's
mandated for implementation does not matter if operators ignore these
requirements.


That is not different from the examples I gave earlier for those RFCs.
You can encourage/discourage or obsolete features. The good thing of
doing that in an RFC is that organizations and goverments and vendors
can point to it for compliance or policy and explain why it is done
a certain way.


Of course it has to be explained to non-IETFers in many more words to
eliminate requirement to read all the RFCs, but that's it.


If you think that, you haven't properly informed implementers via
existing RFCs. A new one is apparently needed. I don't see why this
should not be done here. This is dnsops. If you find an operational
issue, you write a clarifying or correcting RFC.


Changing default EDNS buffer size is, I believe, in competency of
individual implementations, so we as implementors will do a thing we
deem sensible.


No one is saying you are not sensible. My point was that none of this
is a flag day, and the promotion to reach a few implementations via
"flag days" is better directed at writing a new or updated RFC that
explains the issue and recommends implementors what (not) to do. That
also helps downstream with customers wanting RFC ABC compliance, which
is a much stronger signal than compliance to "dnsflagday.net/2020".


Let's continue discussion about dns flag day 2020 at mailing list
dns-operati...@lists.dns-oarc.net, please.


I'd rather not. Operational issues related to the DNS protocol
(mis)implementations or standard behaviour are well within the
charter of this group. DNS-OARC is a good venue to look at what
is happening, discuss why certain operational things are happening,
maybe brainstorm on how to fix it. Then coming to this group with
a proposal for a document to inform everyone and improve everything
is the right venue. It seems the problem and solution are already
well defined. It just needs to be written down in an RFC, and then
gradually software can implement the new behaviour. And again, if
for reasons vendors decide to implement it all on the same day to
ensure strict vendors are not unreasonably punished by being blamed
for failures, that's a reasonable goal. But seeing how upstream
vendors have no control over when downstream vendors pick up new
versions, the term "flag day" is just not the correct term to use,
and only brings up negative connotations in people being misled
into thinking IETF protocols needs flag days to continue running.

Paul

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

Re: [DNSOP] [Ext] WGLC for draft-ietf-dnsop-serve-stale

[Paul Hoffman]

On Jul 2, 2019, at 6:36 AM, Suzanne Woolf  wrote:
> First, there have been several IPR disclosures against this document. The 
> chairs believe all have been resolved.

Please clarify what "The chairs believe all have been resolved" means in this 
context. There are seven IPR statements on the document.

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

[DNSOP] IETF 105 Agenda and Call for Agenda Items DNSOP WG

[Benno Overeinder]

Hi all,

The IETF105 Agenda is out
https://datatracker.ietf.org/meeting/105/agenda.html and DNSOP has two
sessions

Monday 18:10-19:10  Monday Afternoon session III

Tuesday 10:00-12:00 Tuesday Morning session I

As with the previous IETF meeting, we are planning the shorter (1 hour),
first meeting for newer work that may not have much comment and the
longer, second meeting is initially reserved for already adopted work.


This is also a call for Agenda requests.  Please email the chairs
 with your requests.  *Or* drop us a pull request
https://github.com/DNSOP/dnsop-ietf105 look for
dnsop-ietf105-agenda-requests.txt

Please Note: Draft Submission Deadline is Monday July 8, 2019

Thanks,

Tim
Suzanne
Benno

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

[DNSOP] WGLC for draft-ietf-dnsop-serve-stale

[Suzanne Woolf]

Dear colleagues,


This message starts the Working Group Last Call for 
draft-ietf-dnsop-serve-stale 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/).

Since this draft has not been recently discussed in the WG, we figure people 
might need to swap it back in, and we will be meeting soon in Montreal. So the 
WGLC will end in three weeks (instead of the usual two), on 23 July. We will 
have agenda time if needed to go over any open issues.

Two process points worth noting:

First, there have been several IPR disclosures against this document. The 
chairs believe all have been resolved.

Second, our AD (Warren) is an author on this document, so we’ll be following 
the IETF convention that he won’t be shepherding it in the IESG. His co-AD, 
Barry Leiba, will shepherd it.



Thanks,
Suzanne, Tim, & Benno
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop