what the "scope" disagreement is about

[Tony Hain]

Theodore Ts'o wrote:
> ... the first problem is 
> that there has not been architectural consensus about what is 
> the right way to address this particular problem.  And worse 
> yet, it spans multiple working groups and multiple areas.

Which is why I recommended an IAB workshop on the topic.

> 
> So on the one hand this is the sort of thing that crys out 
> for the IAB to get involved, but ever since Kobe, and 
> especially on an issue as contentious as this one has proven 
> to be, I don't know that the IAB would consider itself 
> empowered to say, OK, this is the way to do things.  Only 
> then could we have the IESG to "task a group" to solve this 
> particular issue in this particular way....

In the workshop case, it is not the IAB making a pronouncement, as much
as a report of a focused discussion group. 

> 
> To take this back to the problem-statement wg, this is 
> another example of the "who makes the hard, fundmental 
> architectural decisions that span multiple working groups" 
> question --- and makes decisions that actually stick, as 
> opposed to suggestions which are often ignored.  In the 
> absense of such a group, then each working group makes 
> choices in isolation, and it's only natural that they 
> optimize for their own convenience and/or interest.

I agree. Without adult supervision the WGs will put selfish interests
first.

> 
> 	"We don't want this ugly wart in *our* architecture, so we'll
> 	make it the DNS's problem instead.  Yeah, that's the ticket...."
> 
> (And to Randy and other members of the DNS directorate: 
> before you come hunting for me, I am *not* the one advocating 
> this; quite the opposite, in fact....  :-)

I am not trying to stick all of this on DNS either. The reason I
occasionally pick on DNS is that it is a service that is explicitly out
of step with the way the network is deployed and run. The participants
in the area know that because they ship or run products that go beyond
the IETF specs to deal with the reality they find themselves in. There
are other services that pass around topology information without
understanding the topology, and they will need similar work.

Tony