[DNSOP] Fwd: Re: *[AD] Fwd: AUTH48 [LB]: RFC 7873 <draft-ietf-dnsop-cookies-10.txt> NOW AVAILABLE

[joel jaeggli <[e-mail]>]

FYI

draft-ietf-dnsop-cookies

now normatively includes RFC 7120

Thanks
joel


-------- Forwarded Message --------
Subject: Re: *[AD] Fwd: AUTH48 [LB]: RFC 7873
<draft-ietf-dnsop-cookies-10.txt> NOW AVAILABLE
Date: Tue, 17 May 2016 08:25:46 -0700
From: joel jaeggli <[e-mail]>
To: Lynne Bartholomew <[e-mail]>
CC: RFC Editor <[e-mail]>

On 5/16/16 5:00 PM, Lynne Bartholomew wrote:
> Dear Joel,
> 
> Forwarding this email directly to you.
> 
> Thank you.
> 
> RFC Editor/lb
> 
> Begin forwarded message:
> 
>> *From: *[e-mail] <mailto:[e-mail]>
>> *Subject: **[AD] Re: AUTH48 [LB]: RFC 7873
>> <draft-ietf-dnsop-cookies-10.txt> NOW AVAILABLE*
>> *Date: *May 16, 2016 at 3:27:43 PM PDT
>> *To: *[e-mail] <mailto:[e-mail]>, [e-mail]
>> <mailto:[e-mail]>
>> *Cc: *[e-mail] <mailto:[e-mail]>,
>> [e-mail] <mailto:[e-mail]>, [e-mail]
>> <mailto:[e-mail]>, [e-mail]
>> <mailto:[e-mail]>
>>
>> Authors, AD*,
>>
>> *Joel, please reply regarding #1.
>>
>> 1) [AD] Per author feedback earlier in the process, RFC 7120 is now
>> cited in Section 8 and listed it as a Normative Reference.  Please let
>> us know if you approve.
>>
>> Original:
>> IANA has assigned the following DNS error code as an early
>> allocation:
>>
>> Changed to:
>> IANA has assigned the following DNS error code as an early allocation
>> per [RFC7120]:
>> ...
>> [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
>>            Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120,
>>            January 2014,
>>            <http://www.rfc-editor.org/info/rfc7120>.

this is fine I approve, I am informing the working group.

>>
>> 2) We changed instances of "HMAC-SHA256" to "HMAC-SHA-256" (and
>> "HMAC-SHA1" to "HMAC-SHA-1") to match [RFC6234], which is cited.
>> However, the document also uses "HMAC-SHA256-64", which matches the
>> IANA-registered description from RFC 6696. Please review whether the
>> current text -- with this apparent inconsistency (hyphen vs. no hyphen
>> after "SHA") -- is correct.

So I'm hardly and informed reference on these things however; SHA-1 is a
proper name whereas SHA256/SHA-256 is a concatentation of (SHA + (the
number of key bits)) .

rfc 4291 seperates them with dashes.

https://tools.ietf.org/html/rfc4231

6696s convention is

         This field indicates the integrity algorithm used
         for ERP.  Key lengths and output lengths are either indicated
         or are obvious from the cryptosuite name.

	e.g.

	HMAC-SHA256-64

that's fine since it's now written in stone but it's not necessary to
indicate the output length  most of the time...

If you're using the iana description then by all means proceed.



>>
>> 3) Please let us know if any changes are needed for the following
>> items, which are about terminology across the Cluster 284 of
>> documents, which includes these documents in addition to RFC-to-be 7873.
>>
>>  RFC 7828 (draft-ietf-dnsop-edns-tcp-keepalive)
>>  draft-ietf-dprive-dns-over-tls (RFC-to-be 7858) in AUTH48-DONE
>>  draft-ietf-dnsop-edns-chain-query in EDIT*R
>>  draft-ietf-dane-openpgpkey in EDIT*R
>>
>> a) The following terms were used inconsistently in this cluster of
>> documents. We have updated the document to use the forms on the right.  
>> Please let us know any objections.
>>
>> Resolver / resolver*
>> Recursive Resolver / recursive resolver*

no objection

>> * Per more common usage in recently published RFCs
>>
>> b) The following terms are used inconsistently in this cluster of
>> documents.  Please let us know which form is preferred.
>>
>> answer section / Answer Section**
>> querying / QUERYing

5.4 QUERYing for a Server Cookie

gives me pain. yes QUERY is the opcode; Querying is what is being done.

Answer Section is probably fine

I assume that probably comes from rfc 1035 (upper case answer) though
that uses it exclusively lower case (10 times)

4.1. Format

All communications inside of the domain protocol are carried in a single
format called a message.  The top level format of message is divided
into 5 sections (some of which are empty in certain cases) shown below:

    +---------------------+
    |        Header      			|
    +---------------------+
    |       Question      			| the question for the name server
    +---------------------+
    |        Answer       			| RRs answering the question
    +---------------------+
    |      Authority     			| RRs pointing toward an authority
    +---------------------+
    |      Additional     			| RRs holding additional information
    +---------------------+

>> ** Usage in recent RFCs is mixed.  FYI that we see "question section"
>>   used in this cluster of documents.
>>
>> Thank you.
>> RFC Editor/lb/ar
>>
>> On May 16, 2016, [e-mail]
>> <mailto:[e-mail]> wrote:
>>
>> *****IMPORTANT*****
>>
>> Updated 2016/05/16
>>
>> RFC Author(s):
>> --------------
>>
>> Instructions for Completing AUTH48
>>
>> This is your last chance to make changes to your RFC-to-be:
>> draft-ietf-dnsop-cookies-10.txt.
>> Once the document is published as an RFC, we will not make changes.
>> Please follow the instructions below to complete the AUTH48 process.
>> (For frequently asked questions, please see
>> https://www.rfc-editor.org/faq/#auth48.)
>>
>> 1) Review the edited document completely.  The files are available here:
>>
>>  https://www.rfc-editor.org/authors/rfc7873.txt
>>  https://www.rfc-editor.org/authors/rfc7873-diff.html
>>
>>  We recommend reviewing the entire document, not just the diff file.
>>  FYI, https://tools.ietf.org/rfcdiff provides tools to make various
>>  kinds of diff files.
>>
>> 2) Review and resolve (as necessary) any questions raised by the RFC
>> Editor.
>>  The questions (if any) will be sent in a subsequent AUTH48 email.
>>
>> 3) Send us your changes or respond with your approval for publication.  
>>  Please use 'REPLY ALL' so that [e-mail]
>> <mailto:[e-mail]> and the parties
>>  CC'ed on this message receive your response. Note that your document will
>>  not move forward until we have received approvals from each of the
>>  authors listed on the front page.
>>
>>  If sending changes, please provide us with an explicit list of changes
>>  via email. Please send the changes in this format:
>>
>>     Section # (or indicate Global)
>>
>>     OLD:
>>     old text
>>
>>     NEW:
>>     new text
>>
>>  Be sure to pay particular attention to these areas of the document:
>>  - IANA Considerations updates (if applicable)
>>  - Contact information
>>  - Copyright notice and legends (see item 6 for more details)
>>
>> 4) Send a list of suitable keywords for this document (beyond those
>>  that appear in the title) for use on https://www.rfc-editor.org/search
>>
>> 5) Review changes submitted by your coauthors (if any).  We assume that
>>  you will speak up if you do not agree with the proposed changes.
>>  That is, your silence is your assent to changes submitted by your
>>  coauthors. Note that any changes that are beyond editorial will be
>>  sent to the relevant body for approval.
>>
>> 6) Review the copyright notice and legends as defined in RFC 5378 and the
>>  Trust Legal Provisions (TLP -- https://trustee.ietf.org/license-info/).
>>
>>  If your document was approved for publication with a pre-RFC-5378
>>  copyright notice, we have applied the text from section 6.c.iii of the
>>  TLP.  Please consider whether this text is required (note that the
>>  6.c.iii text is not applicable to Alternate Stream RFCs).  See item
>>  4.5 of the "Copyright FAQ" at https://trustee.ietf.org/faq.html for
>>  guidance on whether this text applies to your document.
>>
>> 7) Please reply, as the document will not be published until we receive
>>  approvals from each author.  The details of the AUTH48 status of your
>>  document are here:
>>
>>  https://www.rfc-editor.org/auth48/rfc7873
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC7873 (draft-ietf-dnsop-cookies-10)
>> --------------------------------------
>> Title            : Domain Name System (DNS) Cookies
>> Author(s)        : D. Eastlake 3rd, M. Andrews
>> WG Chair(s)      : Suzanne Woolf, Tim Wicinski
>> Area Director(s) : Benoit Claise, Joel Jaeggli
>>
>