From nobody Thu Nov 19 21:53:12 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA33A18D0; Thu, 19 Nov 2020 21:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 n23WCbr90yzv; Thu, 19 Nov 2020 21:53:07 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926E73A18CD; Thu, 19 Nov 2020 21:53:05 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AK5r41X024462; Fri, 20 Nov 2020 05:53:04 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CE2652203B; Fri, 20 Nov 2020 05:53:03 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id B8EF72203A; Fri, 20 Nov 2020 05:53:03 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.90]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AK5r2v6001683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Nov 2020 05:53:03 GMT Reply-To: From: "Adrian Farrel" To: Cc: Date: Fri, 20 Nov 2020 05:53:02 -0000 Organization: Old Dog Consulting Message-ID: <00f901d6bf01$68e18150$3aa483f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00FA_01D6BF01.68E3F250" X-Mailer: Microsoft Outlook 16.0 Thread-Index: Ada/AWPycnIQml0wTw+2ZUstQODBDQ== Content-Language: en-gb X-Originating-IP: 195.166.134.90 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25800.004 X-TM-AS-Result: No--15.986-10.0-31-10 X-imss-scan-details: No--15.986-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25800.004 X-TMASE-Result: 10--15.985800-10.000000 X-TMASE-MatchedRID: 7khSq20EGrv9XvPxh7PvM5i/JtCbSi1TW6IdALvH8VNIXJo+eGm+FFJg /9hqcAh+SZJF7sKgpcsrGZfl768SGPa9Ixfq9T3YHT2MlaqyxprJ5SXtoJPLyKxU5GnNDO6Z0A4 5IAXRxM0ePEYCXfGzgKYppTu5ktrmddp1En6WfuSqDSBu0tUhr6nqnhCNnWZtRjHvrQ40NxZPnX Z9u2IhHU6x2v7t6c0w45nlxyFXjw8L6WqH6WmX3mhCG8qMW+KyvMRNh9hLjFkcNByoSo036cxIi 4bv8Pws/IAMiSHH8gxNL9bcWiPKTVI3mP8aC0PBOf/Bx1+MuMIX2zxRNhh61YxRWJphhsrcYmUf TlXs3OPWQ+VnLujU6v0RPplWlehyoWT+8OwdtGiInASnzB5VfEpFpc3bJiMeabJxhiIFjJn3h2j ybQkTkjdZv7CkHwR/KM7c3paWDi5OdkJru9i75UkDDCs/T+AZ+WzVGPiSY8iwuKAMD8Wm9cjLKL RPCIHw0m26OibmKjAT/uIa0+DRoxA+sC6pdjnQOctXWsNe0qUp/5z3nUiY7El/J9Ro+MABh/kMk Y0aKi7Ik8ZWquNbK1eaNh7AysR6tvcEIGYNXX8+NrfDUTEXxJOelX5LtjzR1y0aXF5eX+jYVu64 dziyNTp+w82lWIL6Z3dyEYeyDQfVSzMNxyhZUZVRzPxemJL0FbCjX6YN5bQ1a43ksVK2hWdZbbE FpKO8sqmzppr3zWvYlAhrLW5bRjB4WUWuaqN8ji4Eh2gp+O7LRD51bz5RZOFaOMaGlwcvGuhqcF SiQajVUyPYt22TJNk14jqTAQD3AZk5UvXKLCY0i6L0DcfAACHmjNSy4BIir10pknZXGJqb4iDlO 9ygjhvhAObZuuUtU6baA36eiawgbhiVsIMQK9XvcOE839ggKx6AD8TWE8EoEPjX2Fg+chRQgY73 wSLuruJUlkYF+rnDSb1+1bs5VkfUJYk4QS17pKCBcw/sBC9gRdTBLm+c2UveLUlMQMwz X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 05:53:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FA_01D6BF01.68E3F250 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00FB_01D6BF01.68E41960" ------=_NextPart_001_00FB_01D6BF01.68E41960 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, =20 [Replying top of thread] =20 This is very promising: thanks for the input so far. I=E2=80=99ll try = not to be so bold that I take four emails as overwhelming consensus, but = it looks good. =20 The next step would be to wordsmith the DE guidance text. Currently we = have: =20 In all cases of review by the Designated Expert (DE) described here, the DE is expected to check the clarity of purpose and use of the requested code points. Additionally, the DE must verify that any request for one of these code points has been made available for review and comment within the IETF: the DE will post the request to the IDR Working Group mailing list (or a successor mailing list designated by the IESG). If the request comes from within the IETF, it should be documented in an Internet-Draft. Lastly, the DE must ensure that any other request for a code point does not conflict with work that is active or already published within the IETF. =20 Issues appear to be (in no particular order): * Alvaro thinks using 8174 language would be appropriate * Do we require an I-D for *all* requests? * What level of review from the WG / mailing list do we have? * How long does it last? * Does the DE have to listen to the review? * Does the DE have to engage with the review? * How are differences of opinion handled? * Is WG consensus required? * How are registry conflicts handled? * Given the timing, do we now just wait for rfc7752bis? * Should assignments that reference an I-D also include the version number of the I-D? =20 For reference, the text in RFC 7370 is: =20 When new I-Ds are introduced requiring new codepoints, it is advantageous to be able to allocate codepoints without waiting for them to progress to RFC. The reasons this is advantageous are described in [RFC7120]. However, the procedures in [RFC7120] for early allocation do not apply to registries, such as the "IS-IS TLV Codepoints" registry, that utilize the "Expert Review" allocation policy. In such cases, what is required is that a request be made to the Designated Experts who MAY approve the assignments according to the guidance that has been established for the registry concerned. =20 The following guidance applies specifically to the "IS-IS TLV Codepoints" registry. =20 1. Application for a codepoint allocation MAY be made to the Designated Experts at any time. =20 2. The Designated Experts SHOULD only consider requests that arise from I-Ds that have already been accepted as Working Group documents or that are planned for progression as AD Sponsored documents in the absence of a suitably chartered Working Group. =20 3. In the case of Working Group documents, the Designated Experts SHOULD check with the Working Group chairs that there is consensus within the Working Group to make the allocation at this time. In the case of AD Sponsored documents, the Designated Experts SHOULD check with the AD for approval to make the allocation at this time. =20 4. The Designated Experts SHOULD then review the assignment requests on their technical merit. The Designated Experts SHOULD NOT seek to overrule IETF consensus, but they MAY raise issues for further consideration before the assignments are made. =20 5. Once the Designated Experts have granted approval, IANA will update the registry by marking the allocated codepoints with a reference to the associated document as normal. =20 6. In the event that the document fails to progress to RFC, the Expiry and deallocation process defined in [RFC7120] MUST be followed for the relevant codepoints -- noting that the Designated Experts perform the role assigned to Working Group chairs. =20 Best, Adrian =20 =20 From: Gyan Mishra =20 Sent: 20 November 2020 04:03 To: Acee Lindem (acee) Cc: Ketan Talaulikar (ketant) ; = adrian@olddog.co.uk; idr-chairs@ietf.org; idr@ietf.org Subject: Re: [Idr] Debate about IANA assignment policies for BGP-LS = registries =20 Hi Adrian=20 =20 I agree with Ketan as well on option #3. =20 Thanks=20 =20 Gyan =20 On Thu, Nov 19, 2020 at 9:29 AM Acee Lindem (acee) = > = wrote: Hi Adrian,=20 I agree with Ketan and would vote for #3 - I thought the last thread was = just wordsmithing the DE guidance and not grounds for a document reset.=20 Thanks, Acee =EF=BB=BFOn 11/19/20, 8:34 AM, "Idr on behalf of Ketan Talaulikar = (ketant)" on behalf = of ketant=3D40cisco.com@dmarc.ietf.org = > wrote: Hi Adrian, First, thanks for doing this. You've provided 3 options: 1. Leave the assignment policies and DE instructions in place = per 7752 and state that they do what we want. 2. Leave the assignment policies in place per 7752, but change = the DE instructions to give explicit advice about Internet-Drafts. KT> I don't believe the first two options can solve/address the main = issue why we went down this path. i.e. the "permanency" point for = "Specification Required" in RFC8126 and what is there today in the I-D = boilerplate. That is a different battle. 3. Change the assignment policies to be simply "Expert Review" = and change the DE instructions to describe what the DE must do. KT> I would vote for this one. "Expert Review" is what is already = there in draft-ietf-idr-bgp-ls-registries. The only change required is = the text for DE guidance and for that the text in RFC7370 (i.e. the way = it is done in IS-IS) looks apt to me for BGP-LS. If there is more tweaking that the WG requires, then let us remember = that https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/ is = following up right behind (hopefully very soon). The goal of draft-ietf-idr-bgp-ls-registries was to get a "quick = point fix" RFC for the allocation scheme for BGP-LS code-points. IMHO = stretching it out much further just defeats its purpose. Thanks, Ketan -----Original Message----- From: Idr > On = Behalf Of Adrian Farrel Sent: 19 November 2020 13:56 To: idr@ietf.org =20 Cc: idr-chairs@ietf.org =20 Subject: [Idr] Debate about IANA assignment policies for BGP-LS = registries Hi, You may have noticed some recent debate about = draft-ietf-idr-bgp-ls-registries on the IDR list. It is possible that, notwithstanding WG last call, the draft doesn't = correctly capture what the working group wanted. Since I hold the pen for the draft and am one of the Designated = Experts for the registry, I will try to set out my understanding of what = we currently have, what the document says, and what questions the WG may = need to address next. [For the avoidance of doubt: I'm just trying to serve the WG and = clarify the instructions to the DEs, I don't have much of an opinion = about this.] The registries were created by RFC 7752 and currently make = assignments according to "Specification Required." RFC 8126 (which = post-dated RFC 7752) defines these terms in section 4.6. "Specification = Required" includes the requirement for: - review by a Designated Expert - documentation in a permanent and readily available public = specification Debate rages about the meaning of "permanent" in this context. Does = an Internet-Draft count, does it expire, or is it archived by the tools = page? Does an individual I-D count, or does it need to be adopted first? = Does IANA track the I-D version, and if not what does it mean when a new = version changes the meaning of a code point? As Alvaro, our AD remarks, IDR is not the place to have this debate. = It is probably an IETF-wide debate and anyone is welcome to take it up = with IANA and the IESG. What we need to do is decide what we want as our policy for these = registries to be, and then work out how to achieve it. We can then set = the DE guidance (see section 5.1 of RFC 7752) to achieve the right = results. It seems, from various discussions on the list, that the WG (or some = of its more vocal participants) want to be able to assign code points = based on I-Ds and without requiring to do early allocation (RFC 7120). = There seem (to me) to be three ways to approach this: 1. Leave the assignment policies and DE instructions in place per = 7752 and state that they do what we want. 2. Leave the assignment policies in place per 7752, but change the = DE instructions to give explicit advice about Internet-Drafts. 3. Change the assignment policies to be simply "Expert Review" and = change the DE instructions to describe what the DE must do. The current draft seeks to implement option 3. I'd note that a secondary issue arises about requests for codepoints = arising from outside the IETF. Suppose another SDO or a vendor wants a = code point: Do they have to write an I-D? Does it have to gain adoption in the = WG? The chairs have a slide on this for the meeting on Friday. I'll = leave it to them to decide whether there is time in the meeting to = discuss the topic, but the agenda was previously full. Perhaps a = discussion on this list would be better. Best, Adrian _______________________________________________ Idr mailing list Idr@ietf.org =20 https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org =20 https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org =20 https://www.ietf.org/mailman/listinfo/idr --=20 =20 Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike=20 Silver Spring, MD =20 ------=_NextPart_001_00FB_01D6BF01.68E41960 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi all,

 

[Replying = top of thread]

 

This is = very promising: thanks for the input so far. I=E2=80=99ll try not to be = so bold that I take four emails as overwhelming consensus, but it looks = good.

 

The next = step would be to wordsmith the DE guidance text. Currently we = have:

 

=C2=A0=C2=A0 In all cases of review = by the Designated Expert (DE) described here,

=C2=A0=C2=A0 the DE is expected to = check the clarity of purpose and use of the

=C2=A0=C2=A0 requested code = points.=C2=A0 Additionally, the DE must verify that = any

=C2=A0=C2=A0 request for one of = these code points has been made available for

=C2=A0=C2=A0 review and comment = within the IETF: the DE will post the request to

=C2=A0=C2=A0 the IDR Working Group = mailing list (or a successor mailing list

=C2=A0=C2=A0 designated by the = IESG).=C2=A0 If the request comes from within the = IETF,

=C2=A0=C2=A0 it should be = documented in an Internet-Draft.=C2=A0 Lastly, the DE = must

=C2=A0=C2=A0 ensure that any other = request for a code point does not conflict with

=C2=A0=C2=A0 work that is active or = already published within the IETF.

 

Issues = appear to be (in no particular order):

  • Alvaro thinks using 8174 language = would be appropriate
  • Do we require an I-D for = *all* requests?
  • What level of review = from the WG / mailing list do we have?
    • How long does it = last?
    • Does the DE have to listen to the = review?
    • Does the DE have to engage with the = review?
    • How are differences of opinion = handled?
    • Is WG consensus = required?
    • How are registry conflicts = handled?
  • Given the timing, do we now just = wait for rfc7752bis?
  • Should assignments that reference = an I-D also include the
    version number of the = I-D?

 

For = reference, the text in RFC 7370 is:

 

=C2=A0=C2=A0 When new I-Ds are = introduced requiring new codepoints, it is

=C2=A0=C2=A0 advantageous to be = able to allocate codepoints without waiting for

=C2=A0=C2=A0 them to progress to = RFC.=C2=A0 The reasons this is advantageous are

=C2=A0=C2=A0 described in = [RFC7120].=C2=A0 However, the procedures in [RFC7120] = for

=C2=A0=C2=A0 early allocation do = not apply to registries, such as the "IS-IS = TLV

=C2=A0=C2=A0 Codepoints" = registry, that utilize the "Expert Review" = allocation

=C2=A0=C2=A0 policy.=C2=A0 In such = cases, what is required is that a request be made = to

=C2=A0=C2=A0 the Designated Experts = who MAY approve the assignments according to

=C2=A0=C2=A0 the guidance that has = been established for the registry concerned.

 

=C2=A0=C2=A0 The following guidance = applies specifically to the "IS-IS TLV

=C2=A0=C2=A0 Codepoints" = registry.

 

=C2=A0=C2=A0 1.=C2=A0 Application = for a codepoint allocation MAY be made to the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Designated Experts at any time.

 

=C2=A0=C2=A0 2.=C2=A0 The = Designated Experts SHOULD only consider requests that = arise

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= from I-Ds that have already been accepted as Working = Group

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= documents or that are planned for progression as AD = Sponsored

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= documents in the absence of a suitably chartered Working = Group.

 

=C2=A0=C2=A0 3.=C2=A0 In the case = of Working Group documents, the Designated = Experts

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= SHOULD check with the Working Group chairs that there = is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= consensus within the Working Group to make the allocation at = this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= time.=C2=A0 In the case of AD Sponsored documents, the = Designated

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Experts SHOULD check with the AD for approval to make = the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= allocation at this time.

 

=C2=A0=C2=A0 4.=C2=A0 The = Designated Experts SHOULD then review the assignment = requests

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= on their technical merit.=C2=A0 The Designated Experts SHOULD NOT = seek

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= to overrule IETF consensus, but they MAY raise issues for = further

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= consideration before the assignments are made.

 

=C2=A0=C2=A0 5.=C2=A0 Once the = Designated Experts have granted approval, IANA = will

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= update the registry by marking the allocated codepoints with = a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= reference to the associated document as normal.

 

=C2=A0=C2=A0 6.=C2=A0 In the event = that the document fails to progress to RFC, the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Expiry and deallocation process defined in [RFC7120] MUST = be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= followed for the relevant codepoints -- noting that = the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Designated Experts perform the role assigned to Working = Group

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= chairs.

 

Best,

Adrian

 

 

From: Gyan Mishra = <hayabusagsm@gmail.com>
Sent: 20 November 2020 = 04:03
To: Acee Lindem (acee) = <acee=3D40cisco.com@dmarc.ietf.org>
Cc: Ketan Talaulikar = (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>; = adrian@olddog.co.uk; idr-chairs@ietf.org; = idr@ietf.org
Subject: Re: [Idr] Debate about IANA assignment = policies for BGP-LS registries

 

Hi = Adrian 

 

I = agree with Ketan as well on option #3.

 

Thanks 

 

Gyan

 

On = Thu, Nov 19, 2020 at 9:29 AM Acee Lindem (acee) <acee=3D40cisco.com@dmarc.ietf.org= > wrote:

Hi = Adrian,
I agree with Ketan and would vote for #3 - I thought the = last thread was just wordsmithing the DE guidance and not grounds for a = document reset.
Thanks,
Acee

=EF=BB=BFOn 11/19/20, 8:34 = AM, "Idr on behalf of Ketan Talaulikar (ketant)" <idr-bounces@ietf.org on behalf of ketant=3D40cisco.com@dmarc.ietf.org> = wrote:

    Hi Adrian,

    First, = thanks for doing this.

    You've provided 3 = options:
        1. Leave the assignment policies = and DE instructions in place per 7752 and state that they do what we = want.
        2. Leave the assignment policies in = place per 7752, but change the DE instructions to give explicit advice = about Internet-Drafts.
    KT> I don't believe the first = two options can solve/address the main issue why we went down this path. = i.e. the "permanency" point for "Specification = Required" in RFC8126 and what is there today in the I-D = boilerplate. That is a different battle.

      =   3. Change the assignment policies to be simply "Expert = Review" and change the DE instructions to describe what the DE must = do.
    KT> I would vote for this one. "Expert = Review" is what is already there in = draft-ietf-idr-bgp-ls-registries. The only change required is the text = for DE guidance and for that the text in RFC7370 (i.e. the way it is = done in IS-IS) looks apt to me for BGP-LS.

    If there = is more tweaking that the WG requires, then let us remember that https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752= bis/ is following up right behind (hopefully very = soon).

    The goal of draft-ietf-idr-bgp-ls-registries = was to get a "quick point fix" RFC for the allocation scheme = for BGP-LS code-points. IMHO stretching it out much further just defeats = its purpose.

    Thanks,
    = Ketan

    -----Original Message-----
    = From: Idr <idr-bounces@ietf.org> On Behalf Of Adrian = Farrel
    Sent: 19 November 2020 13:56
    = To: idr@ietf.org
    Cc: idr-chairs@ietf.org
    Subject: = [Idr] Debate about IANA assignment policies for BGP-LS = registries

    Hi,

    You may have = noticed some recent debate about draft-ietf-idr-bgp-ls-registries on the = IDR list.

    It is possible that, notwithstanding WG = last call, the draft doesn't correctly capture what the working group = wanted.

    Since I hold the pen for the draft and am = one of the Designated Experts for the registry, I will try to set out my = understanding of what we currently have, what the document says, and = what questions the WG may need to address next.

    = [For the avoidance of doubt: I'm just trying to serve the WG and clarify = the instructions to the DEs, I don't have much of an opinion about = this.]

    The registries were created by RFC 7752 and = currently make assignments according to "Specification = Required." RFC 8126 (which post-dated RFC 7752) defines these terms = in section 4.6. "Specification Required" includes the = requirement for:
    - review by a Designated = Expert
    - documentation in a permanent and readily = available public specification

    Debate rages about = the meaning of "permanent" in this context. Does an = Internet-Draft count, does it expire, or is it archived by the tools = page?
    Does an individual I-D count, or does it need to = be adopted first? Does IANA track the I-D version, and if not what does = it mean when a new version changes the meaning of a code = point?

    As Alvaro, our AD remarks, IDR is not the = place to have this debate. It is probably an IETF-wide debate and anyone = is welcome to take it up with IANA and the IESG.

    = What we need to do is decide what we want as our policy for these = registries to be, and then work out how to achieve it. We can then set = the DE guidance (see section 5.1 of RFC 7752) to achieve the right = results.

    It seems, from various discussions on the = list, that the WG (or some of its more vocal participants) want to be = able to assign code points based on I-Ds and without requiring to do = early allocation (RFC 7120). There seem (to me) to be three ways to = approach this:

    1. Leave the assignment policies and = DE instructions in place per 7752 and state that they do what we = want.
    2. Leave the assignment policies in place per = 7752, but change the DE instructions to give explicit advice about = Internet-Drafts.
    3. Change the assignment policies to = be simply "Expert Review" and change the DE instructions to = describe what the DE must do.

    The current draft = seeks to implement option 3.

    I'd note that a = secondary issue arises about requests for codepoints arising from = outside the IETF. Suppose another SDO or a vendor wants a code = point:
    Do they have to write an I-D? Does it have to = gain adoption in the WG?



    The chairs have a = slide on this for the meeting on Friday. I'll leave it to them to decide = whether there is time in the meeting to discuss the topic, but the = agenda was previously full. Perhaps a discussion on this list would be = better.

    Best,
    Adrian

  =   _______________________________________________
    = Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr

&n= bsp;   _______________________________________________
  =   Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr

__= _____________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

-- =

3D"Image

Gyan = Mishra

Network Solutions = Architect 

M 301 = 502-1347
13101 Columbia Pike 
Silver Spring, = MD

 

------=_NextPart_001_00FB_01D6BF01.68E41960-- ------=_NextPart_000_00FA_01D6BF01.68E3F250 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEA8ADwAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAAtAMoBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK//9k= ------=_NextPart_000_00FA_01D6BF01.68E3F250--