[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ping-pong phenomenon with p2p links & /127 prefixes
On Thu, 19 Aug 2010 20:56:57 +0800
Miya Kohno <firstname.lastname@example.org> wrote:
> > > then you will join us supporting the /127 document and it won't be a
> > > problem, will it.
> > >
> > Why won't you and the other authors do a proper job with it then? It
> > doesn't address all the implications that arise. It should, point by
> > point address, all the issues in RFC3627. It should address the points
> > I raised here 2 weeks ago. It doesn't read to me as a proper
> > justification of why the RFCs it contradicts should be contradicted.
> > e.g. Where is the text explaining the implications to bits 70 and 71,
> > if there are any, and do they need to be managed, and if so, how?
> *Except /127*, we support rfc3627 and the appendix B.2 of rfc5375. They
> have properly addressed the implication for using longer prefix than
So where is there reference to Appendix B.2 of RFC5375 in the /127
draft? The draft does not mention anything about the 70/71 bit issue,
and that RFC5375, section B 2.4, discusses what to do about it. I happen
to be a contributor to that RFC, so I've read it at least twice, and
I've forgotten that it is there. What about the people who haven't read
it at all? (A reference to "B.2" isn't any good - when I first went to
that section I came across the B.2.2 text saying /127s shouldn't be used
- and that made me quite confused about what you've said above)
RFC3627 effectively provides a minimum checklist of the implications
that need to be specifically addressed in the /127 draft for /127s to
be accepted. If the /127 draft was published as an RFC, it shouldn't be
possible for a reader, who's deciding whether to adopt /127s or not,
has read RFC3627, and is now reading the /127 RFC, to say "so what about
this issue identified in RFC3627?"