"Adult supervision"

Keith Moore moore at cs.utk.edu
Tue May 6 14:58:03 CEST 2003


> I will kindly respond below to your mail.
> 
> But what I am asking is pretty simple.  Use language that is clear and
> direct in response to ideas in the IETF community, and defend them as we
> all have to do.  This is completely orthogonal to your mail below.

no, I don't think so.  what is clear and direct to an AD is often taken
as capricious and unsupportable by WGs.  and it's completely infeasible
to expect an AD to defend every bit of direction in detail.

> > Mumble.  After you've debated something in depth a dozen or more times it
> > starts to get old.   Should IESG members really have to debate with each
> > document author or working group chair (for instance) whether  it's okay
> > to assume that a device or server will only be  accessible from a local,
> > trusted network and that therefore no authentication is needed?  Or
> > whether it's okay to reuse  port 80 with a protocol that is almost but not
> > quite HTTP?
> 
> Of course not but that is not what Ted L's. mail or mine was about at
> all.

I'm not sure I can tell the difference.

> > - the IESG member's concern ignored,
> 
> No.
> 
> > - the group's work delayed until there is a document that 
> > outlines the issuesin detail and imposes carefully-considered constraints,
> > or
> 
> Yes.  Recall my mail here on that we must chase out assumptions in
> addition to the problem statements we are doing now.  No one picked up
> on this here but we must have discussion of assumptions prior to work
> that is controversial or compromise is not evident in time-to-market
> time frame.

so you'd prefer to delay the group's work for several years?

> > In about 90% of cases I suspect you'd agree that the IESG 
> > member's concern is valid, though perhaps not expressed as 
> > well as it might be, and the constraints imposed might be 
> > either overbroad or insufficient to address the concern.  (of 
> > course, the other 10% is a problem...)  But from personal 
> > experience, getting agreement on a document that outlines the 
> > concerns and constraints around a thorny issue can take 
> > several years - even when there's a general agreement that 
> > the concerns are valid and that some constraints are 
> > appropriate.  For this reason I'm firmly convinced that ADs 
> > need to have fairly broad discretion to make tactical 
> > decisions about things that affect the Internet.  But I'd 
> > also like there to be some way to deter ADs from being 
> > entirely capricious.
> 
> I agree with the above.  But in their communications they need to make
> it clear in depth what they want. 

I remember telling one group about security: "you need to understand and
document your threat model and select authentication mechanisms that are
sufficient to ameliorate those threats.  and it's not acceptable to assume
that the local network is trustworthy, or that your servers are not accessible
from the public Internet."  They told me that was arbitrary and capricious and
lacking in detail.  I realize this seems odd, but I don't view the AD's job
as one of designing the security mechansisms in their WG's protocols nor of
writing the security considerations sections in their documents.  It's the
WG's job to understand the requirements and to obtain the necessary expertise
to solve them. 

> > a. the affected party asks the AD for a formal statement of 
> > the constraints
> >    and the reasons for them, copying the IETF chair
> > b. the AD is expected to reply within a reasonable amount of 
> > time c. if the affected party still doesn't agree, he/she can 
> > appeal to IESG and
> >    if necessary, to IAB.
> 
> Agree but there is an issue before this process during WG deliberations.
> Ted L. and my issue on this thread can happen in a WG meeting or even in
> a hallway. 

that's when you say "I need this in writing".  and if the AD doesn't provide
it,
then you send a mail to the iESG as a whole.  cc the IAB if necessary.  or 
even the IETF list. make it sufficiently visible that it will get dealt with.

Keith


More information about the Problem-statement mailing list