[ - IETF@ for clutter] On Fri, Sep 6, 2019 at 12:15 PM Carlos Pignataro (cpignata) <cpign...@cisco.com> wrote: > > Many thanks for following up, Roger. Ack on all your responses below!
I wanted to quickly thank Carlos, and the authors for discussing and working through these issues - it's great when OpsDir is able to provide useful, substantive improvements to documents like this. Thanks all, W > > — Carlos. > > On Sep 6, 2019, at 10:48 AM, Roger D Carney <rcar...@godaddy.com> wrote: > > Good Morning, > > Thank you for your comments Carlos, please see my responses below. A new > version of the draft will be published shortly and will address all of the > review comments that needed edits. > > > Thanks > Roger > > > -----Original Message----- > From: Carlos Pignataro via Datatracker <nore...@ietf.org> > Sent: Wednesday, July 3, 2019 2:51 AM > To: ops-...@ietf.org > Cc: i...@ietf.org; draft-ietf-regext-epp-fees....@ietf.org; regext@ietf.org > Subject: Opsdir last call review of draft-ietf-regext-epp-fees-16 > > Notice: This email is from an external sender. > > > > Reviewer: Carlos Pignataro > Review result: Has Nits > > Reviewer: Carlos Pignataro > Review Result: Has Nits > > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the operational > aspects of the IETF drafts. Comments that are not addressed in last call may > be included in AD reviews during the IESG review. Document editors and WG > chairs should treat these comments just like any other last call comments. > > I hope these comments are useful and clear. > > >From an operational point of view, the document describes protocol > >interactions > for dealing with failure conditions, and sets default behaviors. For example, > the RFC 2119 language explaining the use of <fee:currency> is super useful. > > Minor comments, questions, and nits for your consideration follow: > > 1. Section 2 -- Migrating to Newer Versions of This Extension > > (Note to RFC Editor: remove this section before publication as an > RFC.) > > Since forward compatibility is a key operational consideration, why should > this section be removed? Especially when it contains RFC 2119 language. > > [RDC] Agree, Note will be removed. > > 2. Please do not treat as a pedantic comment, but I did not see an actual > definition for what "fee" and "credit" mean. Since these words have specific > context, it might not hurt to have a formal definition in Section 1.1 > > [RDC] Added clarifying text to section 3.4 “A fee will result in subtracting > from the Account Balance (described section 3.5) and a credit will result in > adding to the Account Balance (described in section 3.5).” > > 3. Should the citation / reference for "ISO 4217" be "ISO 4217:2015"? > > [RDC] Text updated. > > 4. S3.4. Does this text imply there is no zero fee or credit possible? Might > be useful to explicitly set guidance for the use of 0/null fee/credit. > > A <fee:fee> element MUST > have a non-negative value. A <fee:credit> element MUST have a > negative value. > > [RDC] This was discussed in another email but for completeness, this does > state fee can be zero (a non-negative value). > > 5. S3.6, why "equal to" and not only "exceed"? > > A server MAY reject certain > transactions if the absolute value of the <fee:balance> is equal to > or exceeds the value of the <fee:creditLimit> element. > > [RDC] This allows server policy flexibility, allows a server to deny a > transaction when the limit is reached or exceeded. > > 6. Section 6.1 > > * Should <CODE BEGINS> and <CODE ENDS> markers be used as per the TLP? > * Should the (c) year be 2019? > * And should the BSD License be part of the code? > > [RDC] BEGIN/END is the standard that has been used in EPP RFCs. The copyright > information in this section has been removed.. > > 7. Section 7, Security Considerations. > > What are "security services"? Further, this protocol deals with on-the-wire > monetary information. I suspect there might be specific such considerations. > > [RDC] “Security Services” are any related security features/functions. > “on-the-wire” monetary information has been addressed through secdir > comments, an additional line of text for clarity was added. > > 8. Section 9. Implementation Status > > If this section is removed, the reference to [RFC7942] would result hanging > without citations to it. ALthough the RFC Editor would catch, might want to > indicate removal of the Normative Reference as well. > > [RDC] The removal text also states to remove the reference. > > Thanks! > > Carlos Pignataro. > > > _______________________________________________ > OPS-DIR mailing list > ops-...@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir -- 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
