Subject: [Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-lta-use-cases-05: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Mon, 29 Apr 2019 20:59:49 -0700

Adam Roach has entered the following ballot position for
draft-ietf-sidrops-lta-use-cases-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this document. I have two minor editorial suggestions.

---------------------------------------------------------------------------

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - RPKI
 - LIR
 - PI
 - RIR
 - CA

---------------------------------------------------------------------------

ID Nits reports:

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords.

     RFC 2119 keyword, line 177: '...eds.  Hence they MUST be implemented t...'

Please consider adding the boilerplate specified in RFC 8174.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Apr 2019 09:36:17 -0400

> Please consider adding the boilerplate specified in RFC 8174.

Or, alternatively (and my preference), re-word that brief paragraph in
the Security Considerations so that it doesn't use "MUST".  I find
"Hence they MUST be implemented to assure the local constraint." hard
to understand anyway, so re-wording might help.

Barry

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Apr 2019 09:24:30 -0700

> to understand anyway, so re-wording might help.

as mirja kühlewind pointed out, that paragraph was a bungle.  how about

6.  Security Considerations

   Though the above use cases are all constrained to local contexts,
   they violate the model of a single Global RPKI, albeit to meet real
   operational needs.  Hence the result must be able to be validated as
   if the changed data were part of the validatable Global RPKI while
   including the local context, perhaps with the addition of trust
   anchors or authenticatable patching of trust.

   Modification 'recipes' may lack authentication.  E.g., if
   modifications to the tree are passed around a la SLURM files, see
   [RFC8416], what was object security becomes, at best, transport
   security, or authentication by other trust domains such as PGP.

randy

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Apr 2019 11:27:24 -0500

This seems like an even better resolution to the problem. Thanks, Randy.

/a

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Apr 2019 09:30:26 -0700

> see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

i think i will leave that to the rfced, as it blows line length in the
xml2rfc i run

rest ok

randy