Subject: [Gen-art] Genart Telechat review draft-ietf-eppext-keyrelay-11

From: Robert Sparks <[email-masked]>
Date: Mon, 14 Dec 2015 13:37:28 -0600

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-eppext-keyrelay-11
Reviewer: Robert Sparks
Review Date: 14Dec2015
IETF LC End Date: 4Dec2015
IESG Telechat date: 17Dec2015

Summary: (Still) ready for publication as Proposed Standard

Thanks for addressing most of my nits.

I think it's a problem (not for this document, but for the overall work) 
that draft-koch-dnsop-operator-change isn't moving forward. I think the 
group should spend energy on how to capture what it was saying.

I also still think you would have a stronger document if it discussed 
the SHOULD NOT in the security section as I suggest below. I think you 
read that to be me suggesting you change it to MUST NOT. That was not 
the intent. I was asking you to add to the document _why_ it wasn't MUST 
NOT.

On 11/25/15 3:45 PM, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-eppext-keyrelay-10
> Reviewer: Robert Sparks
> Review Date: 25Nov2015
> IETF LC End Date: 4Dec2015
> IESG Telechat date: (not yet scheduled)
>
> Summary: Ready for publication as Proposed Standard with nits
>
> This is a small nit, but please consider changing the document to 
> address it. The motivation for this extension leans on improving the 
> security of transferring information between registrars. It should be 
> recast as providing better automation and reliability instead. In 
> practice (and I think in specification), it hinges on passing a 
> password from the registrar of record to the gaining registrar through 
> some unspecified means (though typically through the registrant). That 
> password is required to be placed in the create by the gaining 
> registrar as specified in this document in order for that create to 
> succeed at the registry. While it would be impractical and 
> error-prone, the same channel that was used to hand this password 
> around _could_ be used to pass the keying material this extension 
> addresses.
>
> Reading draft-koch-dnsop-operator-change (an informational reference 
> currently) helped greatly with understanding this document. That draft 
> expired in 2014. Please be sure it advances, and consider making it a 
> normative reference.
> If it is not going to move forward, consider pulling some of the 
> transfer mechanic recommendations and the definitions of 
> losing/gaining entities into this draft, unless they've already made 
> it into the RFC series somewhere else?
>
> The security considerations document says a server SHOULD NOT perform 
> any transformation on data under server management when processing a 
> <keyrelay:create> command. Can this point to more detailed discussion 
> somewhere? Why is this not a MUST NOT? (What are the conditions where 
> violating the SHOULD NOT is the right thing to do? What are the risks 
> a server takes if it performs such a transformation?)
>
> Micro-nit : In section 2.1 where you say "The <expiry> element MUST 
> contain one of the following", consider saying "The <expiry> element 
> MUST contain exactly one of the following".
>
> RjS
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Dec 2015 11:19:19 +0000

Document: draft-ietf-p2psip-diagnostics-19
Reviewer: Alexey Melnikov
Review Date: 2015-12-15
IETF LC End Date:
IESG Telechat date: 2015-12-17

Summary: Nearly ready for publication as Proposed Standard

I think this document has a list of issues, but they should be easy to fix:

In Section 5.3:

The dMFlags field described above is a 64 bit field that allows
   initiator nodes to identify up to 62 items of base information to
   request in a request message (the first and last flags being
   reserved).

But the IANA registration section uses flags 1 and doesn't seem to
reserve the highest bit either. If this text is now wrong, it should be
deleted. If the IANA section is wrong, please fix it. If I am wrong,
please tell me :-).

In Section 5.3:

SOFTWARE_VERSION: A single value element containing a US-ASCII
      string that identifies the manufacture, model, operating system
      information and the version of the software.  Given that there are
      very large number of peers in some networks, and no peer is likely
      to know all other peer’s software, this information may be very
      useful to help determine if the cause of certain groups of
      misbehaving peers is related to specific software versions.  While
      the format is peer-defined, a suggested format is as follows:
      "ApplicationProductToken (Platform; OS-or-CPU) VendorProductToken
      (VendorComment)".  For example: "MyReloadApp/1.0 (Unix; Linux
      x86_64) libreload-java/0.7.0 (Stonyfish Inc.)".  The string is a
      C-style string, and MUST be delimited by "\0".

Did you mean "terminated"? I don't see what can be delimited, as this
implies presence of multiple fields.

      "\0" MUST NOT be
      included in the string itself to prevent confusion with the
      delimiter.

EWMA_BYTES_SENT (32 bits): A single value element containing an
      unsigned 32-bit integer representing an exponential weighted
      average of bytes sent per second by this peer. sent = alpha x
      sent_present + (1 - alpha) x sent where sent_present represents
      the bytes sent per second since the last calculation and sent
      represents the last calculation of bytes sent per second.  A
      suitable value for alpha is 0.8.  This value is calculated every
      five seconds.

I don't understand the formula. What is "x"?
Should the formula be on its own line for ease of understanding?

BATTERY_STATUS

This flag doesn't seem to be defined in a useful fashion. You need to at
least provide some guidance here to insure interoperability.

In Sections 9.3-9.5: is RFC-AAAA this document or RFC 6940 (or something
else)?

Thank you,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Dec 2015 12:23:39 +0000

I deleted an incorrect recipient in my original review. Sorry about that.

> On 15 Dec 2015, at 11:19, Alexey Melnikov <[email-masked]> wrote:
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Rik Ribbers <[email-masked]>
Date: Tue, 15 Dec 2015 19:20:29 +0000

Robert,

> 
> I also still think you would have a stronger document if it discussed the SHOULD NOT in the security section as I suggest below. I think you read that to be me suggesting you change it to MUST NOT. That was not the intent. I was asking you to add to the document _why_ it wasn't MUST NOT.

I’ll take that into consideration, as I have explained it in the response the wording isn’t that difficult anymore. There are some more IESG review comment on this section so I assume there will another version to before publication. 

Current wording:

A server SHOULD NOT perform any transformation on data under server management when processing a \<keyrelay:create\> command.

Proposed wording:

A server SHOULD NOT perform any transformation on data under server management when processing a \<keyrelay:create\> command. The intent of this command is to put DNSSEC key material on the poll queue of another client. To make sure that this EPP extension is interoperable with the different server policies that already have implemented EPP this extension it is not classified as must not.

Please let me know what you think of this proposal (or send in text ;-))

Gr,
Rik

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Dec 2015 08:51:43 +0200

Thanks for your review, Alexey!

Authors, what say you?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Dec 2015 14:51:02 +0200

Robert, thank you for your review(s), and Rik, thanks for the edits.
Your proposed wording below works for me.

Jari