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

[Dick Franks <[e-mail]>]

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 <[e-mail]>

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>
>

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