Subject: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05.txt

From: Patrik Fältström <[email-masked]>
Date: Mon, 26 Mar 2012 10:55:35 +0200

All,

First of all, please note the version number I want you to (re-)read. It is posted basically "now", but for the ones that want to check before it ends up in the repository, I have also attached a copy.

This version is, I think, answering all questions all individuals have had that I have managed to track. I have had private conversation with many of you that had comments after version -02, and your comments have been passed to the editors.

I already have enough individuals that have said they have read this draft and support it to be able to forward it towards the IESG, so this WGLC only have as a goal to ensure there are no more issues.

I would like to thank, among others, Miek Gieben, Mark Andrews, Marc Lampo, Bill Manning, Warren Kumari, Ed Lewis and Dick Franks for the review and suggested changes.

    Patrik

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Miek Gieben <[email-masked]>
Date: Mon, 26 Mar 2012 13:06:10 +0200

[ Quoting <[email-masked]> in "[dnsext] WGLC on draft-ietf-dnsext-..." ]
> All,
> 
> First of all, please note the version number I want you to (re-)read. It is
> posted basically "now", but for the ones that want to check before it ends up
> in the repository, I have also attached a copy.

Looks good to me.

One nit though:

> 3.2.  Validating Stub Resolvers
> 
>    A validating stub resolver already (usually) sets the DO bit
>    [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs
>    (i.e.  RRSIG RR's) in the response.  Such validating resolvers SHOULD
>    include the DAU, DHU and/or the N3U option(s) in the OPT RR when
>    sending a query.  This way thee validating stub resolver indicates
                                ^^^^
the

grtz Miek

---

From: Dick Franks <[email-masked]>
Date: Mon, 26 Mar 2012 15:14:33 +0100

Patrik,

Editorial nits

[1. para 4, line 7] revise wording

  ... determine when to stop signing with the old algorithm(s) when
the server sees ...

   ... determine when to stop signing with a superseded algorithm when the
server sees ...

[1. para 5, last line] revise wording

  ... can signal a set of algorithms and hashes it implements.

   ... client query can signal the set of algorithms and hashes which it
implements.

[2. para 1, line 6] spelling

   independly

    independently

[2. para 4] simplify wording

   LIST-LENGTH is the length of the list of digital signature or hash
   algorithms in octets.  Since each algorithm and hash codes are 1
   octet long so this value is the number of octets.

    LIST-LENGTH is the length of the list of digital signature or hash
algorithm codes.
    Each algorithm code occupies a single octet.

[2. para 5, line 3] revise wording

  ... that the client indicates as understood.

   ... that the client declares to be supported.

[2. para 6, last line] delete redundant words

   ... in a reasonable potential future example.

    The reasonableness of the example is a matter of taste, flavoured by
uncertain numbers.

[3.1. line 3] simplify wording

   ... depends on whether the stub resolver performs its own
   DNSSEC validation or doesn't perform its own validation.

    ... depends on whether the stub resolver elects to perform its own
DNSSEC validation.

[3.2. line 5] key bounce

   This way thee validating ...

[3.2. line 7] revise wording

   ... order of preference, with the most preferred algorithm(s) first ...

    ... order of preference, with the most preferred algorithm first ...

    This is describing the ordering direction of each (singular) list;
first element is singular.

[6. para 1, line 6] fix garbled wording

   This monitoring can be used to measure the deployment of client code
   that implements (and signals) certain algorithms.  The Exactly how to
   capture DNS traffic and measure new algorithm adoption is beyond the
   scope of this document.

    This monitoring can be used to measure the deployment of client code
    that implements (and signals) specific algorithms. Description of the
    techniques used to capture DNS traffic and measure new algorithm
    adoption is beyond the scope of this document.

[6. para 2, line 9]

   ... until a large majority of clients signal that they understand
the new algorithm.

    ... until a large majority of clients signal that they recognise the
new algorithm.

--Dick

2012/3/26 Patrik Fältström <[email-masked]>

> All,
>
> First of all, please note the version number I want you to (re-)read. It
> is posted basically "now", but for the ones that want to check before it
> ends up in the repository, I have also attached a copy.
>
> This version is, I think, answering all questions all individuals have had
> that I have managed to track. I have had private conversation with many of
> you that had comments after version -02, and your comments have been passed
> to the editors.
>
> I already have enough individuals that have said they have read this draft
> and support it to be able to forward it towards the IESG, so this WGLC only
> have as a goal to ensure there are no more issues.
>
> I would like to thank, among others, Miek Gieben, Mark Andrews, Marc
> Lampo, Bill Manning, Warren Kumari, Ed Lewis and Dick Franks for the review
> and suggested changes.
>
>    Patrik
>
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Mar 2012 10:15:06 +1100

In message <[email-masked]>, =?iso-8859-1?Q?Pa
trik_F=E4ltstr=F6m?= writes:
> All,
> 
> First of all, please note the version number I want you to (re-)read. It =
> is posted basically "now", but for the ones that want to check before it =
> This version is, I think, answering all questions all individuals have =
> had that I have managed to track. I have had private conversation with =
> many of you that had comments after version -02, and your comments have =
> been passed to the editors.
> 
> I already have enough individuals that have said they have read this =
> draft and support it to be able to forward it towards the IESG, so this =
> WGLC only have as a goal to ensure there are no more issues.
> 
> I would like to thank, among others, Miek Gieben, Mark Andrews, Marc =
> Lampo, Bill Manning, Warren Kumari, Ed Lewis and Dick Franks for the =
> review and suggested changes.
> 
>     Patrik

Patrik,
	The draft really should explictly state whether a server can
use this information to filter RRSIG records or not.  This need to be
a MAY or a MUST NOT.  As currently written I would say this needs to
be a MUST NOT.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext