Re: secdir review of draft-ietf-ianaplan-icg-response-06

Eliot Lear <lear@cisco.com> Mon, 15 December 2014 08:53 UTC

Return-Path: <lear@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F581A1A30; Mon, 15 Dec 2014 00:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZy8ReN_dnpl; Mon, 15 Dec 2014 00:53:00 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B218C1A0179; Mon, 15 Dec 2014 00:52:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6720; q=dns/txt; s=iport; t=1418633580; x=1419843180; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=xmGKGUdORQGACo3ZQCstYqVQbLb4k5/hMzpP0mXOZ3Q=; b=YJ1UO5LD4zboO4KShwsxhncbQPwvBcR5NYbhjgrLvKA/27czyhY5X6zZ mk5wjJ2chZ7TV5bbZrMkJKq9ZnKj40rOiP/03JWyCCC7tMiLdaoyyo5k3 qaE+ubzlWILBhF4DxPy0sZqV5R8rKn8+JErtp1aPj1C9GlsM2Ek3i2Pk7 Y=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFADqhjlStJssW/2dsb2JhbABag1hYgwbCX4VuAoEtAQEBAQF9hAwBAQEDASNbCwkCGAkhAgIPAkYGAQwIAQEQB4gJCA2fG5xflXsBAQEBAQEBAwEBAQEBAQEbj3mCaIFBBYwsgyCBJ02FMYELMIIughCIBoM4IoNtPTABgkIBAQE
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="asc'?scan'208";a="270515145"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 15 Dec 2014 08:52:58 +0000
Received: from [10.61.68.177] (ams3-vpn-dhcp1201.cisco.com [10.61.68.177]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBF8qvVV001111; Mon, 15 Dec 2014 08:52:57 GMT
Message-ID: <548EA168.20702@cisco.com>
Date: Mon, 15 Dec 2014 09:52:56 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Sean Turner <turners@ieca.com>, draft-ietf-ianaplan-icg-response@tools.ietf.org, The IESG <iesg@ietf.org>, ietf@ietf.org
Subject: Re: secdir review of draft-ietf-ianaplan-icg-response-06
References: <7E631EA0-8577-4616-A885-331078D93115@ieca.com>
In-Reply-To: <7E631EA0-8577-4616-A885-331078D93115@ieca.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="J286nTVhmOLrscGbnaw0KJWVu49vT5OtQ"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Z8NdDx0eDY8LsGM-Ypaq9rpX9FY
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 08:53:02 -0000

Hi Sean,

Thank you for your review.

On 12/13/14, 4:25 PM, Sean Turner wrote:
> 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.

The intent is to respond to the ICG CFP with the exact wording as is
stated in the document approved by the IESG. The form of the document
will remain the same as you saw.

> 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

I have added this reference.

>
> 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.

This text has been struck.

>
> 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].

Yes thanks.
>
> 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

Thanks.

>
> 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?

Right.
>
> 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?

Changed to "RIRs".

>
> 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”?

I believe this is already sufficiently covered.  We have chosen not to
include activities beyond the scope of the contract, because they would
introduce elements that are not germane to the NTIA or the ICG.

>
> 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.

Corrected.

>
> 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.

We have answered this question in the same section by implication when
we wrote:

>  What is necessary as part of transition is the completion of
>   any supplemental agreement(s) necessary to achieve the requirements
>   outlined in our response in Section III of this RFP.

> 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.

I propose to add the following text to match that bullet:

"Policy oversight is performed by the IAB, which is neither a
government-led or an intergovernmental organization."


>
> 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.

That's the intent.
>
> 12) s3 (IANA Considerations)
>
> r/is a response a request for/is a response to a request for

Yep.

Regards,

Eliot