[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Requirements document [was Re: Again no multi6 at IETF#56]



I'm with Kurt here. We need this document on record, and if
people are worried by the R-word, then don't call them requirements.

Call them desirable properties, and lose the RFC 2119 language.
Let's not get hung up on our own process hooks.

   Brian

Kurt Erik Lindqvist wrote:
> 
> >> Quote from the one and only document in this WG:
> >>
> >>> 3.2.1 Scalability
> >>>   [snip]
> >>>    A new IPv6 multihoming architecture MUST scale to
> >>>    accommodate orders of magnitude more multihomed
> >>>    sites without imposing unreasonable requirements
> >>>    on the routing system.
> >>
> >> As chair, you simply can not recommend to go a way that blatantly
> >> violates the only working document we have. This text is clear, and
> >> it's
> >> a "MUST" not a "must" which has a very specific meaning as per RFC
> >> 2119.
> >
> > To be pedantic, the requirements doc doesn't specify the starting
> > point: orders of magnitude more multihomed sites than exist today on
> > the v6 network is still easily achievable using
> > draft-kurtis-call-me-when-we-get-1000-routes-in-the-dfz-00.
> >
> 
> That is true, But it does bring up the issue of the status of the
> requirements document. From what I know it has been ready to be shipped
> to the IESG for last-call for quite some time. Some people have
> privately expressed to me that they see little point in moving this
> forward. I want to disagree, as I do think that this documents provides
> a good base-line and a tool for us as chairs to keep people focused on
> what we need to achieve. That said, I do not think that "requirements"
> are the right word as we will have different requirements at different
> times (and I know that people disagrees to this statement).
> 
> I have discussed this with Joe and if I have understood him correctly
> he is for updating the document to better reflect this as
> considerations for potential multihoming solutions. I suggest that we
> hold off discussions on this until we have a updated document and then
> see where to take it from there.
> 
> ...and yes, I do realize that this creates problems with the charter
> and the milestones, but that is the least of my worries at the moment
> :-). We need to fix that anyway.
> 
> - kurtis -