Re: [Rfced-future] Comments on draft-iab-rfcefdp-rfced-model-12

[Benjamin Kaduk <[e-mail]>]

Hi Peter,

I see we're keeping you quite busy this week; thanks for all you're doing.

On Thu, Mar 10, 2022 at 02:35:58PM -0700, Peter Saint-Andre wrote:
> Working my way from the end of the thread to the beginning...
> 
> On 3/10/22 1:28 AM, Eliot Lear wrote:
> > Hi Ben,
> > 
> > I'm only addressing points on which I have a view here:
> > 
> > On 10.03.22 08:12, Benjamin Kaduk wrote:
> >> I just mention it as a potential route to process deadlock.  Can the RSAB
> >> function with no chair?
> 
> Probably. As Eliot says, the RSAB chair mainly coordinates meetings of 
> the RSAB.

Ah.  That would probably turn this into not really much of a concern, then.

> >> I would like to assume that streams would 
> >> pull and
> >> replace their reps that behave badly, but when designing systems try to
> >> remove classes of failure scenarios by construction, when possible.
> > 
> > It's really not necessary to worry about this.  Because the streams 
> > themselves require the proper functioning of the RFC editor, they're not 
> > likely to argue much over this, and just pick someone. The RSAB chair 
> > function is relatively weak, it's primary function being to convene 
> > meetings. 
> 
> Agreed.
> 
> >> It's getting late here, so maybe I'm just missing things, but while this
> >> does seem to be an improvement, it still seems to have somewhat of a
> >> mismatch with §4.3's depiction.  If I understand correctly, the RPC only
> >> cares about value assignments insamuch as the values being assigned get
> >> recorded in the RFCs being produced, and your new proposal doesn't 
> >> mention
> >> documents/RFCs (other than this one) at all.
> > 
> > "This document requires that the RPC document registry value
> > assignments made by IANA."
> 
> That's pretty much what it said before, no? ;-)
> 
> I suggest this in the "RPC Responsibilities" section:
> 
> 14. Ensuring that RFCs accurately document registry value assignments
>      made by IANA.
> 
> For the avoidance of doubt, we could also say the same thing under the 
> IANA considerations.

That does remove the bits I was confused about, but to me it also seems to
change the semantics somewhat.  Namely, now the RPC is just consuming
things produced by IANA, which could be seen as removing the possibility to
coordinate on which allocations are actually to be made, from what
range(s), etc., that the previous text seems to have implied.  I think I
have seen the RPC notice things in editing that would affect what IANA
does, and thus am not confident that describing this as a unidirectional
flow would be entirely accurate.  (Whether such coordination could occur
between RPC and IANA in an informal manner so as to get the right thing to
happen anyway, is another question.)

> >>>> My understanding is that the current preference is to use the term
> >>>> "disabilities" rather than "special needs".
> >> Please don't forget this one.
> > 
> > I leave it to Peter to address this point.  I have no special knowledge 
> > or wisdom here.
> 
> Further research indicates to me that "people with disabilities" is 
> indeed the term of art these days.
> 
> >> I was trying to say that 8730 is currently listed as only an informative
> >> reference, but it seems like it would be more properly classified as a
> >> normative reference.
> 
> I'll move RFC 8730 from informative to normative.

Thanks for both of these.

-Ben