From nobody Tue Oct 1 09:00:38 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23B120992; Tue, 1 Oct 2019 09:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mjbtqyegRpFc; Tue, 1 Oct 2019 09:00:32 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B9B120A28; Tue, 1 Oct 2019 08:51:21 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id k20so14881808oih.3; Tue, 01 Oct 2019 08:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uQ5xFTiNLEriw8mK9KPnSSRyGpTtV3bxfUGCAFwDqvo=; b=hsp2JdM/y9LXaMgolE+zIrTiFrlin2dBFue0E68p1z5fDp4ZzLF6SC2X8Y913WXnOA IJJtkYT1pFd7wxuI07wJ0vCcjETebZUgfd3rlfmsP6xRPnli5I0mFVVEgp0PEi/ZkOn6 VWFLPh6LNzvESYfRAZU+XNlWFRnxcf0L0q5gEkqFl5B5ovpwGKqib+KvV8uPde8gE5I4 nkoX2iCD/2Ga9gqBRewWVxemDOJoYR9uZovNg8S4941TFq3J4Ng4JCdVc82Ev2s3x87K hoBxaGsEDpw2tYATpGiERvuHbRsSKahU3k5ut0dyFzU1dAOw0U1A0ECTTANCJBjNpotF mFgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uQ5xFTiNLEriw8mK9KPnSSRyGpTtV3bxfUGCAFwDqvo=; b=JcPh40Cwt75y8U38tMLfpucS7kvzD/ax86ks2lkSu0ZC+2HZU04TQJS/790jHGjal2 dRw5evHqniGKUAUkOCEFcOpaT84G8wZ2yuOzSkFQXvQWLpc9PYlaV18+4Vy5tgTHqi4W O5robzqQNxO2Q5WksUPWEsPVFT8eXCWx2BUXGZtYotUf5g8fB+isRqszedR8I77L6Z+7 9NBLaLxwC7HlnF3FCkdUS7t+XXAtqPUVP0oCs0ieFuK1GlssgA8FMKPC8I11Y8RvRZ0p AIO5m/EfzMq7ewwL0IwfJmw/ncDpKRypfZaVUvMypDDqTPLJzn6LCZjf1JXTPnU2jtjY 3hRA== X-Gm-Message-State: APjAAAULgg2M84jiTSWV5w2MuzaIvQZc+34JK9NLI/SdSd4E6QhfHJx3 xDUjdOp35amHO/FUCDF+M7z9uo5ertI/cqKuHKU= X-Google-Smtp-Source: APXvYqyixkRlj2b3BAlH2VR4F0/45pvMptUPQRhqTADvtonByBNuIxPwe0g+rBk1wM0k+Ygr/kO7DmsMywospuGrqsc= X-Received: by 2002:a05:6808:b07:: with SMTP id s7mr4027169oij.134.1569945080760; Tue, 01 Oct 2019 08:51:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2f61:0:0:0:0:0 with HTTP; Tue, 1 Oct 2019 08:51:20 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Tue, 1 Oct 2019 22:51:20 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" , "tsoupi@uic.edu" , "info@playthemagic.com" Content-Type: multipart/alternative; boundary="000000000000db11a10593db527e" Archived-At: Subject: Re: [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 16:00:36 -0000 --000000000000db11a10593db527e Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, To share what may be inspiring: If there are society of networks and networks of societies may we say also about pedagogy of networks and networks of pedagogies: thus we are supposedly combining those notions on "society", "networks", "languages" and "great operations of capital" (those of M. Castells', J.F. Lyotard's and G. Deleuze and F. Guattari's)... Regard, Guntur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > (There are things need to correct on * Note) > > To share what I have found out: if such public installations inspire/is > about exploring musicality of diferent architectural features --as it was > attempted by "Building Music" of Electronic Visual Laboratory UIC: > > > https://www.evl.uic.edu/entry.php?id=1985 > > > *Note: > - There is a correction for Daria Tsoupikova e-mail address of my previous > messages on Marcos Novak'"Liquid Architecture in Cyberspace" > - Should I add CC: info@playthemagic.com as it is of the "Building Music" > page which may have importances. > > > Regard, > Guntur Wiseno Putra > > > > > > Dear architecture-discuss, > > > > To share what I have found out: if such public installations inspire/is > about exploring musicality of diferent architectural features --as it was > attempted by "Building Music" of Electronic Visual Laboratory UIC: > > > https://www.evl.uic.edu/entry.php?id=1985 > > > *Note: There is a correction for Daria Tsoupikova e-mail address of my > previous messages... > > > Regard, > Guntur Wiseno Putra > > > > Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> >> >> To share what I have found out: if such public installations inspire/is >> about exploring musicality of diferent architectural features --as it was >> attempted by "Building Music" of Electronic Visual Laboratory UIC: >> >> >> https://www.evl.uic.edu/entry.php?id=1985 >> >> >> *Note: There is a correction for Daria Tsoupikova e-mail address of my >> previous messages... >> >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >> menulis: >> >>> Dear architecture-discuss, >>> >>> Forgive me for typing errors in previous message... >>> >>> An alternative link to the posting on Marcos Novak's "Liquid >>> Architecture in Cyberspace" at public@informationarchitecture@w3.org I >>> mentioned earlier is >>> >>> https://lists.w3.org/Archives/Public/public-informationarchi >>> tecture/2019May/0000.html >>> >>> (which was "403 Forbidden: Request forbidden by administrative rules" >>> the last time I checked up minutes ago) >>> >>> Or, if going directly toward the text: >>> >>> https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf >>> >>> Thank to Martin Dodge for suggesting Marcos Novak's architecture in >>> www.cybergeography.org bringing me to Daria Tsoupukiva's lecture >>> providing the reading... >>> >>> >>> >>> Regard, >>> Guntur Wiseno Putra >>> >>> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >>> menulis: >>> >>>> Dear architecture-discuss, >>>> >>>> An alternative link to the posting on Marcos Nocak'S "Liquid >>>> Architecture in Cyberspace" at public@informationarchitecture@w3.org >>>> I mentioned earlier is >>>> >>>> https://lists.w3.org/Archives/Public/public-informationarchi >>>> tecture/2019May/0000.html >>>> >>>> (which was "403 Forbidden: Request forbidden by administrative rules" >>>> the last time I checked up minutes ago) >>>> >>>> Or, if going directly toward the text: >>>> >>>> https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ >>>> Liquid.pdf >>>> >>>> Thank to Martin Dodge for suggesting Marcos Novak's architecture in >>>> www.cybergeography.org bringing me to Daria Tsoupukiva's lecture >>>> providing the reading... >>>> >>>> Regard, >>>> Gubtur Wiseno Putra >>>> >>>> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >>>> menulis: >>>> >>>>> Dear architecture-discuss, >>>>> >>>>> Such co-presences of which architecture is part of: if we attempt to >>>>> think of its relation with other human experiences on poetry, on poetics, >>>>> on a spirit invoked to make comprehensible a poetic fact, to get toward an >>>>> understanding of cyberspace architecture, of "Liquid Architecture in >>>>> Cyberspace" (Marcos Novak, 1991) >>>>> >>>>> I suggested as a reading to public-informationarchitecture@w3.org at >>>>> which there is the web-address to the Novak's work (posted at 12 May 2019): >>>>> >>>>> http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy >>>>> T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture >>>>> Regard, >>>>> >>>>> Guntur Wiseno Putra >>>>> >>>>> Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra >>>>> menulis: >>>>> >>>>>> Dear architecture-discuss, >>>>>> & John, >>>>>> >>>>>> To share what might be inspiring... >>>>>> >>>>>> In order to propose what should be understood as "concept", "percept" >>>>>> & "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >>>>>> Philosophy?") mentioned architecture as the first art as art begins with >>>>>> house: that of which "the most scientific architecture continually produces >>>>>> and unifies planes and sections... it could be defined as "frame" with a >>>>>> connection among various frames oriented differently, applied to other >>>>>> arts...(There is) a composite system consisting of points and >>>>>> counterpoints... (there is) a matter of sensations (percepts and affects) >>>>>> combined... (While) the system still needs a composition plane run >>>>>> "deframing" opening ways from house territory to city-cosmos, the system in >>>>>> which there are cosmic forces to create new affects...". >>>>>> >>>>>> There is "asthetic composition" as the working of sensation which is, >>>>>> so they said, the definition of art... >>>>>> >>>>>> Regard, >>>>>> Guntur Wiseno Putra >>>>>> >>>>>> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >>>>>> >>>>>>> John -- >>>>>>> >>>>>>> It's going to take a while for me to formulate my thoughts around >>>>>>> what you say below. To make sure I understand the class of constraints >>>>>>> you're concerned about below, can you clarify whether you think they apply >>>>>>> to: >>>>>>> >>>>>>> - Documents like BCP 200, RFC 2804, and BCP 188? >>>>>>> - Documents like BCP 9 and BCP 92? >>>>>>> - Documents like BCP 25, BCP 54, and BCP 83? >>>>>>> >>>>>>> You might see an unstated agenda in the categories of documents I >>>>>>> list above, so I'll state it explicitly: in the general case, one person's >>>>>>> important protections against a tragedy of the commons is another person's >>>>>>> annoying impediment to be ignored and defeated. I get that not all of the >>>>>>> above read on protocol design; but they do share the common feature that >>>>>>> they've gone through the IETF consensus process (at least to the degree >>>>>>> that such a process existed at the time of their respective publications). >>>>>>> If we're going to carefully parse out the meanings of some of them as the >>>>>>> will of the community while treating others as light guidelines to be >>>>>>> ignored when they become cumbersome, we're going to need to agree on a >>>>>>> pretty bright line that divides those categories. >>>>>>> >>>>>>> /a >>>>>>> >>>>>>> On 7/23/19 08:37, John C Klensin wrote: >>>>>>> >>>>>>> (copying architecture-discuss because the comment I'm about to >>>>>>> make is an architectural issue and because >>>>>>> draft-nottingham-for-the-users is under discussion there.) >>>>>>> >>>>>>> >>>>>>> A late colleague, much loved by some of us, used to claim (much >>>>>>> more elegantly than I can manage) that one of the reasons the >>>>>>> ARPANET and then the Internet protocols had succeeded and much >>>>>>> of what was seen as competitive alternatives had not, was that >>>>>>> our efforts focused on pragmatic, working protocols and >>>>>>> implementations. >>>>>>> >>>>>>> The other folks had developed a culture of formalisms, models, >>>>>>> and stated design principles. They then tried to develop >>>>>>> protocols that fit into the boxes and categories of those >>>>>>> formalisms, models, and design principles. When they >>>>>>> discovered that something didn't fit, they needed to either >>>>>>> invent kludges or other ways of getting square pegs into round >>>>>>> holes, go back and revise models and guidance before moving >>>>>>> forward, or consider and make exceptions (which often required >>>>>>> first figuring out how to make an exception and developing >>>>>>> procedures for that). >>>>>>> >>>>>>> One difficulty is that the above can waste a lot of time. >>>>>>> Another is that it can distort protocol design, if only because >>>>>>> forcing square pegs into round holes tends to be hard on both >>>>>>> the pegs and the holes. >>>>>>> >>>>>>> In many or most fields of application, the nature of engineering >>>>>>> involves seeing and understanding a range of tradeoffs and then >>>>>>> doing design work that reflects a carefully-chosen balance among >>>>>>> them. Give design elegance absolute priority over structural >>>>>>> issues and buildings and bridges fall down. IMO, we need to >>>>>>> think, and keep thinking, about systems and tradeoffs. That, in >>>>>>> turn, means that statements like these that can be interpreted >>>>>>> in absolute terms, even if we mostly agree with them, should be >>>>>>> packaged as general guidelines and not BCPs to which everything >>>>>>> done in the future is required to either conform or to try to >>>>>>> figure out how to appeal to a higher authority. >>>>>>> >>>>>>> I'm not at all convinced that the proposal that was summarized >>>>>>> an ARTAREA yesterday and that is seen as requiring an exception >>>>>>> to BCP 190 is a good idea. But I think our time would be better >>>>>>> spent, and the Internet more efficiently made better, discussing >>>>>>> the strengths, weaknesses, and alternatives to that idea rather >>>>>>> than debating the reach and appropriateness of BCP 190 under >>>>>>> various circumstances. Long term and more generally, I think >>>>>>> that suggests seeing BCP 190 not as a particular set of >>>>>>> principles and rules but as an example of something we don't >>>>>>> want to do to ourselves again as a BCP (or as something that >>>>>>> gets enough of an IAB stamp of approval that people will later >>>>>>> argue MUST (or SHOULD) be conformed to. Again, restated as >>>>>>> general guidance with the assumption that there will be >>>>>>> exceptions and cases not considered, I don't have much of a >>>>>>> problem. If that shoe fits draft-nottingham-for-the-users, >>>>>>> so be it. >>>>>>> >>>>>>> john >>>>>>> >>>>>>> p.s. I don't mean to pick on Mark here. While these two >>>>>>> documents coming up at the same time was handy, I think the >>>>>>> problem is general and that there are far worse examples >>>>>>> (examples of which he is not an author) than either of them. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>>>>>> >>>>>>> >>>>>>> --000000000000db11a10593db527e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,


To share what may be inspiring:

If there are soci= ety of networks and networks of societies may we say also about pedagogy of= networks and networks of pedagogies: thus we are supposedly combining thos= e notions on "society", "networks", "languages&quo= t; and "great operations of capital" (those of M. Castells', = J.F. Lyotard's and G. Deleuze and F. Guattari's)...

<= /div>

Regard,
Guntur Wiseno Putra
Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,
=
(There are things need to correct on * Note)

<= /div>
To share what I have found out: if such public installations insp= ire/is about exploring musicality of diferent architectural features --as i= t was attempted by "Building Music" of Electronic Visual Laborato= ry UIC:




*Note:= =C2=A0
- There is a correction for Daria Tsoupikova e-mail addres= s of my previous messages on Marcos Novak'"Liquid Architecture in = Cyberspace"
- Should I add CC: info@playthemagic.com as it is of the &qu= ot;Building Music" page which may have importances.


Regard,
Guntur Wiseno Putra





Dear architecture-discuss,



To share what I have found out: if such public installations inspire/is a= bout exploring musicality of diferent architectural features --as it was at= tempted by "Building Music" of Electronic Visual Laboratory UIC:<= /div>




*Note: There i= s a correction for Daria Tsoupikova e-mail address of my previous messages.= ..


Regard,
Guntur Wiseno = Putra



Pada Minggu, 11 Agustus 2019, Guntu= r Wiseno Putra <g= senopu@gmail.com> menulis:
Dear ar= chitecture-discuss,



To sha= re what I have found out: if such public installations inspire/is about exp= loring musicality of diferent architectural features --as it was attempted = by "Building Music" of Electronic Visual Laboratory UIC:




*Note: There is a corr= ection for Daria Tsoupikova e-mail address of my previous messages...
=


Regard,
Guntur Wiseno Putra
Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

<= div>Forgive me for typing errors in previous message...
=

An alternative link to the posting= on Marcos Novak's "Liquid Architecture in Cyberspace" at pub= lic@informationarchitecture@w3.org=C2=A0I mentioned earlier is
<= br>

(which was "403 Forbidden: Reques= t forbidden by administrative rules" the last time I checked up minute= s ago)

Or, if going directly toward the text:


Thank to M= artin Dodge for suggesting Marcos Novak's architecture in=C2=A0www.cybergeography.or= g=C2=A0bringing me to Daria Tsoupukiva's lecture providing the= reading...



Re= gard,
Guntur Wiseno Putra

Pada Minggu, 11 Agustus 2019, Gu= ntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear= architecture-discuss,

An alternative link to the postin= g on Marcos Nocak'S "Liquid Architecture in Cyberspace" at pu= blic@informationarchitecture@w3.org=C2=A0 I mentioned earlier is

(which was "403 Forbidden: Request forbidden by administr= ative rules" the last time I checked up minutes ago)

Or, if going directly toward the text:

https:///www.evl.uic.edu/datsoupi/coding/readings/Ma= rcos_Novak_ Liquid.pdf

Thank to Martin Do= dge for suggesting Marcos Novak's architecture in www.cybergeography.org bringing = me to Daria Tsoupukiva's lecture providing the reading...
Regard,
Gubtur Wiseno Putra

Pada Minggu, 11 Ag= ustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

Such co-presences o= f which architecture is part of: if we attempt to think of its relation wit= h other human experiences on poetry, on poetics, on a spirit invoked to mak= e comprehensible a poetic fact, to get toward an understanding of cyberspac= e architecture, of "Liquid Architecture in Cyberspace" (Marcos No= vak, 1991)

I suggested as a reading to public-info= rmationarchitecture@w3.org at which there is the web-address to th= e Novak's work (posted at 12 May 2019):

Regard,

Guntur Wiseno Putr= a

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,
& John,<= br>

To share what might be inspiring...
In order to propose what should be understood as "concept= ", "percept" & "affect", thus as "philoso= phy" & "art", Deleuze & Guattari ("What is Phil= osophy?") mentioned architecture as the first art as art begins with h= ouse: that of which "the most scientific architecture continually prod= uces and unifies planes and sections... it could be defined as "frame&= quot; with a connection among various frames oriented differently, applied = to other arts...(There is) a composite system consisting of points and coun= terpoints... (there is) a matter of sensations (percepts and affects) combi= ned... (While) the system still needs a composition plane run "deframi= ng" opening ways from house territory to city-cosmos, the system in wh= ich there are cosmic forces to create new affects...".

<= /div>
There is "asthetic composition" as the working of sensa= tion which is, so they said, the definition of art...

<= div>Regard,
Guntur Wiseno Putra

Pada Selasa, 23 Juli 2019,= Adam Roach <adam@= nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--000000000000db11a10593db527e-- From nobody Mon Oct 14 12:45:32 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27188120932 for ; Mon, 14 Oct 2019 12:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 SK3lDR5XkKEt for ; Mon, 14 Oct 2019 12:45:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6980D12091A for ; Mon, 14 Oct 2019 12:45:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E7F54300AAB for ; Mon, 14 Oct 2019 15:45:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CyeuqkW1O9-w for ; Mon, 14 Oct 2019 15:45:25 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id DFB45300460; Mon, 14 Oct 2019 15:45:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <281D3BF8-CE5E-46D3-B4F4-F0289606C308@cooperw.in> Date: Mon, 14 Oct 2019 15:45:25 -0400 Cc: architecture-discuss@ietf.org, IAB Content-Transfer-Encoding: quoted-printable Message-Id: <33B6BD0C-260B-4061-A188-58CD1CA44535@vigilsec.com> References: <156763101565.22770.5246009160641276406.idtracker@ietfa.amsl.com> <281D3BF8-CE5E-46D3-B4F4-F0289606C308@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Call for Comment: (The RFC Series and RFC Editor) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 19:45:30 -0000 Alissa: > Section 3.3: >=20 > The first paragraph of this section fails to mention the IAB and RSOC, = which according to RFC 6635 have oversight roles. It seems incorrect to = claim that operational oversight is solely the responsibility of IASA. >=20 > The second paragraph is superfluous since the roles of the LLC Board = and ED are defined in rfc4071bis, so I think for clarity it should be = removed. >=20 > The resulting changes could appear as follows: >=20 > OLD=20 > The IETF Administration Limited Liability Company (IETF LLC), as part = of the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The = IASA is tasked with providing the funding for and operational oversight = of the RFC Editor. >=20 > The IETF LLC Board provides oversight of the IASA, and the IETF = Executive Director is the chief actor for the IASA. >=20 > The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor. >=20 > NEW=20 > The IETF Administration Limited Liability Company (IETF LLC), as part = of the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA = is tasked with providing the funding for the RFC Editor. The IASA, the = IAB, and the RFC Series Oversight Committee (RSOC) provide operational = oversight of the RFC Editor. >=20 > The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor. The RSOC is not otherwise mentioned in this document, so to bring the = RSOC into this discussion, I think a bit more context is needed. I = suggest: The IETF Administration Limited Liability Company (IETF LLC), as part of the IETF Administrative Support Activity (IASA), is responsible for administrative and financial matters for the IETF, the IAB, and the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The IASA is tasked with providing the funding for the RFC Editor. The IASA and the IAB provide operational oversight of the RFC Editor; however, as described in Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], RFC Series Oversight Committee (RSOC), acting with authority delegated from the IAB, is responsible for ensuring that the RFC Series is run in a transparent and accountable manner, including design and execution of the RFC Series Editor selection process. The IETF Executive Director works with the IAB to identify suitable persons or entities to fulfill the mandate of the RFC Production Center and the RFC Publisher roles as defined in [I-D.ietf-iasa2-rfc6635bis]. > Section 7: >=20 > I would suggest the following to make the text consistent with = rfc4071bis Sec. 4.2: >=20 > OLD > Under the new structure, the IETF LLC performs the tasks that were > previously assigned to the IETF Administrative Oversight Committee > (IAOC) under the old structure. >=20 > NEW > Under the new structure, the IETF LLC performs the tasks related to = IASA that were > previously assigned to the IETF Administrative Director and to the = Internet Society. Sure. That is an improvement. Russ From nobody Tue Oct 15 07:09:55 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391F8120119 for ; Tue, 15 Oct 2019 07:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.com 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 bahymH72JA6O for ; Tue, 15 Oct 2019 07:09:50 -0700 (PDT) Received: from anteater.oak.relay.mailchannels.net (anteater.oak.relay.mailchannels.net [23.83.215.3]) (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 906EB120043 for ; Tue, 15 Oct 2019 07:09:49 -0700 (PDT) Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0202120A95; Tue, 15 Oct 2019 14:09:47 +0000 (UTC) Received: from pdx1-sub0-mail-a97.g.dreamhost.com (100-96-6-135.trex.outbound.svc.cluster.local [100.96.6.135]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7DE75229FA; Tue, 15 Oct 2019 14:09:31 +0000 (UTC) Received: from pdx1-sub0-mail-a97.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 15 Oct 2019 14:09:46 +0000 Received: from pdx1-sub0-mail-a97.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a97.g.dreamhost.com (Postfix) with ESMTP id F385E7F7ED; Tue, 15 Oct 2019 07:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=a v2B97rDgXUhch9iEXQFIq30Vgo=; b=oL659Zga+jygb+/L6l1cTaDDkoumiT1DN jURC0Zjy4BwGGn5iFz1iSo4vUUbAPruf1Z35VrzoSdKl1WhaC0fKSIAhwBBkt1v1 iyvsDiigTUpOcGWu1XTT14iZVPJFFWcBs5c15XjVIuOxfGcQXuh0a5dgGiVgLXFh AH5QFE83+0= Received: from [192.168.62.222] (unknown [94.142.114.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 3C5FB7F7EC; Tue, 15 Oct 2019 07:09:22 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a97 From: "Leslie Daigle" To: "Russ Housley" Cc: "Alissa Cooper" , IAB , architecture-discuss@ietf.org Date: Tue, 15 Oct 2019 10:09:15 -0400 X-Mailer: MailMate (1.13r5655) Message-ID: <8B086B3F-5630-43BF-91E2-6747EE75EC03@thinkingcat.com> In-Reply-To: <33B6BD0C-260B-4061-A188-58CD1CA44535@vigilsec.com> References: <156763101565.22770.5246009160641276406.idtracker@ietfa.amsl.com> <281D3BF8-CE5E-46D3-B4F4-F0289606C308@cooperw.in> <33B6BD0C-260B-4061-A188-58CD1CA44535@vigilsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_C9294CF6-24EB-416D-8630-92141E330D24_=" Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Call for Comment: (The RFC Series and RFC Editor) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 14:09:53 -0000 --=_MailMate_C9294CF6-24EB-416D-8630-92141E330D24_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable I agree that the second point is improved wording. However on the first point, while I agree a rewrite is in order, I think=20 Alissa=E2=80=99s suggested text, and your refinements, are taking us a bi= t off=20 track. In-line: On 14 Oct 2019, at 15:45, Russ Housley wrote: > Alissa: > >> Section 3.3: >> >> The first paragraph of this section fails to mention the IAB and=20 >> RSOC, which according to RFC 6635 have oversight roles. It seems=20 >> incorrect to claim that operational oversight is solely the=20 >> responsibility of IASA. >> >> The second paragraph is superfluous since the roles of the LLC Board=20 >> and ED are defined in rfc4071bis, so I think for clarity it should be=20 >> removed. >> >> The resulting changes could appear as follows: >> >> OLD >> The IETF Administration Limited Liability Company (IETF LLC), as part=20 >> of the IETF Administrative Support Activity (IASA), is responsible=20 >> for administrative and financial matters for the IETF, the IAB, and=20 >> the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].=20 >> The IASA is tasked with providing the funding for and operational=20 >> oversight of the RFC Editor. >> >> The IETF LLC Board provides oversight of the IASA, and the IETF=20 >> Executive Director is the chief actor for the IASA. >> >> The IETF Executive Director works with the IAB to identify suitable=20 >> persons or entities to fulfill the mandate of the RFC Editor. >> >> NEW >> The IETF Administration Limited Liability Company (IETF LLC), as part=20 >> of the IETF Administrative Support Activity (IASA), is responsible=20 >> for administrative and financial matters for the IETF, the IAB, and=20 >> the Internet Research Task Force (IRTF)=20 >> [I-D.ietf-iasa2-rfc4071bis].The IASA is tasked with providing the=20 >> funding for the RFC Editor. The IASA, the IAB, and the RFC Series=20 >> Oversight Committee (RSOC) provide operational oversight of the RFC=20 >> Editor. Oh, boy, operational oversite from 3 independent bodies! Sounds like=20 serving 3 masters, and two is already discouraged in most literature. The original intent was to make the distinction between oversight of=20 substantive matters (which fell to the IAB, and now its delegate, the=20 RSOC) and contractual, day-to-day matters, which falls to the admin side=20 of the house. I think we need to continue to make some version of that distinction=20 (and, evidently clearer than it was originally written). I also note that the original text, convoluted as it had become, made=20 the IAD/IETF Executive Director, in charge of those contracts. If we=20 simply say =E2=80=9Cthe IASA=E2=80=9D, we introduce an infelicitous fourt= h potential=20 oversight body, in the shape of the IASA LLC Board. There is nothing in=20 this setup that rises to the level of the involvement of the IASA LLC=20 Board, except in its normal oversight of the exec dir. Straw text: The IETF Administration Limited Liability Company (IETF LLC), as part of the IETF Administrative Support Activity (IASA), is responsible for administrative and financial matters for the IETF, the IAB, and the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The IASA is tasked with providing the funding for the RFC Editor. =20 The IASA (through the IETF Executive Director) provides contractual and=20 financial oversight of the RFC Editor. Additionally, as described in=20 Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], RFC Series Oversight Committee (RSOC), acting with authority delegated from the IAB, is responsible for ensuring that the RFC Series is run in a transparent and accountable manner, including design and execution of the RFC Series Editor selection process. The IETF Executive Director works with the IAB to identify suitable persons or entities to fulfill the mandate of the RFC Production Center and the RFC Publisher roles as defined in [I-D.ietf-iasa2-rfc6635bis]. >> Leslie. >> The IETF Executive Director works with the IAB to identify suitable=20 >> persons or entities to fulfill the mandate of the RFC Editor. > > The RSOC is not otherwise mentioned in this document, so to bring the=20 > RSOC into this discussion, I think a bit more context is needed. I=20 > suggest: > > The IETF Administration Limited Liability Company (IETF LLC), as=20 > part > of the IETF Administrative Support Activity (IASA), is responsible > for administrative and financial matters for the IETF, the IAB, and > the Internet Research Task Force (IRTF)=20 > [I-D.ietf-iasa2-rfc4071bis]. > The IASA is tasked with providing the funding for the RFC Editor. > The IASA and the IAB provide operational oversight of the RFC=20 > Editor; > however, as described in Section 3.1 of=20 > [I-D.ietf-iasa2-rfc6635bis], > RFC Series Oversight Committee (RSOC), acting with authority > delegated from the IAB, is responsible for ensuring that the RFC > Series is run in a transparent and accountable manner, including > design and execution of the RFC Series Editor selection process. > > The IETF Executive Director works with the IAB to identify suitable > persons or entities to fulfill the mandate of the RFC Production > Center and the RFC Publisher roles as defined in > [I-D.ietf-iasa2-rfc6635bis]. > > >> Section 7: >> >> I would suggest the following to make the text consistent with=20 >> rfc4071bis Sec. 4.2: >> >> OLD >> Under the new structure, the IETF LLC performs the tasks that were >> previously assigned to the IETF Administrative Oversight Committee >> (IAOC) under the old structure. >> >> NEW >> Under the new structure, the IETF LLC performs the tasks related to=20 >> IASA that were >> previously assigned to the IETF Administrative Director and to the=20 >> Internet Society. > > Sure. That is an improvement. > > Russ > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --=20 ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- --=_MailMate_C9294CF6-24EB-416D-8630-92141E330D24_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I agree that the second point is improved wording.

However on the first point, while I agree a rewrite is in= order, I think Alissa=E2=80=99s suggested text, and your refinements, ar= e taking us a bit off track.

In-line:

On 14 Oct 2019, at 15:45, Russ Housley wrote:

A= lissa:

Section 3.3= :

The first paragraph of this section fails to mention the IAB and RSOC, wh= ich according to RFC 6635 have oversight roles. It seems incorrect to cla= im that operational oversight is solely the responsibility of IASA.

The second paragraph is superfluous since the roles of the LLC Board and = ED are defined in rfc4071bis, so I think for clarity it should be removed= =2E

The resulting changes could appear as follows:

OLD
The IETF Administration Limited Liability Company (IETF LLC), as part of = the IETF Administrative Support Activity (IASA), is responsible for admin= istrative and financial matters for the IETF, the IAB, and the Internet R= esearch Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The IASA is tasked= with providing the funding for and operational oversight of the RFC Edit= or.

The IETF LLC Board provides oversight of the IASA, and the IETF Executive= Director is the chief actor for the IASA.

The IETF Executive Director works with the IAB to identify suitable perso= ns or entities to fulfill the mandate of the RFC Editor.

NEW
The IETF Administration Limited Liability Company (IETF LLC), as part of = the IETF Administrative Support Activity (IASA), is responsible for admin= istrative and financial matters for the IETF, the IAB, and the Internet R= esearch Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA is tasked = with providing the funding for the RFC Editor. The IASA, the IAB, and the= RFC Series Oversight Committee (RSOC) provide operational oversight of t= he RFC Editor.

Oh, boy, operational oversite from 3 independent bodies! = Sounds like serving 3 masters, and two is already discouraged in most l= iterature.

The original intent was to make the distinction between o= versight of substantive matters (which fell to the IAB, and now its deleg= ate, the RSOC) and contractual, day-to-day matters, which falls to the ad= min side of the house.

I think we need to continue to make some version of that = distinction (and, evidently clearer than it was originally written).

I also note that the original text, convoluted as it had = become, made the IAD/IETF Executive Director, in charge of those contract= s. If we simply say =E2=80=9Cthe IASA=E2=80=9D, we introduce an infelici= tous fourth potential oversight body, in the shape of the IASA LLC Board.= There is nothing in this setup that rises to the level of the involveme= nt of the IASA LLC Board, except in its normal oversight of the exec dir.=

Straw text:

The IETF Administration Limited Liability Company (IETF L= LC), as part
of the IETF Administrative Support Activity (IASA), is responsible
= for administrative and financial matters for the IETF, the IAB, and the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The IASA is tasked with providing the funding for the RFC Editor. The= IASA (through the IETF Executive Director) provides contractual and fina= ncial oversight of the RFC Editor. Additionally, as described in Section= 3.1 of [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection process.

The IETF Executive Director works with the IAB to identif= y suitable
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Leslie.

The IETF Executive Director = works with the IAB to identify suitable persons or entities to fulfill th= e mandate of the RFC Editor.

The RSOC is not otherwise mentioned in this = document, so to bring the RSOC into this discussion, I think a bit more c= ontext is needed. I suggest:

The IETF Administration Limited Liability Company (IETF LLC), as part<= br> of the IETF Administrative Support Activity (IASA), is responsible
= for administrative and financial matters for the IETF, the IAB, and the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The IASA is tasked with providing the funding for the RFC Editor.
The IASA and the IAB provide operational oversight of the RFC Editor;<= br> however, as described in Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection process.

The IETF Executive Director works with the IAB to identify suitable persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Section 7:<= br>
I would suggest the following to make the text consistent with rfc4071bis= Sec. 4.2:

OLD
Under the new structure, the IETF LLC performs the tasks that were
previously assigned to the IETF Administrative Oversight Committee
(IAOC) under the old structure.

NEW
Under the new structure, the IETF LLC performs the tasks related to IAS= A that were
previously assigned to the IETF Administrative Director and to the Inte= rnet Society.

Sure. That is an improvement.

Russ

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-dis= cuss

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com

--=_MailMate_C9294CF6-24EB-416D-8630-92141E330D24_=-- From nobody Tue Oct 15 09:22:27 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC5120033 for ; Tue, 15 Oct 2019 09:22:24 -0700 (PDT) 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 2vZk85_8S3SR for ; Tue, 15 Oct 2019 09:22:20 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DFC12010F for ; Tue, 15 Oct 2019 09:22:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E603C300B1F for ; Tue, 15 Oct 2019 12:22:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zXXKUWPoLiO6 for ; Tue, 15 Oct 2019 12:22:15 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id DEA4F300A0A; Tue, 15 Oct 2019 12:22:14 -0400 (EDT) From: Russ Housley Message-Id: <5614790E-8498-4546-8585-3171EB3C722B@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3AC9063A-F567-4745-9FC7-E20DF944C6B1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 15 Oct 2019 12:22:15 -0400 In-Reply-To: <8B086B3F-5630-43BF-91E2-6747EE75EC03@thinkingcat.com> Cc: Alissa Cooper , IAB , architecture-discuss@ietf.org To: Leslie Daigle References: <156763101565.22770.5246009160641276406.idtracker@ietfa.amsl.com> <281D3BF8-CE5E-46D3-B4F4-F0289606C308@cooperw.in> <33B6BD0C-260B-4061-A188-58CD1CA44535@vigilsec.com> <8B086B3F-5630-43BF-91E2-6747EE75EC03@thinkingcat.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Call for Comment: (The RFC Series and RFC Editor) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 16:22:24 -0000 --Apple-Mail=_3AC9063A-F567-4745-9FC7-E20DF944C6B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Leslie: Works for me. =20 Russ > On Oct 15, 2019, at 10:09 AM, Leslie Daigle = wrote: >=20 > I agree that the second point is improved wording. >=20 > However on the first point, while I agree a rewrite is in order, I = think Alissa=E2=80=99s suggested text, and your refinements, are taking = us a bit off track. >=20 > In-line: >=20 > On 14 Oct 2019, at 15:45, Russ Housley wrote: >=20 > Alissa: >=20 > Section 3.3: >=20 > The first paragraph of this section fails to mention the IAB and RSOC, = which according to RFC 6635 have oversight roles. It seems incorrect to = claim that operational oversight is solely the responsibility of IASA. >=20 > The second paragraph is superfluous since the roles of the LLC Board = and ED are defined in rfc4071bis, so I think for clarity it should be = removed. >=20 > The resulting changes could appear as follows: >=20 > OLD > The IETF Administration Limited Liability Company (IETF LLC), as part = of the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The = IASA is tasked with providing the funding for and operational oversight = of the RFC Editor. >=20 > The IETF LLC Board provides oversight of the IASA, and the IETF = Executive Director is the chief actor for the IASA. >=20 > The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor. >=20 > NEW > The IETF Administration Limited Liability Company (IETF LLC), as part = of the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA = is tasked with providing the funding for the RFC Editor. The IASA, the = IAB, and the RFC Series Oversight Committee (RSOC) provide operational = oversight of the RFC Editor. >=20 > Oh, boy, operational oversite from 3 independent bodies! Sounds like = serving 3 masters, and two is already discouraged in most literature. >=20 > The original intent was to make the distinction between oversight of = substantive matters (which fell to the IAB, and now its delegate, the = RSOC) and contractual, day-to-day matters, which falls to the admin side = of the house. >=20 > I think we need to continue to make some version of that distinction = (and, evidently clearer than it was originally written). >=20 > I also note that the original text, convoluted as it had become, made = the IAD/IETF Executive Director, in charge of those contracts. If we = simply say =E2=80=9Cthe IASA=E2=80=9D, we introduce an infelicitous = fourth potential oversight body, in the shape of the IASA LLC Board. = There is nothing in this setup that rises to the level of the = involvement of the IASA LLC Board, except in its normal oversight of the = exec dir. >=20 > Straw text: >=20 > The IETF Administration Limited Liability Company (IETF LLC), as part > of the IETF Administrative Support Activity (IASA), is responsible > for administrative and financial matters for the IETF, the IAB, and > the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. > The IASA is tasked with providing the funding for the RFC Editor. The = IASA (through the IETF Executive Director) provides contractual and = financial oversight of the RFC Editor. Additionally, as described in = Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], > RFC Series Oversight Committee (RSOC), acting with authority > delegated from the IAB, is responsible for ensuring that the RFC > Series is run in a transparent and accountable manner, including > design and execution of the RFC Series Editor selection process. >=20 > The IETF Executive Director works with the IAB to identify suitable > persons or entities to fulfill the mandate of the RFC Production > Center and the RFC Publisher roles as defined in > [I-D.ietf-iasa2-rfc6635bis]. >=20 > Leslie. >=20 > The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor. >=20 > The RSOC is not otherwise mentioned in this document, so to bring the = RSOC into this discussion, I think a bit more context is needed. I = suggest: >=20 > The IETF Administration Limited Liability Company (IETF LLC), as part > of the IETF Administrative Support Activity (IASA), is responsible > for administrative and financial matters for the IETF, the IAB, and > the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. > The IASA is tasked with providing the funding for the RFC Editor. > The IASA and the IAB provide operational oversight of the RFC Editor; > however, as described in Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], > RFC Series Oversight Committee (RSOC), acting with authority > delegated from the IAB, is responsible for ensuring that the RFC > Series is run in a transparent and accountable manner, including > design and execution of the RFC Series Editor selection process. >=20 > The IETF Executive Director works with the IAB to identify suitable > persons or entities to fulfill the mandate of the RFC Production > Center and the RFC Publisher roles as defined in > [I-D.ietf-iasa2-rfc6635bis]. >=20 >=20 > Section 7: >=20 > I would suggest the following to make the text consistent with = rfc4071bis Sec. 4.2: >=20 > OLD > Under the new structure, the IETF LLC performs the tasks that were > previously assigned to the IETF Administrative Oversight Committee > (IAOC) under the old structure. >=20 > NEW > Under the new structure, the IETF LLC performs the tasks related to = IASA that were > previously assigned to the IETF Administrative Director and to the = Internet Society. >=20 > Sure. That is an improvement. >=20 > Russ >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss = > -- >=20 > Leslie Daigle > Principal, ThinkingCat Enterprises >=20 > ldaigle@thinkingcat.com --Apple-Mail=_3AC9063A-F567-4745-9FC7-E20DF944C6B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Leslie:

Works for me.  

Russ


On Oct 15, 2019, at 10:09 AM, Leslie Daigle <ldaigle@thinkingcat.com> wrote:

I = agree that the second point is improved wording.

However on the first point, while I agree a rewrite is in = order, I think Alissa=E2=80=99s suggested text, and your refinements, = are taking us a bit off track.

In-line:

On 14 Oct 2019, at = 15:45, Russ Housley wrote:

Alissa:

Section 3.3:

The first paragraph of this section fails to mention the IAB and RSOC, = which according to RFC 6635 have oversight roles. It seems incorrect to = claim that operational oversight is solely the responsibility of = IASA.

The second paragraph is superfluous since the roles of the LLC Board and = ED are defined in rfc4071bis, so I think for clarity it should be = removed.

The resulting changes could appear as follows:

OLD
The IETF Administration Limited Liability Company (IETF LLC), as part of = the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The = IASA is tasked with providing the funding for and operational oversight = of the RFC Editor.

The IETF LLC Board provides oversight of the IASA, and the IETF = Executive Director is the chief actor for the IASA.

The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor.

NEW
The IETF Administration Limited Liability Company (IETF LLC), as part of = the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA = is tasked with providing the funding for the RFC Editor. The IASA, the = IAB, and the RFC Series Oversight Committee (RSOC) provide operational = oversight of the RFC Editor.

Oh, boy, operational oversite from 3 independent bodies! = Sounds like serving 3 masters, and two is already discouraged in most = literature.

The original intent was to = make the distinction between oversight of substantive matters (which = fell to the IAB, and now its delegate, the RSOC) and contractual, = day-to-day matters, which falls to the admin side of the house.

I think we need to continue to make some version = of that distinction (and, evidently clearer than it was originally = written).

I also note that the original = text, convoluted as it had become, made the IAD/IETF Executive Director, = in charge of those contracts. If we simply say =E2=80=9Cthe IASA=E2=80=9D= , we introduce an infelicitous fourth potential oversight body, in the = shape of the IASA LLC Board. There is nothing in this setup that rises = to the level of the involvement of the IASA LLC Board, except in its = normal oversight of the exec dir.

Straw = text:

The IETF Administration Limited = Liability Company (IETF LLC), as part
of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, = and
the Internet Research Task Force (IRTF) = [I-D.ietf-iasa2-rfc4071bis].
The IASA is tasked with providing the funding for the RFC Editor. = The IASA (through the IETF Executive Director) provides contractual and = financial oversight of the RFC Editor. Additionally, as described in = Section 3.1 of [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection = process.

The IETF Executive Director works = with the IAB to identify suitable
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Leslie.

The IETF = Executive Director works with the IAB to identify suitable persons or = entities to fulfill the mandate of the RFC Editor.

The RSOC is not otherwise = mentioned in this document, so to bring the RSOC into this discussion, I = think a bit more context is needed. I suggest:

The IETF Administration Limited Liability Company (IETF LLC), as = part
of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, = and
the Internet Research Task Force (IRTF) = [I-D.ietf-iasa2-rfc4071bis].
The IASA is tasked with providing the funding for the RFC Editor.
The IASA and the IAB provide operational oversight of the RFC = Editor;
however, as described in Section 3.1 of = [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection process.

The IETF Executive Director works with the IAB to identify = suitable
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Section 7:

I would suggest the following to make the text consistent with = rfc4071bis Sec. 4.2:

OLD
Under the new structure, the IETF LLC performs the tasks that were
previously assigned to the IETF Administrative Oversight Committee
(IAOC) under the old structure.

NEW
Under the new structure, the IETF LLC performs the tasks related to = IASA that were
previously assigned to the IETF Administrative Director and to the = Internet Society.

Sure. That is an = improvement.

Russ

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss<= /p>

--=

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com


= --Apple-Mail=_3AC9063A-F567-4745-9FC7-E20DF944C6B1-- From nobody Tue Oct 15 10:25:25 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FB012083A for ; Tue, 15 Oct 2019 10:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=l4h3/arS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=croJftjt 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 b3FKI80HJLUr for ; Tue, 15 Oct 2019 10:25:10 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8494120808 for ; Tue, 15 Oct 2019 10:25:09 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id F1BE372D; Tue, 15 Oct 2019 13:25:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 15 Oct 2019 13:25:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=8Tnr5t3j/0LXRLS421gQkLb dtBjHp70h+CJHX0EPT+o=; b=l4h3/arSZ7oHAVHPsJg05frKIJQ5foTlmZ7Fgmi D3+V1+N3sZd+4xyp9J9STKbLbfpLziMFt8kilZsAx7tz6cVnxAta0jyg4OsCtDyt on+74/tSLcs4mNIVbQ/c5V0pu3rNdxvE0KLj1k6uFVH9LgWqOuts6NwKqnE3a4ER 3vTlaJ+DQeZ/9c/JzvbctYPfsOHR/WlRwhpC7K3imuzNOr2+4uQb71gerys42evt LOj3CKN1f/MUIgEGx1Gh/gvOujKdlcY9S1xH1dIw85rChzCHQNu9mheMROKF/+lv +lDjTO425dnWcNpx2ndFzUTkNAs+qK5vkLTzuAiIrjjqmSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8Tnr5t 3j/0LXRLS421gQkLbdtBjHp70h+CJHX0EPT+o=; b=croJftjtvCD1byyYgx/9ZS JrWyD3Uw7/lRnnKhbppsz3VItgtEZec7w3mIhkyyljC8MWldkNEU+/GhPpqHSrz+ DSyJZ8E/UiW07A1f7NSkoFrlu+47EKa6rF+pfu+p+MxzC5N0nCRyce4E4cZ4tHAp YSvdjwQxNf5sguqleWTkDWDlSqJtCigF3iqATpGzcRpeaCZdCl7GsTb/+THIDZAA 7plqlryu4fvLhjA0hOMX88HQqpHKpN41ehq/LRr2tSGkIyk7NVRNIQkIhaycn8d5 qyaVGz/lFUvgciPwtCeutaZNKIny2mlE+OB7v++65/qZqOkZ651PwOEDXaIan5tA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeefgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekfeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro3.cisco.com (unknown [173.38.117.83]) by mail.messagingengine.com (Postfix) with ESMTPA id CC36BD60066; Tue, 15 Oct 2019 13:25:06 -0400 (EDT) From: Alissa Cooper Message-Id: <9B58D313-3DF5-485E-92AD-9DDA1B9BACE5@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_461DBE85-464B-4AD0-85EB-3470200B15DC" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 15 Oct 2019 13:25:05 -0400 In-Reply-To: <5614790E-8498-4546-8585-3171EB3C722B@vigilsec.com> Cc: Leslie Daigle , IAB , architecture-discuss@ietf.org To: Russ Housley References: <156763101565.22770.5246009160641276406.idtracker@ietfa.amsl.com> <281D3BF8-CE5E-46D3-B4F4-F0289606C308@cooperw.in> <33B6BD0C-260B-4061-A188-58CD1CA44535@vigilsec.com> <8B086B3F-5630-43BF-91E2-6747EE75EC03@thinkingcat.com> <5614790E-8498-4546-8585-3171EB3C722B@vigilsec.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [arch-d] Call for Comment: (The RFC Series and RFC Editor) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 17:25:24 -0000 --Apple-Mail=_461DBE85-464B-4AD0-85EB-3470200B15DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 WFM Alissa > On Oct 15, 2019, at 12:22 PM, Russ Housley = wrote: >=20 > Leslie: >=20 > Works for me. =20 >=20 > Russ >=20 >=20 >> On Oct 15, 2019, at 10:09 AM, Leslie Daigle > wrote: >>=20 >> I agree that the second point is improved wording. >>=20 >> However on the first point, while I agree a rewrite is in order, I = think Alissa=E2=80=99s suggested text, and your refinements, are taking = us a bit off track. >>=20 >> In-line: >>=20 >> On 14 Oct 2019, at 15:45, Russ Housley wrote: >>=20 >> Alissa: >> Section 3.3: >>=20 >> The first paragraph of this section fails to mention the IAB and = RSOC, which according to RFC 6635 have oversight roles. It seems = incorrect to claim that operational oversight is solely the = responsibility of IASA. >>=20 >> The second paragraph is superfluous since the roles of the LLC Board = and ED are defined in rfc4071bis, so I think for clarity it should be = removed. >>=20 >> The resulting changes could appear as follows: >>=20 >> OLD >> The IETF Administration Limited Liability Company (IETF LLC), as part = of the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The = IASA is tasked with providing the funding for and operational oversight = of the RFC Editor. >>=20 >> The IETF LLC Board provides oversight of the IASA, and the IETF = Executive Director is the chief actor for the IASA. >>=20 >> The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor. >>=20 >> NEW >> The IETF Administration Limited Liability Company (IETF LLC), as part = of the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA = is tasked with providing the funding for the RFC Editor. The IASA, the = IAB, and the RFC Series Oversight Committee (RSOC) provide operational = oversight of the RFC Editor. >>=20 >> Oh, boy, operational oversite from 3 independent bodies! Sounds like = serving 3 masters, and two is already discouraged in most literature. >>=20 >> The original intent was to make the distinction between oversight of = substantive matters (which fell to the IAB, and now its delegate, the = RSOC) and contractual, day-to-day matters, which falls to the admin side = of the house. >>=20 >> I think we need to continue to make some version of that distinction = (and, evidently clearer than it was originally written). >>=20 >> I also note that the original text, convoluted as it had become, made = the IAD/IETF Executive Director, in charge of those contracts. If we = simply say =E2=80=9Cthe IASA=E2=80=9D, we introduce an infelicitous = fourth potential oversight body, in the shape of the IASA LLC Board. = There is nothing in this setup that rises to the level of the = involvement of the IASA LLC Board, except in its normal oversight of the = exec dir. >>=20 >> Straw text: >>=20 >> The IETF Administration Limited Liability Company (IETF LLC), as part >> of the IETF Administrative Support Activity (IASA), is responsible >> for administrative and financial matters for the IETF, the IAB, and >> the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. >> The IASA is tasked with providing the funding for the RFC Editor. The = IASA (through the IETF Executive Director) provides contractual and = financial oversight of the RFC Editor. Additionally, as described in = Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], >> RFC Series Oversight Committee (RSOC), acting with authority >> delegated from the IAB, is responsible for ensuring that the RFC >> Series is run in a transparent and accountable manner, including >> design and execution of the RFC Series Editor selection process. >>=20 >> The IETF Executive Director works with the IAB to identify suitable >> persons or entities to fulfill the mandate of the RFC Production >> Center and the RFC Publisher roles as defined in >> [I-D.ietf-iasa2-rfc6635bis]. >>=20 >> Leslie. >>=20 >> The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor. >>=20 >> The RSOC is not otherwise mentioned in this document, so to bring the = RSOC into this discussion, I think a bit more context is needed. I = suggest: >>=20 >> The IETF Administration Limited Liability Company (IETF LLC), as part >> of the IETF Administrative Support Activity (IASA), is responsible >> for administrative and financial matters for the IETF, the IAB, and >> the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. >> The IASA is tasked with providing the funding for the RFC Editor. >> The IASA and the IAB provide operational oversight of the RFC Editor; >> however, as described in Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], >> RFC Series Oversight Committee (RSOC), acting with authority >> delegated from the IAB, is responsible for ensuring that the RFC >> Series is run in a transparent and accountable manner, including >> design and execution of the RFC Series Editor selection process. >>=20 >> The IETF Executive Director works with the IAB to identify suitable >> persons or entities to fulfill the mandate of the RFC Production >> Center and the RFC Publisher roles as defined in >> [I-D.ietf-iasa2-rfc6635bis]. >>=20 >> Section 7: >>=20 >> I would suggest the following to make the text consistent with = rfc4071bis Sec. 4.2: >>=20 >> OLD >> Under the new structure, the IETF LLC performs the tasks that were >> previously assigned to the IETF Administrative Oversight Committee >> (IAOC) under the old structure. >>=20 >> NEW >> Under the new structure, the IETF LLC performs the tasks related to = IASA that were >> previously assigned to the IETF Administrative Director and to the = Internet Society. >>=20 >> Sure. That is an improvement. >>=20 >> Russ >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss = >> -- >>=20 >> Leslie Daigle >> Principal, ThinkingCat Enterprises >>=20 >> ldaigle@thinkingcat.com --Apple-Mail=_461DBE85-464B-4AD0-85EB-3470200B15DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 WFM
Alissa

On Oct = 15, 2019, at 12:22 PM, Russ Housley <housley@vigilsec.com> wrote:

Leslie:

Works for me. =  

Russ


On Oct = 15, 2019, at 10:09 AM, Leslie Daigle <ldaigle@thinkingcat.com> wrote:

I = agree that the second point is improved wording.

However on the first point, while I agree a rewrite is in = order, I think Alissa=E2=80=99s suggested text, and your refinements, = are taking us a bit off track.

In-line:

On 14 Oct 2019, at = 15:45, Russ Housley wrote:

Alissa:

Section 3.3:

The first paragraph of this section fails to mention the IAB and RSOC, = which according to RFC 6635 have oversight roles. It seems incorrect to = claim that operational oversight is solely the responsibility of = IASA.

The second paragraph is superfluous since the roles of the LLC Board and = ED are defined in rfc4071bis, so I think for clarity it should be = removed.

The resulting changes could appear as follows:

OLD
The IETF Administration Limited Liability Company (IETF LLC), as part of = the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The = IASA is tasked with providing the funding for and operational oversight = of the RFC Editor.

The IETF LLC Board provides oversight of the IASA, and the IETF = Executive Director is the chief actor for the IASA.

The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor.

NEW
The IETF Administration Limited Liability Company (IETF LLC), as part of = the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA = is tasked with providing the funding for the RFC Editor. The IASA, the = IAB, and the RFC Series Oversight Committee (RSOC) provide operational = oversight of the RFC Editor.

Oh, boy, operational oversite from 3 independent bodies! = Sounds like serving 3 masters, and two is already discouraged in most = literature.

The original intent was to = make the distinction between oversight of substantive matters (which = fell to the IAB, and now its delegate, the RSOC) and contractual, = day-to-day matters, which falls to the admin side of the house.

I think we need to continue to make some version = of that distinction (and, evidently clearer than it was originally = written).

I also note that the original = text, convoluted as it had become, made the IAD/IETF Executive Director, = in charge of those contracts. If we simply say =E2=80=9Cthe IASA=E2=80=9D= , we introduce an infelicitous fourth potential oversight body, in the = shape of the IASA LLC Board. There is nothing in this setup that rises = to the level of the involvement of the IASA LLC Board, except in its = normal oversight of the exec dir.

Straw = text:

The IETF Administration Limited = Liability Company (IETF LLC), as part
of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, = and
the Internet Research Task Force (IRTF) = [I-D.ietf-iasa2-rfc4071bis].
The IASA is tasked with providing the funding for the RFC Editor. = The IASA (through the IETF Executive Director) provides contractual and = financial oversight of the RFC Editor. Additionally, as described in = Section 3.1 of [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection = process.

The IETF Executive Director works = with the IAB to identify suitable
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Leslie.

The IETF = Executive Director works with the IAB to identify suitable persons or = entities to fulfill the mandate of the RFC Editor.

The RSOC is not otherwise = mentioned in this document, so to bring the RSOC into this discussion, I = think a bit more context is needed. I suggest:

The IETF Administration Limited Liability Company (IETF LLC), as = part
of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, = and
the Internet Research Task Force (IRTF) = [I-D.ietf-iasa2-rfc4071bis].
The IASA is tasked with providing the funding for the RFC Editor.
The IASA and the IAB provide operational oversight of the RFC = Editor;
however, as described in Section 3.1 of = [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection process.

The IETF Executive Director works with the IAB to identify = suitable
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Section 7:

I would suggest the following to make the text consistent with = rfc4071bis Sec. 4.2:

OLD
Under the new structure, the IETF LLC performs the tasks that were
previously assigned to the IETF Administrative Oversight Committee
(IAOC) under the old structure.

NEW
Under the new structure, the IETF LLC performs the tasks related to = IASA that were
previously assigned to the IETF Administrative Director and to the = Internet Society.

Sure. That is an = improvement.

Russ

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss<= /p>

--=

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com



= --Apple-Mail=_461DBE85-464B-4AD0-85EB-3470200B15DC-- From nobody Tue Oct 15 10:57:46 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C301201C6 for ; Tue, 15 Oct 2019 10:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EIuDSnj4sTfL for ; Tue, 15 Oct 2019 10:57:41 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC28120808 for ; Tue, 15 Oct 2019 10:57:41 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id w12so47958967iol.11 for ; Tue, 15 Oct 2019 10:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ASlOPtele9g4BZgyVjhC/J0RIuu2wSgICSGHVjcm2Vw=; b=AhUG6xUCTesF6RUoMFkRE+qf5V8zbqoXL+1HJWsJPZExfE59wn4u3wwt5d1QTADO7C Dc05egzRTKyp1r7D17sfCcJqGlXqS9yx1Br2sB5Y8IhyD94+PUrk8NMgamAIMzxn4dUE 8eZDWmppzoUBiV0LmqXKcEtP9EJw0g7IimPHea5GQyIZilAiIVDwBlM4u04YMT6G1jCn BlKRHKBsFn5e5k/xAY1eHgdtvfqrooEe6fWSlEAGpL3uV1m3VzXxdWeVNcMcezw+RTYI 5fZprBjCOAe2n0NWZVgWluT60Zb+vF35IrKX6B3V2lDkINLp9cBKM0uucM1iJqWZXmye GR5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ASlOPtele9g4BZgyVjhC/J0RIuu2wSgICSGHVjcm2Vw=; b=j7ZvYftQTRFYFVoxHpXAzidjvzDmLTw0sbvFe8HtKkWlGey/um6+WEV7WlQWkG2n9b tbwKN9cpqxiChCTSfpHiQMkBTcWU8AGGfDbdfQ1+RvVbC5Lld4auVqZMhfq2hmWcciOs CKWO91YSWbkSdOF7vnQ1czFM3jJBMChdCdtPW7gd2k5Hg98SvdsHIlhki2uguCVsL9HO vBS8uUZwmg/GUVe1e1iTUY6DP/vt89FNPdfDE4wjfxSagLedNz5+qIho86dRKflLxAiF 0MkZPgC3wgVz4YTtkdehqT5+45iM0B9B8ZGa3+h2C9eEYHa407U6En5tgxoN/iCmL2To 7fcA== X-Gm-Message-State: APjAAAUh28/hYSJyboLFYvWnpiw0tEqoLKQ4Zanlv6ujIdhnpUBQiK1y mfYfWew90QwQ6s6BfWKPnAQbUz310JFjYoJMA28= X-Google-Smtp-Source: APXvYqzxV3Ze2Wx7PNz2HA4W7Usrw/liyamr5TpObgLe/WdRJok1lumSoMZKAEQvTMcU7awotThWhOjAtrHVHd7CZ5k= X-Received: by 2002:a6b:ce03:: with SMTP id p3mr6505958iob.290.1571162260722; Tue, 15 Oct 2019 10:57:40 -0700 (PDT) MIME-Version: 1.0 References: <156763101565.22770.5246009160641276406.idtracker@ietfa.amsl.com> <281D3BF8-CE5E-46D3-B4F4-F0289606C308@cooperw.in> <33B6BD0C-260B-4061-A188-58CD1CA44535@vigilsec.com> <8B086B3F-5630-43BF-91E2-6747EE75EC03@thinkingcat.com> <5614790E-8498-4546-8585-3171EB3C722B@vigilsec.com> <9B58D313-3DF5-485E-92AD-9DDA1B9BACE5@cooperw.in> In-Reply-To: <9B58D313-3DF5-485E-92AD-9DDA1B9BACE5@cooperw.in> From: Ted Hardie Date: Tue, 15 Oct 2019 10:57:13 -0700 Message-ID: To: Alissa Cooper Cc: Russ Housley , Leslie Daigle , IAB , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000006f5a840594f6b860" Archived-At: Subject: Re: [arch-d] [IAB] Call for Comment: (The RFC Series and RFC Editor) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 17:57:45 -0000 --0000000000006f5a840594f6b860 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Russ, If everyone is okay with this text, can you update the draft? I'll bring it to an IAB meeting (probably week after next, but possible the one after that, depending on the other agenda items). thanks, Ted On Tue, Oct 15, 2019 at 10:25 AM Alissa Cooper wrote: > WFM > Alissa > > On Oct 15, 2019, at 12:22 PM, Russ Housley wrote: > > Leslie: > > Works for me. > > Russ > > > On Oct 15, 2019, at 10:09 AM, Leslie Daigle > wrote: > > I agree that the second point is improved wording. > > However on the first point, while I agree a rewrite is in order, I think > Alissa=E2=80=99s suggested text, and your refinements, are taking us a bi= t off > track. > > In-line: > > On 14 Oct 2019, at 15:45, Russ Housley wrote: > > Alissa: > > Section 3.3: > > The first paragraph of this section fails to mention the IAB and RSOC, > which according to RFC 6635 have oversight roles. It seems incorrect to > claim that operational oversight is solely the responsibility of IASA. > > The second paragraph is superfluous since the roles of the LLC Board and > ED are defined in rfc4071bis, so I think for clarity it should be removed= . > > The resulting changes could appear as follows: > > OLD > The IETF Administration Limited Liability Company (IETF LLC), as part of > the IETF Administrative Support Activity (IASA), is responsible for > administrative and financial matters for the IETF, the IAB, and the > Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The IASA > is tasked with providing the funding for and operational oversight of the > RFC Editor. > > The IETF LLC Board provides oversight of the IASA, and the IETF Executive > Director is the chief actor for the IASA. > > The IETF Executive Director works with the IAB to identify suitable > persons or entities to fulfill the mandate of the RFC Editor. > > NEW > The IETF Administration Limited Liability Company (IETF LLC), as part of > the IETF Administrative Support Activity (IASA), is responsible for > administrative and financial matters for the IETF, the IAB, and the > Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA = is > tasked with providing the funding for the RFC Editor. The IASA, the IAB, > and the RFC Series Oversight Committee (RSOC) provide operational oversig= ht > of the RFC Editor. > > Oh, boy, operational oversite from 3 independent bodies! Sounds like > serving 3 masters, and two is already discouraged in most literature. > > The original intent was to make the distinction between oversight of > substantive matters (which fell to the IAB, and now its delegate, the RSO= C) > and contractual, day-to-day matters, which falls to the admin side of the > house. > > I think we need to continue to make some version of that distinction (and= , > evidently clearer than it was originally written). > > I also note that the original text, convoluted as it had become, made the > IAD/IETF Executive Director, in charge of those contracts. If we simply s= ay > =E2=80=9Cthe IASA=E2=80=9D, we introduce an infelicitous fourth potential= oversight body, > in the shape of the IASA LLC Board. There is nothing in this setup that > rises to the level of the involvement of the IASA LLC Board, except in it= s > normal oversight of the exec dir. > > Straw text: > > The IETF Administration Limited Liability Company (IETF LLC), as part > of the IETF Administrative Support Activity (IASA), is responsible > for administrative and financial matters for the IETF, the IAB, and > the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. > The IASA is tasked with providing the funding for the RFC Editor. The IAS= A > (through the IETF Executive Director) provides contractual and financial > oversight of the RFC Editor. Additionally, as described in Section 3.1 of > [I-D.ietf-iasa2-rfc6635bis], > RFC Series Oversight Committee (RSOC), acting with authority > delegated from the IAB, is responsible for ensuring that the RFC > Series is run in a transparent and accountable manner, including > design and execution of the RFC Series Editor selection process. > > The IETF Executive Director works with the IAB to identify suitable > persons or entities to fulfill the mandate of the RFC Production > Center and the RFC Publisher roles as defined in > [I-D.ietf-iasa2-rfc6635bis]. > > Leslie. > > The IETF Executive Director works with the IAB to identify suitable > persons or entities to fulfill the mandate of the RFC Editor. > > The RSOC is not otherwise mentioned in this document, so to bring the RSO= C > into this discussion, I think a bit more context is needed. I suggest: > > The IETF Administration Limited Liability Company (IETF LLC), as part > of the IETF Administrative Support Activity (IASA), is responsible > for administrative and financial matters for the IETF, the IAB, and > the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. > The IASA is tasked with providing the funding for the RFC Editor. > The IASA and the IAB provide operational oversight of the RFC Editor; > however, as described in Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], > RFC Series Oversight Committee (RSOC), acting with authority > delegated from the IAB, is responsible for ensuring that the RFC > Series is run in a transparent and accountable manner, including > design and execution of the RFC Series Editor selection process. > > The IETF Executive Director works with the IAB to identify suitable > persons or entities to fulfill the mandate of the RFC Production > Center and the RFC Publisher roles as defined in > [I-D.ietf-iasa2-rfc6635bis]. > > Section 7: > > I would suggest the following to make the text consistent with rfc4071bis > Sec. 4.2: > > OLD > Under the new structure, the IETF LLC performs the tasks that were > previously assigned to the IETF Administrative Oversight Committee > (IAOC) under the old structure. > > NEW > Under the new structure, the IETF LLC performs the tasks related to IASA > that were > previously assigned to the IETF Administrative Director and to the > Internet Society. > > Sure. That is an improvement. > > Russ > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- > ------------------------------ > > Leslie Daigle > Principal, ThinkingCat Enterprises > ldaigle@thinkingcat.com > > > > --0000000000006f5a840594f6b860 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,

If everyone is okay= with this text, can you update the draft?=C2=A0 I'll bring it to an IA= B meeting (probably week after next, but possible the one after that, depen= ding on the other agenda items).

thanks,

Ted

On Tue, Oct 15, 2019 at 10:25 AM Alissa Coope= r <alissa@cooperw.in> wrote:=
WFM
Alissa

On Oct 15, 2019, at 12:22 PM, Russ Housley <housley@vigilsec.com> wrote:=

Leslie:

Works for me. =C2=A0

Russ

<= div>
On Oct 15, 2019, at 10:09 AM, Leslie= Daigle <ld= aigle@thinkingcat.com> wrote:

I agree that the second point is improved wording.

However on the first point, while I agree a rewrite is in order, = I think Alissa=E2=80=99s suggested text, and your refinements, are taking u= s a bit off track.

In-line:

On 14 Oct= 2019, at 15:45, Russ Housley wrote:

Alissa:

Section 3.3:
The first paragraph of this section fails to mention the IAB and RSOC, whic= h according to RFC 6635 have oversight roles. It seems incorrect to claim t= hat operational oversight is solely the responsibility of IASA.

The second paragraph is superfluous since the roles of the LLC Board and ED= are defined in rfc4071bis, so I think for clarity it should be removed.
The resulting changes could appear as follows:

OLD
The IETF Administration Limited Liability Company (IETF LLC), as part of th= e IETF Administrative Support Activity (IASA), is responsible for administr= ative and financial matters for the IETF, the IAB, and the Internet Researc= h Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The IASA is tasked with pr= oviding the funding for and operational oversight of the RFC Editor.

The IETF LLC Board provides oversight of the IASA, and the IETF Executive D= irector is the chief actor for the IASA.

The IETF Executive Director works with the IAB to identify suitable persons= or entities to fulfill the mandate of the RFC Editor.

NEW
The IETF Administration Limited Liability Company (IETF LLC), as part of th= e IETF Administrative Support Activity (IASA), is responsible for administr= ative and financial matters for the IETF, the IAB, and the Internet Researc= h Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA is tasked with pro= viding the funding for the RFC Editor. The IASA, the IAB, and the RFC Serie= s Oversight Committee (RSOC) provide operational oversight of the RFC Edito= r.

Oh, boy, operational over= site from 3 independent bodies! Sounds like serving 3 masters, and two is= already discouraged in most literature.

The original in= tent was to make the distinction between oversight of substantive matters (= which fell to the IAB, and now its delegate, the RSOC) and contractual, day= -to-day matters, which falls to the admin side of the house.

I think we need to continue to make some version of that distinction (= and, evidently clearer than it was originally written).

I also note that the original text, convoluted as it had become, made the= IAD/IETF Executive Director, in charge of those contracts. If we simply s= ay =E2=80=9Cthe IASA=E2=80=9D, we introduce an infelicitous fourth potentia= l oversight body, in the shape of the IASA LLC Board. There is nothing in = this setup that rises to the level of the involvement of the IASA LLC Board= , except in its normal oversight of the exec dir.

Straw = text:

The IETF Administration Limited Liability Company = (IETF LLC), as part
of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, and
the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].
The IASA is tasked with providing the funding for the RFC Editor. The I= ASA (through the IETF Executive Director) provides contractual and financia= l oversight of the RFC Editor. Additionally, as described in Section 3.1 o= f [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection process.

The IETF Executive Director works with the IAB to identify suit= able
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

=

Leslie.

The IETF E= xecutive Director works with the IAB to identify suitable persons or entiti= es to fulfill the mandate of the RFC Editor.

The RSOC is not otherwise mentioned in this do= cument, so to bring the RSOC into this discussion, I think a bit more conte= xt is needed. I suggest:

The IETF Administration Limited Liability Company (IETF LLC), as part of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, and
the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].
The IASA is tasked with providing the funding for the RFC Editor.
The IASA and the IAB provide operational oversight of the RFC Editor; however, as described in Section 3.1 of [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection process.

The IETF Executive Director works with the IAB to identify suitable
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Section 7:

I would suggest the following to make the text consistent with rfc4071bis S= ec. 4.2:

OLD
Under the new structure, the IETF LLC performs the tasks that were
previously assigned to the IETF Administrative Oversight Committee
(IAOC) under the old structure.

NEW
Under the new structure, the IETF LLC performs the tasks related to IASA = that were
previously assigned to the IETF Administrative Director and to the Intern= et Society.

Sure. That is an improvement.

Russ

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman= /listinfo/architecture-discuss

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com=



--0000000000006f5a840594f6b860-- From nobody Tue Oct 15 12:19:25 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBF7120864 for ; Tue, 15 Oct 2019 12:19:13 -0700 (PDT) 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 QU3vaEYwNJ2P for ; Tue, 15 Oct 2019 12:19:09 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A3B120879 for ; Tue, 15 Oct 2019 12:19:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1D411300B21 for ; Tue, 15 Oct 2019 15:19:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ogg0-lWCViiZ for ; Tue, 15 Oct 2019 15:19:02 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id B24E73005D7; Tue, 15 Oct 2019 15:19:02 -0400 (EDT) From: Russ Housley Message-Id: <81A22F8B-EBC5-47B1-B70A-5996BAF047DA@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6DBE2C21-00A3-480A-B2CA-B2245203D682" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 15 Oct 2019 15:19:03 -0400 In-Reply-To: Cc: Alissa Cooper , Leslie Daigle , IAB , architecture-discuss@ietf.org To: Ted Hardie References: <156763101565.22770.5246009160641276406.idtracker@ietfa.amsl.com> <281D3BF8-CE5E-46D3-B4F4-F0289606C308@cooperw.in> <33B6BD0C-260B-4061-A188-58CD1CA44535@vigilsec.com> <8B086B3F-5630-43BF-91E2-6747EE75EC03@thinkingcat.com> <5614790E-8498-4546-8585-3171EB3C722B@vigilsec.com> <9B58D313-3DF5-485E-92AD-9DDA1B9BACE5@cooperw.in> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] [IAB] Call for Comment: (The RFC Series and RFC Editor) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 19:19:23 -0000 --Apple-Mail=_6DBE2C21-00A3-480A-B2CA-B2245203D682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Done. I just posted -04. Russ > On Oct 15, 2019, at 1:57 PM, Ted Hardie wrote: >=20 > Hi Russ, >=20 > If everyone is okay with this text, can you update the draft? I'll = bring it to an IAB meeting (probably week after next, but possible the = one after that, depending on the other agenda items). >=20 > thanks, >=20 > Ted >=20 > On Tue, Oct 15, 2019 at 10:25 AM Alissa Cooper > wrote: > WFM > Alissa >=20 >> On Oct 15, 2019, at 12:22 PM, Russ Housley > wrote: >>=20 >> Leslie: >>=20 >> Works for me. =20 >>=20 >> Russ >>=20 >>=20 >>> On Oct 15, 2019, at 10:09 AM, Leslie Daigle > wrote: >>>=20 >>> I agree that the second point is improved wording. >>>=20 >>> However on the first point, while I agree a rewrite is in order, I = think Alissa=E2=80=99s suggested text, and your refinements, are taking = us a bit off track. >>>=20 >>> In-line: >>>=20 >>> On 14 Oct 2019, at 15:45, Russ Housley wrote: >>>=20 >>> Alissa: >>>=20 >>> Section 3.3: >>>=20 >>> The first paragraph of this section fails to mention the IAB and = RSOC, which according to RFC 6635 have oversight roles. It seems = incorrect to claim that operational oversight is solely the = responsibility of IASA. >>>=20 >>> The second paragraph is superfluous since the roles of the LLC Board = and ED are defined in rfc4071bis, so I think for clarity it should be = removed. >>>=20 >>> The resulting changes could appear as follows: >>>=20 >>> OLD >>> The IETF Administration Limited Liability Company (IETF LLC), as = part of the IETF Administrative Support Activity (IASA), is responsible = for administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The = IASA is tasked with providing the funding for and operational oversight = of the RFC Editor. >>>=20 >>> The IETF LLC Board provides oversight of the IASA, and the IETF = Executive Director is the chief actor for the IASA. >>>=20 >>> The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor. >>>=20 >>> NEW >>> The IETF Administration Limited Liability Company (IETF LLC), as = part of the IETF Administrative Support Activity (IASA), is responsible = for administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA = is tasked with providing the funding for the RFC Editor. The IASA, the = IAB, and the RFC Series Oversight Committee (RSOC) provide operational = oversight of the RFC Editor. >>>=20 >>> Oh, boy, operational oversite from 3 independent bodies! Sounds like = serving 3 masters, and two is already discouraged in most literature. >>>=20 >>> The original intent was to make the distinction between oversight of = substantive matters (which fell to the IAB, and now its delegate, the = RSOC) and contractual, day-to-day matters, which falls to the admin side = of the house. >>>=20 >>> I think we need to continue to make some version of that distinction = (and, evidently clearer than it was originally written). >>>=20 >>> I also note that the original text, convoluted as it had become, = made the IAD/IETF Executive Director, in charge of those contracts. If = we simply say =E2=80=9Cthe IASA=E2=80=9D, we introduce an infelicitous = fourth potential oversight body, in the shape of the IASA LLC Board. = There is nothing in this setup that rises to the level of the = involvement of the IASA LLC Board, except in its normal oversight of the = exec dir. >>>=20 >>> Straw text: >>>=20 >>> The IETF Administration Limited Liability Company (IETF LLC), as = part >>> of the IETF Administrative Support Activity (IASA), is responsible >>> for administrative and financial matters for the IETF, the IAB, and >>> the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. >>> The IASA is tasked with providing the funding for the RFC Editor. = The IASA (through the IETF Executive Director) provides contractual and = financial oversight of the RFC Editor. Additionally, as described in = Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], >>> RFC Series Oversight Committee (RSOC), acting with authority >>> delegated from the IAB, is responsible for ensuring that the RFC >>> Series is run in a transparent and accountable manner, including >>> design and execution of the RFC Series Editor selection process. >>>=20 >>> The IETF Executive Director works with the IAB to identify suitable >>> persons or entities to fulfill the mandate of the RFC Production >>> Center and the RFC Publisher roles as defined in >>> [I-D.ietf-iasa2-rfc6635bis]. >>>=20 >>> Leslie. >>>=20 >>> The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor. >>>=20 >>> The RSOC is not otherwise mentioned in this document, so to bring = the RSOC into this discussion, I think a bit more context is needed. I = suggest: >>>=20 >>> The IETF Administration Limited Liability Company (IETF LLC), as = part >>> of the IETF Administrative Support Activity (IASA), is responsible >>> for administrative and financial matters for the IETF, the IAB, and >>> the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. >>> The IASA is tasked with providing the funding for the RFC Editor. >>> The IASA and the IAB provide operational oversight of the RFC = Editor; >>> however, as described in Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], >>> RFC Series Oversight Committee (RSOC), acting with authority >>> delegated from the IAB, is responsible for ensuring that the RFC >>> Series is run in a transparent and accountable manner, including >>> design and execution of the RFC Series Editor selection process. >>>=20 >>> The IETF Executive Director works with the IAB to identify suitable >>> persons or entities to fulfill the mandate of the RFC Production >>> Center and the RFC Publisher roles as defined in >>> [I-D.ietf-iasa2-rfc6635bis]. >>>=20 >>>=20 >>> Section 7: >>>=20 >>> I would suggest the following to make the text consistent with = rfc4071bis Sec. 4.2: >>>=20 >>> OLD >>> Under the new structure, the IETF LLC performs the tasks that were >>> previously assigned to the IETF Administrative Oversight Committee >>> (IAOC) under the old structure. >>>=20 >>> NEW >>> Under the new structure, the IETF LLC performs the tasks related to = IASA that were >>> previously assigned to the IETF Administrative Director and to the = Internet Society. >>>=20 >>> Sure. That is an improvement. >>>=20 >>> Russ >>>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss = >>> -- >>>=20 >>> Leslie Daigle >>> Principal, ThinkingCat Enterprises >>>=20 >>> ldaigle@thinkingcat.com >=20 --Apple-Mail=_6DBE2C21-00A3-480A-B2CA-B2245203D682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Done.=  I just posted -04.

Russ


On Oct = 15, 2019, at 1:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Hi Russ,

If everyone is okay with this text, can = you update the draft?  I'll bring it to an IAB meeting (probably = week after next, but possible the one after that, depending on the other = agenda items).

thanks,

Ted

On Tue, Oct = 15, 2019 at 10:25 AM Alissa Cooper <alissa@cooperw.in> = wrote:
WFM
Alissa

On Oct 15, 2019, at 12:22 PM, Russ Housley <housley@vigilsec.com> wrote:

Leslie:

Works for me.  

Russ


On Oct 15, 2019, at 10:09 AM, Leslie Daigle = <ldaigle@thinkingcat.com> wrote:

I = agree that the second point is improved wording.

However on the first point, while I agree a rewrite is in = order, I think Alissa=E2=80=99s suggested text, and your refinements, = are taking us a bit off track.

In-line:

On 14 Oct 2019, at = 15:45, Russ Housley wrote:

Alissa:

Section = 3.3:

The first paragraph of this section fails to mention the IAB and RSOC, = which according to RFC 6635 have oversight roles. It seems incorrect to = claim that operational oversight is solely the responsibility of = IASA.

The second paragraph is superfluous since the roles of the LLC Board and = ED are defined in rfc4071bis, so I think for clarity it should be = removed.

The resulting changes could appear as follows:

OLD
The IETF Administration Limited Liability Company (IETF LLC), as part of = the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. The = IASA is tasked with providing the funding for and operational oversight = of the RFC Editor.

The IETF LLC Board provides oversight of the IASA, and the IETF = Executive Director is the chief actor for the IASA.

The IETF Executive Director works with the IAB to identify suitable = persons or entities to fulfill the mandate of the RFC Editor.

NEW
The IETF Administration Limited Liability Company (IETF LLC), as part of = the IETF Administrative Support Activity (IASA), is responsible for = administrative and financial matters for the IETF, the IAB, and the = Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].The IASA = is tasked with providing the funding for the RFC Editor. The IASA, the = IAB, and the RFC Series Oversight Committee (RSOC) provide operational = oversight of the RFC Editor.

Oh, boy, operational oversite from 3 independent bodies! = Sounds like serving 3 masters, and two is already discouraged in most = literature.

The original intent was to = make the distinction between oversight of substantive matters (which = fell to the IAB, and now its delegate, the RSOC) and contractual, = day-to-day matters, which falls to the admin side of the house.

I think we need to continue to make some version = of that distinction (and, evidently clearer than it was originally = written).

I also note that the original = text, convoluted as it had become, made the IAD/IETF Executive Director, = in charge of those contracts. If we simply say =E2=80=9Cthe IASA=E2=80=9D= , we introduce an infelicitous fourth potential oversight body, in the = shape of the IASA LLC Board. There is nothing in this setup that rises = to the level of the involvement of the IASA LLC Board, except in its = normal oversight of the exec dir.

Straw = text:

The IETF Administration Limited = Liability Company (IETF LLC), as part
of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, = and
the Internet Research Task Force (IRTF) = [I-D.ietf-iasa2-rfc4071bis].
The IASA is tasked with providing the funding for the RFC Editor. = The IASA (through the IETF Executive Director) provides contractual and = financial oversight of the RFC Editor. Additionally, as described in = Section 3.1 of [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection = process.

The IETF Executive Director works = with the IAB to identify suitable
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Leslie.

The IETF = Executive Director works with the IAB to identify suitable persons or = entities to fulfill the mandate of the RFC Editor.

The RSOC is not otherwise = mentioned in this document, so to bring the RSOC into this discussion, I = think a bit more context is needed. I suggest:

The IETF Administration Limited Liability Company (IETF LLC), as = part
of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, = and
the Internet Research Task Force (IRTF) = [I-D.ietf-iasa2-rfc4071bis].
The IASA is tasked with providing the funding for the RFC Editor.
The IASA and the IAB provide operational oversight of the RFC = Editor;
however, as described in Section 3.1 of = [I-D.ietf-iasa2-rfc6635bis],
RFC Series Oversight Committee (RSOC), acting with authority
delegated from the IAB, is responsible for ensuring that the RFC
Series is run in a transparent and accountable manner, including
design and execution of the RFC Series Editor selection process.

The IETF Executive Director works with the IAB to identify = suitable
persons or entities to fulfill the mandate of the RFC Production
Center and the RFC Publisher roles as defined in
[I-D.ietf-iasa2-rfc6635bis].

Section = 7:

I would suggest the following to make the text consistent with = rfc4071bis Sec. 4.2:

OLD
Under the new structure, the IETF LLC performs the tasks that were
previously assigned to the IETF Administrative Oversight Committee
(IAOC) under the old structure.

NEW
Under the new structure, the IETF LLC performs the tasks related to = IASA that were
previously assigned to the IETF Administrative Director and to the = Internet Society.

Sure. That is an = improvement.

Russ

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss<= /p>

--=

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com




= --Apple-Mail=_6DBE2C21-00A3-480A-B2CA-B2245203D682-- From nobody Fri Oct 18 06:44:44 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067F5120169 for ; Fri, 18 Oct 2019 06:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 XrOOOa6NssoB for ; Fri, 18 Oct 2019 06:44:39 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740081.outbound.protection.outlook.com [40.107.74.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4513C12012E for ; Fri, 18 Oct 2019 06:44:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=no1VoU/N+bfre0FetxWwu8ucs4EaraeUyNgM8psRb38MBKDbgHnbsWh2+btXlJTLe6bpXS9OEBE/hvwxin0F4UPl3ye3duvt7Fp+zy6qbTNU8+m7bbihYsyWJoqWq4h6CvK6mj2sMA2WyJdFBUqBDy2c7VC8OAfxjd6IVsFa3+eCKyiRoQipDwzOQqizrFg3xL856qiCQhDAuLZBq05d0DXdD/vlwlrz/qx8SSdMV8A0z0z5ULrwx2owUDJ9BDOk7de+7zThhxrNkxCsGjvr5+goyBrZK/3TZ0kRYLm8d90UInS7oHyBQ6PpO7aTvo1xNeGC0Lxir8yVjjZNVt7qMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u4i4pmO9hQyc3Two8TqW4S4lEnZbxxZtKsb2zpku5R8=; b=BsDOWdE1j7wUYcwAYUXh8OrSpJNBQ2oa2lSS4chyLji+VLoOs5fkJw313tVMWNCEFm4Ya3Ybrr26UrHmgcnoqlCqbcB2lswW/AVTfDFcRFIqzbCzpK4uAJP9pcI064P79Py6wj5xMII5w4KvV5n8om2Ij4Fj/RWFQ7jFPfMkelcygRnIQnJ3yYzCuWs+GRNJ6gpZfgrposdPe8H0JALNAdacBoFNaFX1careAvsRhXKT8YPW7rF6RZLFWo8ERytBV7mIItFonyUSQHNkv+igp1RSqZINE/N5DoYdXtMlBxjjOcWAlS+/9eMXMvXmTXoi2EvJNJhud1R264OABTU7VQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u4i4pmO9hQyc3Two8TqW4S4lEnZbxxZtKsb2zpku5R8=; b=tDYUPcM66ttgRF8OxWhbq6EVbDkCakWI4FZKVJPKonADAVmSzk6ZAEuA17hVF4gag1EV1b4RwuvGUCya3pjtFAdshGz6AMhuEpF7zTfB0RW/O51xqSBE9Q0qttECtjaSPdDJm0QIckzVUBdiJGI3DKM4DiMV3c0gWgpRCgcxucI= Received: from DM6PR06MB4827.namprd06.prod.outlook.com (20.176.119.148) by DM6PR06MB3995.namprd06.prod.outlook.com (20.176.65.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.23; Fri, 18 Oct 2019 13:44:37 +0000 Received: from DM6PR06MB4827.namprd06.prod.outlook.com ([fe80::2c68:6b9e:2153:38be]) by DM6PR06MB4827.namprd06.prod.outlook.com ([fe80::2c68:6b9e:2153:38be%2]) with mapi id 15.20.2347.023; Fri, 18 Oct 2019 13:44:37 +0000 From: Olaf Kolkman To: Benjamin Kaduk , Bob Hinden CC: "iab@iab.org" , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Call for Comment: (Defining the Role and Function of IETF Protocol Parameter Registry Operators) Thread-Index: AQHVWrbCDVtv7FXGX0ucQiBQ26SoCadgvucA Date: Fri, 18 Oct 2019 13:44:36 +0000 Message-ID: <8067C034-89D9-4FF9-906A-81C9F62D0223@isoc.org> References: <156641157393.25789.13597724381522897325.idtracker@ietfa.amsl.com> <20190824200124.GL60855@kduck.mit.edu> In-Reply-To: <20190824200124.GL60855@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: AM4PR0701CA0038.eurprd07.prod.outlook.com (2603:10a6:200:42::48) To DM6PR06MB4827.namprd06.prod.outlook.com (2603:10b6:5:56::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kolkman@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: MailMate (1.13r5655) x-originating-ip: [2001:980:2282:1:e43d:df82:8ccb:291d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e0988f4-568c-4c75-ca7d-08d753d150d1 x-ms-traffictypediagnostic: DM6PR06MB3995: x-ld-processed: 89f84dfb-7285-4810-bc4d-8b9b5794554f,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 01949FE337 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39840400004)(396003)(136003)(376002)(51914003)(199004)(189003)(51444003)(36756003)(229853002)(6506007)(54906003)(46003)(236005)(110136005)(6512007)(5660300002)(81156014)(6486002)(446003)(386003)(6306002)(14454004)(6246003)(2171002)(606006)(33656002)(486006)(81166006)(54896002)(316002)(25786009)(6436002)(86362001)(66616009)(66574012)(2906002)(71190400001)(66556008)(71200400001)(50226002)(76176011)(476003)(186003)(52116002)(478600001)(4326008)(2616005)(8936002)(99936001)(66446008)(64756008)(66476007)(14444005)(6116002)(66946007)(8676002)(102836004)(11346002)(256004)(99286004)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR06MB3995; H:DM6PR06MB4827.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m5T+9fi6dTbRy2TC7ycLtr8I4A6Fiv6Kvz7X1SeJ05uP+wBtDZPdOr+NL55giG7jm2aAXAGT/T7qGubjOZQgd6rWba7PwILvneRIwnSCGBxyxGbGBB2aMchHk9jaSbHAYdFC2i2SyzBJ6eyh197hnA0oph8+QhpzOCSOjXHak6hS3BVzPBKDxN5Sik/riYl7DdX2stuzoBBd8G1A1l5eFtwW5wKR1BCB8lNLdIKRXyollE4/CyGqXGO1kcg05SH2ToBR6EH0VnneFrOA7daAWDv6lznb6Wd2Dq6gYVUe8XfWbcOsAoM/GfBNyaJ2psCslMILbAawekt6J3muOwz0xRNuTyJVmZgcaZCSnEnmwHUz9mazjqMchB7p7zo0NOSarwA3opw5sVNfQ4tjOu5fR7Xi/EZQGshnBeZe1+ZjXIs= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary="=_MailMate_354D8187-E093-451E-8F72-FF1F4F097103_="; micalg=pgp-sha512; protocol="application/pgp-signature" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 0e0988f4-568c-4c75-ca7d-08d753d150d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2019 13:44:36.7589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: faJ+AQjaPZGyQT1xI9WdN78zqzyPGKDuhNteV7qUH3/hahSdJc2IH2dj8onjD5XvTtr6CA7ajbNsRkBD/H87Lg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB3995 Archived-At: Subject: Re: [arch-d] Call for Comment: (Defining the Role and Function of IETF Protocol Parameter Registry Operators) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 13:44:43 -0000 --=_MailMate_354D8187-E093-451E-8F72-FF1F4F097103_= Content-Type: multipart/alternative; boundary="=_MailMate_E856614C-EE06-46C3-B7E5-0281A59BCCE0_=" --=_MailMate_E856614C-EE06-46C3-B7E5-0281A59BCCE0_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Colleagues, I=E2=80=99ve just uploaded [version 04](https://tools.ietf.org/html/draft= -ietf-iasa2-rfc6220bis-04). Here is a summary of the changes I=E2=80=99ve= made and didn=E2=80=99t make. For reference, [here are the diffs](https:= //tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-iasa2-rfc6220bis-04.txt). I=E2=80=99ve taken up Bob=E2=80=99s suggestion to add a sentence about ob= soleting RFC6220 in the abstract and introduction. Benjamin=E2=80=99s comments are addressed below. > Section 1 references the "IETF Internet Standards Process [RFC2026]", w= hich > might be spelled better as BCP 9. > > Section 2 uses DHCP and IPsec as examples; are these sufficiently > well-known that no informative reference to them is needed? I am tempted to err on the side of clarity. I do have a similar question = about the repeated references to the IASA model. But punted that to the R= FC editor. > > Section 2.1 talks about IANA being direted to register values "as direc= ted > by [...] Proposed, Draft, and full Internet Standards", which is a bit > stale with respect to "Draft" standards (though not strictly inaccurate= in > the full context). > I replaced Proposed, Draft, and full Internet Standards with =E2=80=9CSta= ndard Track Documents[RFC6410]=E2=80=9D > In Section 2.1: > > o Mailing Lists > > * The Registry Operator maintains public mailing lists as > specified in IANA Considerations [RFC8126]. Such lists are > > It might be worth clarifying whether "public" means archives, subscript= ion, > and/or posting. > I would think that the details of what maintenance means are subject to t= he specifics of a list and can be captured in SOWs. So no change. > Reporting > > * The Registry Operator will submit periodic reports to the IAB > concerning the operational performance of the registry > function. As an example of the requirements for such reports,= > the reader is referred to a supplement [MoU_SUPP2018] to the > "Memorandum of Understanding Concerning the Technical Work of > the Internet Assigned Numbers Authority" [RFC2860] that > provides service level agreement (SLA) guidelines under which > ICANN, the current protocol parameter registry, must operate. > > I did not think that ICANN was the current primary protocol parameter > registry operator. ICANN is the entity the LLC does its business with .. See the latest vers= ion of the MoU - to which the reference has been updated. Besides the ref= erence update, no other changes. > > o Intellectual Property Rights and the Registry Operator > > * All assigned values are to be published and made available fre= e > of any charges. > > * The assignment values may be redistributed without > modification. > > These clauses seem to be in conflict with the earlier text about "speci= al > circumstances" that might allow for a closed registry. > It's also unclear how this interacts with the Trust's role, as specifie= d in > Section 2.4: > > The IETF Trust may make such regulations as appropriate for the > redistribution of assignment values and registry publications. I think that is right - with some goodwill this can be seen as an editori= al change. Text now reads: ```` * Intellectual Property Rights and the Registry Operator Unless special circumstances apply (see Section 2.1): - All assigned values are to be published and made available free of any charges. - The assignment values may be redistributed without modification. In any case, - any intellectual property rights of the IETF protocol parameter assignment information, including the IETF protocol parameter registry and its contents, are to be held by the IETF Trust [BCP101]. ``` > In Section 2.5: > > In addition, the IETF LLC has the responsibility to ensure long-term= > access, stability, and uniqueness across all such registries. This > > Ensuring uniqueness seems rather different from the other two, and on t= he > face of it would seem to require rather invasive interaction with the > actual registry operator. Do I misunderstand the sense in which this i= s > intended? My understanding is this: the LLC should make sure that uniqueness is gua= ranteed. For instance in the case that a registry is transferred from one= operator to another, the legacy operator should stop registering new val= ues in the registry and track (if the legacy operator chooses to continue= publication) the content of the registries as published by the new opera= tor. That can/should(?) the LLC can/should (?) enforce this. I have made no changes in the text. > > Section 4 notes that there are no new protocols, and concludes that the= re > are no new security considerations. To a large extent this is true, an= d > even if there are security considerations to operating a public, availa= ble > registry and maintaining the integrity of its contents, those concerns = are > arguably divorced from the administrative structure of how the registry= > operator is selected. > No Changes. > Appendix A notes that the IASA 2.0 update was in 2018, though we're wel= l > into 2019 at this point. > Removed mention of year. Thanks for the comments Benjamin and Bob, -Olaf --=_MailMate_E856614C-EE06-46C3-B7E5-0281A59BCCE0_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Colleagues,

I=E2=80=99ve just uploaded version 04. Here is a summar= y of the changes I=E2=80=99ve made and didn=E2=80=99t make. For reference= , here are the diffs.

I=E2=80=99ve taken up Bob=E2=80=99s suggestion to add a s= entence about obsoleting RFC6220 in the abstract and introduction.

Benjamin=E2=80=99s comments are addressed below.

Section 1 references= the "IETF Internet Standards Process [RFC2026]", which
might be spelled better as BCP 9.

Section 2 uses DHCP and IPsec as examples; are these sufficiently
well-known that no informative reference to them is needed?

I am tempted to err on the side of clarity. I do have a s= imilar question about the repeated references to the IASA model. But punt= ed that to the RFC editor.

Section 2.1 talks ab= out IANA being direted to register values "as directed
by [...] Proposed, Draft, and full Internet Standards", which is a b= it
stale with respect to "Draft" standards (though not strictly in= accurate in
the full context).

I replaced Proposed, Draft, and full Internet Standards w= ith =E2=80=9CStandard Track Documents[RFC6410]=E2=80=9D

In Section 2.1:

o Mailing Lists

* The Registry Operator maintains public mailing lists as
specified in IANA Considerations [RFC8126]. Such lists are

It might be worth clarifying whether "public" means archives, s= ubscription,
and/or posting.

I would think that the details of what maintenance means = are subject to the specifics of a list and can be captured in SOWs. So no= change.

Reporting

* The Registry Operator will submit periodic reports to the IAB concerning the operational performance of the registry
function. As an example of the requirements for such reports, the reader is referred to a supplement [MoU_SUPP2018] to the
= "Memorandum of Understanding Concerning the Technical Work = of
the Internet Assigned Numbers Authority" [RFC2860] that
= provides service level agreement (SLA) guidelines under which ICANN, the current protocol parameter registry, must operate.
I did not think that ICANN was the current primary protocol parameter
= registry operator.

ICANN is the entity the LLC does its business with .. See= the latest version of the MoU - to which the reference has been updated.= Besides the reference update, no other changes.

o Intellectual P= roperty Rights and the Registry Operator

* All assigned values are to be published and made available free<= br> of any charges.

* The assignment values may be redistributed without
modification.

These clauses seem to be in conflict with the earlier text about "sp= ecial
circumstances" that might allow for a closed registry.
It's also unclear how this interacts with the Trust's role, as sp= ecified in
Section 2.4:

The IETF Trust may make such regulations as appropriate for the
redistribution of assignment values and registry publications.

I think that is right - with some goodwill this can be se= en as an editorial change.

Text now reads:

   *  Intellectual Property Rights and the Registry Operator

      Unless special circumstances apply (see Section 2.1):

      -  All assigned values are to be published and made available free
         of any charges.

      -  The assignment values may be redistributed without
         modification.

      In any case,

      -  any intellectual property rights of the IETF protocol parameter
         assignment information, including the IETF protocol parameter
         registry and its contents, are to be held by the IETF Trust
         [BCP101].

In Section 2.5:

In addition, the IETF LLC has the responsibility to ensure long-term access, stability, and uniqueness across all such registries. This
Ensuring uniqueness seems rather different from the other two, and on the=
face of it would seem to require rather invasive interaction with the
= actual registry operator. Do I misunderstand the sense in which this is<= br> intended?

My understanding is this: the LLC should make sure that u= niqueness is guaranteed. For instance in the case that a registry is tran= sferred from one operator to another, the legacy operator should stop reg= istering new values in the registry and track (if the legacy operator cho= oses to continue publication) the content of the registries as published = by the new operator. That can/should(?) the LLC can/should (?) enforce th= is.

I have made no changes in the text.

Section 4 notes that= there are no new protocols, and concludes that there
are no new security considerations. To a large extent this is true, and<= br> even if there are security considerations to operating a public, availabl= e
registry and maintaining the integrity of its contents, those concerns ar= e
arguably divorced from the administrative structure of how the registry operator is selected.

No Changes.

Appendix A notes tha= t the IASA 2.0 update was in 2018, though we're well
into 2019 at this point.

Removed mention of year.

Thanks for the comments Benjamin and Bob,

-Olaf

--=_MailMate_E856614C-EE06-46C3-B7E5-0281A59BCCE0_=-- --=_MailMate_354D8187-E093-451E-8F72-FF1F4F097103_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJFBAEBCgAvFiEEhLIIi9unO2bLJDsVzN4E5OAtL70FAl2pwb4RHGtvbGttYW5A aXNvYy5vcmcACgkQzN4E5OAtL73p5w/+IM6vAWjdITB4coS6tvNkHZSiMllUhHaD n1nbL7xR7dbilsTLoSHvsFiKIOJvRSA7bDFIDhOLFkLGHYi+Qad+6h3PLdd4L1yI SBCdntDjOeEOol7iBrn1sJJpNivkxJOd47t95XJ0bvBbSJqJrzAyPVNrFI+O/Hff i1drmvLhwnQieDS+zZ6EE7wpv1AnEC7X03W2f9Y6UGwnDvAC9MZ9g2715lbQRWtj E+LymIKm64zaJAkKed4wcpvvHFTHJQoocVHn0Bk4S4395r8MazB3UR6efVYzHsmm PnrX6uEm1cVAecez31tqJ6rwWFZcGywubwi+I5ZERAJa04RrqNjQBCeEB8guaJvn pxz81NOcy2QjiuU/atheJLQQTewMWDvxbJIV+/mXbSigguobS1H1veC829ivnyCp 87Fvb5CJRw2wbbwNvss/7mkyku0FkdDqZAP8eu9EcEBxwF2PKRczfQeDJ4wjTbG4 dq3Sgvm3rXGLXQE81WGGvvcJ0iw+eyTSqWicNX59i3XfPxC213QVGhynZ4HJdgcl 0NVDyNi/O9pzZeqdHXV8i1590Is2+9YKHtlFWF8PqAgteuMwQXY9+l/RaqRU9yi9 lRuTv0tCV3V3bjH6k6NXTC/Xv9VxEbuUA6AcPEnkFwGk4uFcDMLSUp+2yawMm2fn Y9tIqaoO4+M= =ETbR -----END PGP SIGNATURE----- --=_MailMate_354D8187-E093-451E-8F72-FF1F4F097103_=--