Skip to main content

Last Call Review of draft-ietf-ianaplan-icg-response-06
review-ietf-ianaplan-icg-response-06-secdir-lc-turner-2014-12-18-00

Request Review of draft-ietf-ianaplan-icg-response
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-12-15
Requested 2014-11-27
Authors Eliot Lear , Russ Housley
I-D last updated 2014-12-18
Completed reviews Genart Last Call review of -06 by Christer Holmberg (diff)
Secdir Last Call review of -06 by Sean Turner (diff)
Opsdir Last Call review of -06 by Melinda Shore (diff)
Assignment Reviewer Sean Turner
State Completed
Request Last Call review on draft-ietf-ianaplan-icg-response by Security Area Directorate Assigned
Reviewed revision 06 (document currently at 10)
Result Has nits
Completed 2014-12-18
review-ietf-ianaplan-icg-response-06-secdir-lc-turner-2014-12-18-00
And I managed to leave secdir off as a recipient.

spt

Begin forwarded message:

> From: Sean Turner <turners at ieca.com>
> Subject: secdir review of draft-ietf-ianaplan-icg-response-06
> Date: December 13, 2014 at 10:25:49 EST
> To: draft-ietf-ianaplan-icg-response at tools.ietf.org, The IESG <iesg at
ietf.org>, ietf at ietf.org > > Do not be alarmed.  I have reviewed this
document as part of the security > directorate’s ongoing effort to review all
IETF documents being > processed by the IESG.  These comments were written with
the intent > of improving security requirements and considerations in IETF
drafts. > Comments 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. > > Summary: No security or
privacy issues that I can see, but I do have > a couple of nits. > > 0)
General: > > I guess it wasn’t clear to me that the response will take on the
form of the > RFC or if the text not proceeded by “>>>” in the main body will
be returned > in some of other form. > > 1) Sec 1: > > There’s a pointer to
ICG’s charter and the RFP shouldn’t we also have a > pointer to the NTIA
announcement: > >

http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions

>
> 2) Abstract contains:
>
>   The IETF community is invited to
>   comment and propose changes to this document.
>
> I guess this makes it crystal clear that folks could comment on the draft,
> but this sentence should be struck before going to the RFC editor.
>
> 3) Sec I (section #s refer to RFP sections): Missing word
>
> Missing “the”?  r/on iana.org/on the iana.org
>
>   The IETF
>   community presently accesses the protocol parameter registries via
>   references based on iana.org domain name, and makes use of the term
>   "IANA" in the protocol parameter registry processes [RFC5226].
>
> 4) Sec I: missing “.” at the end of the sentence:
>
>>>> A description of any overlaps or interdependencies between your
>>>> IANA requirements and the functions required by other customer
>>>> communities
>
> 5) Sec I: Overlap
>
> I assume the overlap here is with the other two communities listed in
> this RFP (i.e., names & numbers) and not the IEEE or W3C?
>
> 6) Sec I: "RIR System"?
>
>      Through the IANA protocol
>      parameters registries, the IETF delegates unicast IP address and
>      AS number ranges to the RIR system [RFC7020],[RFC7249].
>
> I went and looked in RFCs 7020 and 7249 and could find no reference
> to an “RIR system” I found Internet Numbers Registry System was that
> what you’re referring to?
>
> 7) Sec I: Missing question/response?
>
> In addition to the four bullets there is also this paragraph in the RFP:
>
>   If your community relies on any other IANA service or activity
>   beyond the scope of the IANA functions contract, you may describe
>   them here. In this case please also describe how the service or
>   activity should be addressed by the transition plan.
>
> And because the intro of the RFP says:
>
>   The IANA Stewardship Transition Coordination Group (ICG) seeks
>   complete formal responses to this RFP through processes which are to
>   be convened …
>
> Don’t we need to include a response to this question even if the answer
> is “none” or “see above”?
>
> 8) Sec II.A: r/the/The & r/all/All
>
>   IETF Response: the protocol parameters registries.
>
>   IETF Response: all policy sources relating to the protocol parameters
>   registry are affected.
>
> 9) Sec IV: Missing question?
>
> The “Risks” paragraph in the RFP includes the following question:
>
>   Description of how long the proposals in Section III are expected to
>   take to complete, and any intermediate milestones that may occur
>   before they are completed.
>
> Does it need to be included along with the bullets in Sec IV?
>
> 10) Sec V: missing question/response:
>
> There are five bullets in sV this one is omitted:
>
>    o The proposal must not replace the NTIA role with a government-led
>      or an inter-governmental organization solution.
>
> Should we say something about our proposal not replacing
> NTIA with a government-y organizational solution?  I mean I know it’s
> obvious to you and me, but maybe being explicit here is better.
>
> 11) Sec VI: add IETF LC?
>
> I assume you’re going to add a link to the IETF LC and maybe the ballots
> to the end of the list of actions.
>
> 12) s3 (IANA Considerations)
>
> r/is a response a request for/is a response to a request for
>
> Cheers,
>
> spt