[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 -