Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-06-12 Thread Benno Overeinder
Hi,

On 11/06/2018 22:15, Paul Hoffman wrote:
> On 11 Jun 2018, at 12:43, Job Snijders wrote:
> 
>> For what it's worth - all my concerns have been addressed.
> 
> +1 to Job's feeling.

Thank you all.

>> I believe
>> the document to be in good shape now and would support a progression
>> through WG LC.
> 
> except that we already went through WG Last Call.
> 
> The changes to the document are large, but it is not clear to me that
> enough people are reading them to warrant another WG Last Call before
> sending it to the IETF Last Call.

Fair enough, we will coordinate with Terry Manderson, the AD for the
document, if another WG Last Call is appropriate.

Regards,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-06-11 Thread Paul Hoffman

On 11 Jun 2018, at 12:43, Job Snijders wrote:


For what it's worth - all my concerns have been addressed.


+1 to Job's feeling.


I believe
the document to be in good shape now and would support a progression
through WG LC.


except that we already went through WG Last Call.

The changes to the document are large, but it is not clear to me that 
enough people are reading them to warrant another WG Last Call before 
sending it to the IETF Last Call.



I appreciate the effort the authors have put into
making this an exemplary specification!


+1 again.

--Paul Hoffman

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-06-11 Thread Job Snijders
Dear all,

For what it's worth - all my concerns have been addressed. I believe
the document to be in good shape now and would support a progression
through WG LC. I appreciate the effort the authors have put into
making this an exemplary specification!

Kind regards,

Job


On Mon, Jun 11, 2018 at 7:30 PM, Warren Kumari  wrote:
> Dear WG (and chairs),
>
> Firstly, thank you to everyone who supported this, those who provided
> comments (especially pull requests!) and implementers.
>
> We have made a number of improvements to the documents based upon your
> comments - the diff can be seen here:
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-kskroll-sentinel-10=draft-ietf-dnsop-kskroll-sentinel-14
>
> Possibly more helpful is the GitHub list of Pull Requests:
> https://github.com/APNIC-Labs/draft-kskroll-sentinel/pulls?q=is%3Apr+is%3Aclosed
>
> We've added an implementation section - I know that there were more "client"
> side (the Javascript or similar automated tests); I'd been keeping a note
> with a list, but seem to have misplaced it.
>
> BIND and Unbound now support this; AFAIK, Knot supports the older name.
>
>
> I *think* that we've managed to address the comments, but if we happened to
> miss yours, please let us know.
>
> From my read of the WGs views, these, being *labels*, are not *Special Use
> Domain Names*, and so don't need to be added to the SUDN registry.
>
> The authors would like to thank the WG again, and ask that WGLC be resumed.
>
> W
>
>
> On Tue, Apr 24, 2018 at 9:02 AM Ondřej Surý  wrote:
>>
>> And the MR was peer-review and merged into BIND master branch with intent
>> to backport the feature into older release branches.
>>
>> I don’t think it’s a useful or helpful to change the rules for existing
>> adopted work.  We need to have a discussion on the mechanisms that would
>> allow implementors to know when to start the implementation of existing
>> draft. From implementors point, it makes little sense to start implementing
>> before the protocol change is almost fully baked (aka WGLC and further),
>> because until then the protocol might change considerably.
>>
>> So, if we require implementation report further down the road, it needs to
>> be more clearly defined than people suddenly shouting “this is not ready”
>> when WGLC starts.  And while the attempt to implement something is certainly
>> useful to get valuable feedback, it also imposes some costs (with undefined
>> limit) on implementors (especially the open source implementors) and it sort
>> of discards the whole “Proposed Standard” -> “Internet Standard”
>> classification at global IETF level.
>>
>> I get that we probably need something more lightweight than “Internet
>> Standard” at the WG level, but this needs to be discussed and consensus
>> reached.
>>
>> ISC gave our feedback during the implementation and here are some nits
>> from me (re-reading the document again):
>>
>> ~~~
>>
>> Section "2.  Protocol Walkthrough Example" will be made into Appendix at
>> publication time, so just reminder here that you also need to change the
>> references like "(see the logic below)” when you move the section - perhaps
>> add direct reference to the other section this refers to?
>>
>> ~~~
>>
>> The table in 3.2 says:
>>
>> "Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit
>> confusing to me; I think that “Key is trusted” and “Key is not trusted”; or
>> some change similar to this needs to be made:
>>
>> “First, the resolver determines if the Key Tag is trusted by comparing
>> numerical value of 
>>to any of the Key Tags of an active root zone KSK which is
>>currently trusted…"
>>
>> in paragraph just before the table you mix “Key Tag” and “keytag” and
>> there’s also …
>>
>> My understanding of the text and the proposed fix:
>>
>> […]
>>
>>First, the resolver determines if the numerical value of  is
>>equal to any of the Key Tags of an active root zone KSK which is
>>currently trusted by the local resolver and is stored in its store of
>>trusted keys.  If a match is found the  is trusted. An active
>>root zone KSK is one which could currently be used for
>>validation (that is, a key that is not in either the AddPend or
>>Revoked state as described in [RFC5011]).
>>
>>Second, the resolver alters the response being sent to the original
>>query based on both the left-most label and the presence of a key
>>with given Key Tag in the trust anchor store.  Two labels and two
>>possible states of the  generate four possible combinations
>>summarized in the table:
>>
>> Label  |is trusted|is not trusted
>> --
>> is-ta  | return original answer  | return SERVFAIL
>> not-ta | return SERVFAIL | return original answer
>>
>> […]
>>
>> ~~~
>>
>>o  A query name that is signed with a DNSSEC signature that cannot be
>>   validated (such as if the 

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-06-11 Thread Warren Kumari
Dear WG (and chairs),

Firstly, thank you to everyone who supported this, those who provided
comments (especially pull requests!) and implementers.

We have made a number of improvements to the documents based upon your
comments - the diff can be seen here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-kskroll-sentinel-10=draft-ietf-dnsop-kskroll-sentinel-14

Possibly more helpful is the GitHub list of Pull Requests:
https://github.com/APNIC-Labs/draft-kskroll-sentinel/pulls?q=is%3Apr+is%3Aclosed

We've added an implementation section - I know that there were more
"client" side (the Javascript or similar automated tests); I'd been keeping
a note with a list, but seem to have misplaced it.

BIND and Unbound now support this; AFAIK, Knot supports the older name.


I *think* that we've managed to address the comments, but if we happened to
miss yours, please let us know.

>From my read of the WGs views, these, being *labels*, are not *Special Use
Domain Names*, and so don't need to be added to the SUDN registry.

The authors would like to thank the WG again, and ask that WGLC be resumed.

W


On Tue, Apr 24, 2018 at 9:02 AM Ondřej Surý  wrote:

> And the MR was peer-review and merged into BIND master branch with intent
> to backport the feature into older release branches.
>
> I don’t think it’s a useful or helpful to change the rules for existing
> adopted work.  We need to have a discussion on the mechanisms that would
> allow implementors to know when to start the implementation of existing
> draft. From implementors point, it makes little sense to start implementing
> before the protocol change is almost fully baked (aka WGLC and further),
> because until then the protocol might change considerably.
>
> So, if we require implementation report further down the road, it needs to
> be more clearly defined than people suddenly shouting “this is not ready”
> when WGLC starts.  And while the attempt to implement something is
> certainly useful to get valuable feedback, it also imposes some costs (with
> undefined limit) on implementors (especially the open source implementors)
> and it sort of discards the whole “Proposed Standard” -> “Internet
> Standard” classification at global IETF level.
>
> I get that we probably need something more lightweight than “Internet
> Standard” at the WG level, but this needs to be discussed and consensus
> reached.
>
> ISC gave our feedback during the implementation and here are some nits
> from me (re-reading the document again):
>
> ~~~
>
> Section "2.  Protocol Walkthrough Example" will be made into Appendix at
> publication time, so just reminder here that you also need to change the
> references like "(see the logic below)” when you move the section - perhaps
> add direct reference to the other section this refers to?
>
> ~~~
>
> The table in 3.2 says:
>
> "Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit
> confusing to me; I think that “Key is trusted” and “Key is not trusted”; or
> some change similar to this needs to be made:
>
> “First, the resolver determines if the Key Tag is trusted by comparing
> numerical value of 
>to any of the Key Tags of an active root zone KSK which is
>currently trusted…"
>
> in paragraph just before the table you mix “Key Tag” and “keytag” and
> there’s also …
>
> My understanding of the text and the proposed fix:
>
> […]
>
>First, the resolver determines if the numerical value of  is
>equal to any of the Key Tags of an active root zone KSK which is
>currently trusted by the local resolver and is stored in its store of
>trusted keys.  If a match is found the  is trusted. An active
>root zone KSK is one which could currently be used for
>validation (that is, a key that is not in either the AddPend or
>Revoked state as described in [RFC5011]).
>
>Second, the resolver alters the response being sent to the original
>query based on both the left-most label and the presence of a key
>with given Key Tag in the trust anchor store.  Two labels and two
>possible states of the  generate four possible combinations
>summarized in the table:
>
> Label  |is trusted|is not trusted
> --
> is-ta  | return original answer  | return SERVFAIL
> not-ta | return SERVFAIL | return original answer
>
> […]
>
> ~~~
>
>o  A query name that is signed with a DNSSEC signature that cannot be
>   validated (such as if the corresponding RRset is not signed with a
>   valid RRSIG record).
>
> This is called “Bogus” by RFC 4033 Section 5 -> maybe a reference?
>
> ~~~
>
> In  Section: 7.  Privacy Considerations
>
> s/mechansim/mechanism/
>
> ~~~
>
> That is all folks.
>
> Cheers,
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 7 Apr 2018, at 08:27, Evan Hunt  wrote:
> >
> > On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote:
> >> I think I heard that ISC 

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-24 Thread Ondřej Surý
And the MR was peer-review and merged into BIND master branch with intent to 
backport the feature into older release branches.

I don’t think it’s a useful or helpful to change the rules for existing adopted 
work.  We need to have a discussion on the mechanisms that would allow 
implementors to know when to start the implementation of existing draft. From 
implementors point, it makes little sense to start implementing before the 
protocol change is almost fully baked (aka WGLC and further), because until 
then the protocol might change considerably.

So, if we require implementation report further down the road, it needs to be 
more clearly defined than people suddenly shouting “this is not ready” when 
WGLC starts.  And while the attempt to implement something is certainly useful 
to get valuable feedback, it also imposes some costs (with undefined limit) on 
implementors (especially the open source implementors) and it sort of discards 
the whole “Proposed Standard” -> “Internet Standard” classification at global 
IETF level.

I get that we probably need something more lightweight than “Internet Standard” 
at the WG level, but this needs to be discussed and consensus reached.

ISC gave our feedback during the implementation and here are some nits from me 
(re-reading the document again):

~~~

Section "2.  Protocol Walkthrough Example" will be made into Appendix at 
publication time, so just reminder here that you also need to change the 
references like "(see the logic below)” when you move the section - perhaps add 
direct reference to the other section this refers to?

~~~

The table in 3.2 says:

"Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit 
confusing to me; I think that “Key is trusted” and “Key is not trusted”; or 
some change similar to this needs to be made:

“First, the resolver determines if the Key Tag is trusted by comparing 
numerical value of 
   to any of the Key Tags of an active root zone KSK which is
   currently trusted…"

in paragraph just before the table you mix “Key Tag” and “keytag” and there’s 
also …

My understanding of the text and the proposed fix:

[…]

   First, the resolver determines if the numerical value of  is
   equal to any of the Key Tags of an active root zone KSK which is
   currently trusted by the local resolver and is stored in its store of
   trusted keys.  If a match is found the  is trusted. An active
   root zone KSK is one which could currently be used for
   validation (that is, a key that is not in either the AddPend or
   Revoked state as described in [RFC5011]).  

   Second, the resolver alters the response being sent to the original
   query based on both the left-most label and the presence of a key
   with given Key Tag in the trust anchor store.  Two labels and two
   possible states of the  generate four possible combinations
   summarized in the table:

Label  |is trusted|is not trusted
--
is-ta  | return original answer  | return SERVFAIL
not-ta | return SERVFAIL | return original answer

[…]

~~~

   o  A query name that is signed with a DNSSEC signature that cannot be
  validated (such as if the corresponding RRset is not signed with a
  valid RRSIG record).

This is called “Bogus” by RFC 4033 Section 5 -> maybe a reference?

~~~

In  Section: 7.  Privacy Considerations

s/mechansim/mechanism/

~~~

That is all folks.

Cheers,
Ondrej
--
Ondřej Surý
ond...@isc.org

> On 7 Apr 2018, at 08:27, Evan Hunt  wrote:
> 
> On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote:
>> I think I heard that ISC was considering adding support, but was
>> planning on waiting till RFC / some sort of LC.
> 
> Yes. The work in progress is available here:
> https://gitlab.isc.org/isc-projects/bind9/merge_requests/123
> 
> -- 
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> 
> ___
> 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] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-13 Thread Peter van Dijk

Hello Suzanne,

On 6 Apr 2018, at 23:49, Suzanne Woolf wrote:

We’re hearing that having an RFC will be helpful to promoting 
implementation, and also that this draft may not be ready to be 
advanced for publication because it doesn’t include implementation 
experience. This is something the WG needs to comment on further, 
because it seems substantive to me so it will have to be addressed one 
way or another before we advance the document— but those inputs are 
somewhat in disagreement.


In WG context, not in draft context: I do not think these inputs are in 
disagreement. If a draft can find -zero- implementers that think the 
draft is a sufficiently good idea that they write an implementation 
during draft status, the draft is, most likely, a bad idea.


Editors: Please take “concern about a description of current 
implementation status” as WGLC input, and consider what you might be 
able to add to the draft to address it.


WG vendors/implementers: Can folks who have implemented 
kskroll-sentinel, or considered implementing it, please speak up on 
your concerns/plans?


Because of privacy concerns (currently raised in section 7 of the draft 
quite briefly), PowerDNS will not be implementing this protocol.


Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-11 Thread George Michaelson
I'd like the WG to close on this. It feels to me like we've had useful
edit in the call and the document is now stable and ready to move onto
the next phase.

Ship it.

-George

On Fri, Apr 6, 2018 at 2:35 AM, tjw ietf  wrote:
>
> After walking through the 168 emails on this draft in the inbox, I feel
> we're ready to take this to WGLC.
>
> (We are aware of the two points raised my Job and Paul)
>
>
> This starts a Working Group Last Call for:
> draft-ietf-dnsop-kskroll-sentinel
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>
> The Current Intended Status of this document is: Proposed Standard
>
> In the brushing of the camel, the draft is focused on determining if
> a particular root key has been loaded into resolvers.
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> if someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  23:59
> 19 April 2018
>
> thanks
> tim
>
>
> ___
> 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] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-09 Thread Bob Harold
On Sat, Apr 7, 2018 at 5:41 AM, Benno Overeinder  wrote:

> Hi Suzanne, Warren, DNSOP WG,
>
> > On 7 Apr 2018, at 04:09, Warren Kumari  wrote:
> >
> > On Fri, Apr 6, 2018 at 5:49 PM, Suzanne Woolf 
> wrote:
> >>
> >>
> >> WG vendors/implementers: Can folks who have implemented
> kskroll-sentinel, or considered implementing it, please speak up on your
> concerns/plans?
> >
> > Yup, that would be helpful  - bits I know of are that Knot has an
> > implementation based on an earlier version (with a different label),
> > and Petr says that it will be some time before they are able to update
> > it; I've never touched Lua, if I get a chance I might try patch their
> > implementation with the new strings ("Hold my beer" / "How hard can it
> > be?")).
> > I think I heard that ISC was considering adding support, but was
> > planning on waiting till RFC / some sort of LC.
> >
>
> NLnet Labs is planning to add kskroll-sentinel support soon.  We will
> report progress and feedback to the authors of the kskroll-sentinel draft..
>
> Code will be made available in our repository and asap be part of the
> Unbound release (for packaging & distribution).
>
> Cheers,
>
> — Benno
>
>
> --
> Benno J. Overeinder
> NLnet Labs
> https://www.nlnetlabs.nl/
>
>
+1 to holding for a while to see if implementations find any issues.

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-07 Thread Benno Overeinder
Hi Suzanne, Warren, DNSOP WG,

> On 7 Apr 2018, at 04:09, Warren Kumari  wrote:
> 
> On Fri, Apr 6, 2018 at 5:49 PM, Suzanne Woolf  wrote:
>> 
>> 
>> WG vendors/implementers: Can folks who have implemented kskroll-sentinel, or 
>> considered implementing it, please speak up on your concerns/plans?
> 
> Yup, that would be helpful  - bits I know of are that Knot has an
> implementation based on an earlier version (with a different label),
> and Petr says that it will be some time before they are able to update
> it; I've never touched Lua, if I get a chance I might try patch their
> implementation with the new strings ("Hold my beer" / "How hard can it
> be?")).
> I think I heard that ISC was considering adding support, but was
> planning on waiting till RFC / some sort of LC.
> 

NLnet Labs is planning to add kskroll-sentinel support soon.  We will report 
progress and feedback to the authors of the kskroll-sentinel draft.

Code will be made available in our repository and asap be part of the Unbound 
release (for packaging & distribution).

Cheers,

— Benno


-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-07 Thread Evan Hunt
On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote:
> I think I heard that ISC was considering adding support, but was
> planning on waiting till RFC / some sort of LC.

Yes. The work in progress is available here:
https://gitlab.isc.org/isc-projects/bind9/merge_requests/123

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Warren Kumari
On Fri, Apr 6, 2018 at 5:49 PM, Suzanne Woolf  wrote:
> Hi,
>
> Thanks all for vigorous discussion, but I think it would be helpful to 
> separate comments on draft-ietf-dnsop-kskroll-sentinel from general comments 
> on WG guidelines for future documents.
>

Yup, I fully agree -- these have become conflated. (This drove the
irritated tone of my prior email.)

>> On Apr 6, 2018, at 9:45 AM, Job Snijders  wrote:
>>
>>
>> On Fri, Apr 06, 2018 at 08:37:15AM -0400, Warren Kumari wrote:
>>> I'm (of course) fine if the WG / chairs decide that DNSOP needs
>>> implementations before progressing documents, but your wording makes
>>> it sound like you believe this this is already the case, and not
>>> simply your (strong) preference.
>>
>> I am aware DNSOP does not have a policy of requiring implementations,
>> and I find this lack of policy regrettable. I believe this document is
>> not ready for WGLC, for the reasons I listed.
>
> The fact that we don’t have a rule about all documents doesn’t mean an issue 
> can’t be raised about a specific document.

Yup, and they have been raised about this document.

>
> While it’s often disappointing to editors when the WG raises significant 
> issues in WGLC, that’s kind of what WGLC is for.
>
> We’re hearing that having an RFC will be helpful to promoting implementation, 
> and also that this draft may not be ready to be advanced for publication 
> because it doesn’t include implementation experience.

Yeah, it is disappointing, but the authors are big boys and girls, and
after sobbing into our pillows for a little bit we'll be okay... :P

It seems to me that there is a fairly strong signal from the WG for
*this* document should have an implementation section -- speaking only
for myself, this seems like a reasonable request.

Again, for *this* document I understand that the WG wants an
implementation section, and so we should add one - I'm not sure we'd
be able to have that done by April 19th, and so I'm not sure if the
chairs want to consider pausing the WGLC.

> This is something the WG needs to comment on further, because it seems 
> substantive to me so it will have to be addressed one way or another before 
> we advance the document— but those inputs are somewhat in disagreement.
>
> Editors: Please take “concern about a description of current implementation 
> status” as WGLC input, and consider what you might be able to add to the 
> draft to address it.
>
> WG vendors/implementers: Can folks who have implemented kskroll-sentinel, or 
> considered implementing it, please speak up on your concerns/plans?

Yup, that would be helpful  - bits I know of are that Knot has an
implementation based on an earlier version (with a different label),
and Petr says that it will be some time before they are able to update
it; I've never touched Lua, if I get a chance I might try patch their
implementation with the new strings ("Hold my beer" / "How hard can it
be?")).
I think I heard that ISC was considering adding support, but was
planning on waiting till RFC / some sort of LC.

On the "other" side of this there are a few "client" implementations
-- the infamous ksk-test.net, Ray Bellis has
http://www.bellis.me.uk/sentinel/, and Paul Hoffman also has code
(which I have embarrassingly misplaced).

Once we have more details, these could be folded into the
implementation section...

W

>
>
> Thanks,
> Suzanne ()
>
>



-- 
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] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Suzanne Woolf
Hi,

Thanks all for vigorous discussion, but I think it would be helpful to separate 
comments on draft-ietf-dnsop-kskroll-sentinel from general comments on WG 
guidelines for future documents. 

> On Apr 6, 2018, at 9:45 AM, Job Snijders  wrote:
> 
> 
> On Fri, Apr 06, 2018 at 08:37:15AM -0400, Warren Kumari wrote:
>> I'm (of course) fine if the WG / chairs decide that DNSOP needs
>> implementations before progressing documents, but your wording makes
>> it sound like you believe this this is already the case, and not
>> simply your (strong) preference.
> 
> I am aware DNSOP does not have a policy of requiring implementations,
> and I find this lack of policy regrettable. I believe this document is
> not ready for WGLC, for the reasons I listed.

The fact that we don’t have a rule about all documents doesn’t mean an issue 
can’t be raised about a specific document.

While it’s often disappointing to editors when the WG raises significant issues 
in WGLC, that’s kind of what WGLC is for.

We’re hearing that having an RFC will be helpful to promoting implementation, 
and also that this draft may not be ready to be advanced for publication 
because it doesn’t include implementation experience. This is something the WG 
needs to comment on further, because it seems substantive to me so it will have 
to be addressed one way or another before we advance the document— but those 
inputs are somewhat in disagreement.

Editors: Please take “concern about a description of current implementation 
status” as WGLC input, and consider what you might be able to add to the draft 
to address it. 

WG vendors/implementers: Can folks who have implemented kskroll-sentinel, or 
considered implementing it, please speak up on your concerns/plans?


Thanks,
Suzanne ()


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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Joe Abley
On Apr 6, 2018, at 14:43, 神明達哉  wrote:

> At Thu, 05 Apr 2018 17:15:47 +,
> Job Snijders  wrote:
>
>> While the chair notes awareness of the point I raised, I’d like the be
>> explicit to avoid any confusion.
>>
>> This document is *not* ready for publication. There is no implementation
>> report available for review and consideration.
>
> (After reading other messages in this thread) I tend to agree.  Even
> after careful reviews of protocol text, an attempt of actually
> implementing it often reveals non-negligible issues that were
> overlooked in the review.

I think it's perhaps worth looking at this from the implementation
perspective, yes.

I don't doubt that we can expect close collaboration and testing
between APNIC Labs and the various resolver implementors, especially
given the experience with 8145.

If I'm right about that, it seems to me that (a) delaying the last
call to allow any unexpected issues with the specification to be
documented and (b) including details of the testing/compliance
criteria in the document for the benefit of future implementations are
both good ideas.

In other words, don't think of this as a constraint on publication but
rather an opportunity to make the document better without holding up
implementation.


Joe

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread 神明達哉
At Thu, 05 Apr 2018 17:15:47 +,
Job Snijders  wrote:

> While the chair notes awareness of the point I raised, I’d like the be
> explicit to avoid any confusion.
>
> This document is *not* ready for publication. There is no implementation
> report available for review and consideration.

(After reading other messages in this thread) I tend to agree.  Even
after careful reviews of protocol text, an attempt of actually
implementing it often reveals non-negligible issues that were
overlooked in the review.  Of course, it's a different question
whether dnsop adopts the requirement as a general rule for any
documents (although I would support the idea personally), at least in
this particular case I think it makes sense because:
- right now there's no known implementation of the latest version of
  the draft
- there seems to be some reasonable expectation that Knot will support
  the latest version not far from now
So it makes sense to me to hold off at least until Knot (or any other
implementation) actually adds
support for it or a sufficient amount of time (a couple of weeks?)
elapses without a news.  In the latter case we might discuss whether
we should make a compromise to move forward at that point.

--
JINMEI, Tatuya

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Joe Abley
On Apr 6, 2018, at 09:45, Job Snijders  wrote:

> While you are right that it is useful to define what is required for
> what sort of document, but I'd like to observe that at this moment, we
> are looking at a draft with 0 (zero, null, nada) implementations*, and
> also no implementation report draft which stipulates what should be
> tested. So your specific question is perhaps somewhat moot. Whatever the
> answer is, it will be larger than zero.

I feel that I'm a reasonably pragmatic person and I am not generally
in favour of boiling the ocean when all we were asked for was an
ISO-standard cup of tea.

However, I think it's worth reflecting on what happens when we don't
have a firm grip on protocol compliance in related implementations --
we get the kind of confusion that resulted from RFC8145. Although that
confusion has numerous root causes, we know for a fact that
variability in implementation has contributed to the madness.

The purpose of this particular draft is to facilitate useful
measurements that will yield a clear signal. I don't imagine the
authors of the draft are any more eager to see a noisy signal than the
rest of us.

If we can make it easier for implementations to behave reliably and
predictably e.g. by specifying what compliance means, I regardless of
the formal requirements of the working group, perhaps we should.


Joe

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Job Snijders
Dear Warren,

On Fri, Apr 06, 2018 at 08:37:15AM -0400, Warren Kumari wrote:
> On Thu, Apr 5, 2018 at 1:15 PM, Job Snijders  wrote:
> > While the chair notes awareness of the point I raised, I’d like the
> > be explicit to avoid any confusion.
> >
> > This document is *not* ready for publication. There is no
> > implementation report available for review and consideration.
> 
> [with absolutely no hats]

The authors of draft-ietf-dnsop-kskroll-sentinel (combined) have at
least 40 years of IETF experience. As such I'm not hesitant to hold them
to the highest standards. Cowboy hats notwithstanding. The protocol
specification will be better for it, and the working group will gain
experience.

> I get that you believe that this is wrong, but DNSOP currently has no
> requirement for there to be an implementation report (nor for there to
> be any implementations). 

The working group chair asked for feedback from the working group:

tjw wrote:
"Please review the draft and offer relevant comments.  If this does
not seem appropriate please speak out. if someone feels the document
is *not* ready for publication, please speak out with your reasons."
(https://mailarchive.ietf.org/arch/msg/dnsop/TfW55JEhQOybvlFLcPjybU6ATVU)

Naturally, I did what was asked of me.

> The way to change this is by proposing that this change (done), having
> the discussion (ongoing) and then having the chairs declare consensus
> and that they will require this going forward. It would also be useful
> for there to be clarity about what exactly is required, and for what
> sort of documents (e.g how does one implement attrleaf? or SUDN?), and
> when this would go into effect.

While you are right that it is useful to define what is required for
what sort of document, but I'd like to observe that at this moment, we
are looking at a draft with 0 (zero, null, nada) implementations*, and
also no implementation report draft which stipulates what should be
tested. So your specific question is perhaps somewhat moot. Whatever the
answer is, it will be larger than zero.

[* Petr was kind enough to provide the working group with an update
on the progress of a knot implementation, he shared that knot is not
compatible with the draft-ietf-dnsop-kskroll-sentinel-07 specification
https://mailarchive.ietf.org/arch/msg/dnsop/ZJ9P7iXUfMoBEojCxVAsJTNs5_Y ]

> A number of people have told me that they wait until something becomes
> an RFC before being willing implement it (some of this may be because
> a significant number of adopted document have simply expired and not
> been published) - suddenly requiring implementations is a large
> change, and deciding it now and retroactively applying it to documents
> which were about cooked seems a little unreasonable. 

"Documents which were about cooked" ?!?! Is this some kind of special
pre-WGLC status? Perhaps the word we are looking for is 'undercooked'? :-)

I have trouble following the line of thought here. Perhaps you can share
your thought on why IDR doesn't seem troubled by these concerns? Companies that
apply "Won't implement until RFC"-policies risk staying behind on the
innovation curve. That is their choice.

I've not seen any attempt to retroactively apply common sense without
following proper process. The process to obsolete/deprecate published
RFCs is well known, and if someone chooses to write a deprecation draft
where the main reason is "lack of implementations" they are free to do
so?

IETF protocol specifications without implementations are worthless. The
IETF TOA lists the phrase "running code" five times. Section A.5 states:

"IETF Standards Track specifications are not considered to be
satisfactory standards until interoperable independent
implementations have been demonstrated. (This is the embodiment of
the "running code" slogan.)"
source: https://www6.ietf.org/tao.html

draft-ietf-dnsop-kskroll-sentinel-07 targets "Standards Track". The
current state of draft-ietf-dnsop-kskroll-sentinel and my understanding
of the IETF slogan "rough consensus and running code" are incompatible.

> I'd also note that this somewhat disenfranchises participants who a:
> don't code and / or b: don't work for a vendor.

I fail to see what disenfranchisement you are referring to. Can you
elaborate? You don't need to have code abilities to create a protocol
specifications, but you'll need to work with protocol implementers. I'd
like to keep the IETF process as inclusive as possible.

> I'm (of course) fine if the WG / chairs decide that DNSOP needs
> implementations before progressing documents, but your wording makes
> it sound like you believe this this is already the case, and not
> simply your (strong) preference.

I am aware DNSOP does not have a policy of requiring implementations,
and I find this lack of policy regrettable. I believe this document is
not ready for WGLC, for the reasons I listed.

Kind regards,

Job


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Warren Kumari
On Thu, Apr 5, 2018 at 1:15 PM, Job Snijders  wrote:
> Hi all,
>
> While the chair notes awareness of the point I raised, I’d like the be
> explicit to avoid any confusion.
>
> This document is *not* ready for publication. There is no implementation
> report available for review and consideration.
>

[with absolutely no hats]

I get that you believe that this is wrong, but DNSOP currently has no
requirement for there to be an implementation report (nor for there to
be any implementations). The way to change this is by proposing that
this change (done), having the discussion (ongoing) and then having
the chairs declare consensus and that they will require this going
forward. It would also be useful for there to be clarity about what
exactly is required, and for what sort of documents (e.g how does one
implement attrleaf? or SUDN?), and when this would go into effect.

A number of people have told me that they wait until something becomes
an RFC before being willing implement it (some of this may be because
a significant number of adopted document have simply expired and not
been published) - suddenly requiring implementations is a large
change, and deciding it now and retroactively applying it to documents
which were about cooked seems a little unreasonable. I'd also note
that this somewhat disenfranchises participants who a: don't code and
/ or b: don't work for a vendor.

I'm (of course) fine if the WG / chairs decide that DNSOP needs
implementations before progressing documents, but your wording makes
it sound like you believe this this is already the case, and not
simply your (strong) preference.


W


> Should the working group produce an implementation report and demonstrate
> multiple implementations before April 15th, I’d ofcourse be willing to
> reconsider my position.
>
> Kind regards,
>
> Job
>
> On Thu, 5 Apr 2018 at 18:36, tjw ietf  wrote:
>>
>>
>> After walking through the 168 emails on this draft in the inbox, I feel
>> we're ready to take this to WGLC.
>>
>> (We are aware of the two points raised my Job and Paul)
>>
>>
>> This starts a Working Group Last Call for:
>> draft-ietf-dnsop-kskroll-sentinel
>>
>> Current versions of the draft is available here:
>> https://datatracker.ietf..org/doc/draft-ietf-dnsop-kskroll-sentinel/
>>
>> The Current Intended Status of this document is: Proposed Standard
>>
>> In the brushing of the camel, the draft is focused on determining if
>> a particular root key has been loaded into resolvers.
>>
>> Please review the draft and offer relevant comments.
>> If this does not seem appropriate please speak out.
>> if someone feels the document is *not* ready for publication, please speak
>> out with your reasons.
>>
>> This starts a two week Working Group Last Call process, and ends on:
>> 23:59 19 April 2018
>>
>> thanks
>> tim
>>
>> ___
>> 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
>



-- 
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] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Job Snijders
On Fri, 6 Apr 2018 at 14:01, Petr Špaček  wrote:

> On 6.4.2018 13:18, Peter van Dijk wrote:
> > On 5 Apr 2018, at 18:35, tjw ietf wrote:
> >
> >> After walking through the 168 emails on this draft in the inbox, I feel
> >> we're ready to take this to WGLC.
> >>
> >> (We are aware of the two points raised my Job and Paul)
> >
> > Especially given that an implementation is in fact available (in Knot),
> > why not take this opportunity to start demanding Implementation Status
> > sections for those drafts where that requirement makes sense? Because it
> > certainly makes sense here!
>
> Please note that we did not update Knot Resolver to comply with latest
> version of the draft *yet*. This is likely to happen over next couple
> weeks, not sooner. We have hands full with other tasks at the moment.
>
> Of course patches to
>
> https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/modules/ta_sentinel/ta_sentinel.lua
> are more than welcome!
>
>
> Speaking of Joes comment, it makes sense to me. AFAIK other resolvers
> are going to implement this anyway so there is no point in rushing the
> RFC out and setting it in stone before it gets implemented at least twice..



My grandmother used to tell me you can’t build a stable chair with just two
legs. Three is the minimum. Or perhaps four:
https://commons.wikimedia.org/wiki/File:BrokenChair.jpg

Kind regards,

Job

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Petr Špaček
On 6.4.2018 13:18, Peter van Dijk wrote:
> On 5 Apr 2018, at 18:35, tjw ietf wrote:
> 
>> After walking through the 168 emails on this draft in the inbox, I feel
>> we're ready to take this to WGLC.
>>
>> (We are aware of the two points raised my Job and Paul)
> 
> Especially given that an implementation is in fact available (in Knot),
> why not take this opportunity to start demanding Implementation Status
> sections for those drafts where that requirement makes sense? Because it
> certainly makes sense here!

Please note that we did not update Knot Resolver to comply with latest
version of the draft *yet*. This is likely to happen over next couple
weeks, not sooner. We have hands full with other tasks at the moment.

Of course patches to
https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/modules/ta_sentinel/ta_sentinel.lua
are more than welcome!


Speaking of Joes comment, it makes sense to me. AFAIK other resolvers
are going to implement this anyway so there is no point in rushing the
RFC out and setting it in stone before it gets implemented at least twice.

-- 
Petr Špaček  @  CZ.NIC

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-06 Thread Peter van Dijk

On 5 Apr 2018, at 18:35, tjw ietf wrote:

After walking through the 168 emails on this draft in the inbox, I 
feel

we're ready to take this to WGLC.

(We are aware of the two points raised my Job and Paul)


Especially given that an implementation is in fact available (in Knot), 
why not take this opportunity to start demanding Implementation Status 
sections for those drafts where that requirement makes sense? Because it 
certainly makes sense here!


Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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


Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-05 Thread tjw ietf
Thanks Job for keeping *me* straight.

Tim

On Thu, Apr 5, 2018 at 1:15 PM, Job Snijders  wrote:

> Hi all,
>
> While the chair notes awareness of the point I raised, I’d like the be
> explicit to avoid any confusion.
>
> This document is *not* ready for publication. There is no implementation
> report available for review and consideration.
>
> Should the working group produce an implementation report and demonstrate
> multiple implementations before April 15th, I’d ofcourse be willing to
> reconsider my position.
>
> Kind regards,
>
> Job
>
> On Thu, 5 Apr 2018 at 18:36, tjw ietf  wrote:
>
>>
>> After walking through the 168 emails on this draft in the inbox, I feel
>> we're ready to take this to WGLC.
>>
>> (We are aware of the two points raised my Job and Paul)
>>
>>
>> This starts a Working Group Last Call for:  draft-ietf-dnsop-kskroll-
>> sentinel
>>
>> Current versions of the draft is available here:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>>
>> The Current Intended Status of this document is: Proposed Standard
>>
>> In the brushing of the camel, the draft is focused on determining if
>> a particular root key has been loaded into resolvers.
>>
>> Please review the draft and offer relevant comments.
>> If this does not seem appropriate please speak out.
>> if someone feels the document is *not* ready for publication, please
>> speak out with your reasons.
>>
>> This starts a two week Working Group Last Call process, and ends on:
>>  23:59 19 April 2018
>>
>> thanks
>> tim
>>
>> ___
>> 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] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-05 Thread Job Snijders
Hi all,

While the chair notes awareness of the point I raised, I’d like the be
explicit to avoid any confusion.

This document is *not* ready for publication. There is no implementation
report available for review and consideration.

Should the working group produce an implementation report and demonstrate
multiple implementations before April 15th, I’d ofcourse be willing to
reconsider my position.

Kind regards,

Job

On Thu, 5 Apr 2018 at 18:36, tjw ietf  wrote:

>
> After walking through the 168 emails on this draft in the inbox, I feel
> we're ready to take this to WGLC.
>
> (We are aware of the two points raised my Job and Paul)
>
>
> This starts a Working Group Last Call for:
>  draft-ietf-dnsop-kskroll-sentinel
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>
> The Current Intended Status of this document is: Proposed Standard
>
> In the brushing of the camel, the draft is focused on determining if
> a particular root key has been loaded into resolvers.
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> if someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:
>  23:59 19 April 2018
>
> thanks
> tim
>
> ___
> 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