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 rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-12-15
Requested 2014-11-27
Draft 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
Review review-ietf-ianaplan-icg-response-06-secdir-lc-turner-2014-12-18
Reviewed rev. 06 (document currently at 10)
Review result Has Nits
Review completed: 2014-12-18

Review
review-ietf-ianaplan-icg-response-06-secdir-lc-turner-2014-12-18

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