---- Original Message -----
From: "Sandra Murphy" <[email protected]>
To: "Terry Manderson" <[email protected]>
Cc: "Christopher Morrow" <[email protected]>; <[email protected]>;
<[email protected]>
Sent: Thursday, September 08, 2011 4:42 PM

> But in your presentation at the wg meeting you noted that few in the room
> had read it, with a wry comment that a last call might be necessary to
> make that happen.  (I agree that it seems to be the modus operandi, here
> and IETF wide.)  So it looks to me like your prediction came through.

How IETF wide it is depends on how many I-Ds the WG has, and perhaps how that
compares to how many it should have.  Some WGs work on one (or two or three)
I-Ds
and then everyone reads everything.  When the WG has 25, then yes, I am
behind the curve and might even wait until IETF LC to raise issues.

And particularly for SIDR, I think that there are more than are needed, that
bits have been tacked on as the work has progressed, making it hard to
understand the (lack of an?) overall plan, even for one who reads every
e-mail to the SIDR list, to find where something is defined, or what to
read to get an understanding of a particular aspect of sidr.

Perhaps these comments are not addressed to you as an individual.

Tom Petch
>
> This is an individual comment.
>
> --Sandy, regular ol' member
>
> On Thu, 8 Sep 2011, Terry Manderson wrote:
>
> > Hi Randy,
> >
> > It strikes me that this is the first time you have read this draft despite
> > the several calls to the WG to do so. That's not bad exactly... just
> > unexpected.
> >
> >
> > On 8/09/11 4:42 PM, "Randy Bush" <[email protected]> wrote:
> >
> >> i do not think this document is at all ready for publication.  someone
> >> with time and energy to clean up the wording needs to spend a half day
> >> with the poor thing.
> >
> > I'm less interested in your abrupt critique and certainly much more
> > interested in constructive reviews of which you started below and then gave
> > up..
> >
> >>
> >> ---
> >>
> >> 1.2 i believe that redefining AS and ASN are ill-advised.  just refer
> >> elsewhere.  we readlly do not want to go there.  e.g. there are a lot of
> >> ASs which are not under a single administrative control.
> >>
> >> if you insist on defining it, i would probably s/route/as-path/
> >>
> >> Aggregate Route makes an assumption that 'more general' and 'specific'
> >> are well definined.  maybe try something like shorter and longer
> >> netmask, or greater or smaller prefix mask length.
> >>
> >> 'Covering Aggregate' uses 'cover' in its definition, which makes it
> >> pretty useless.
> >>
> >> 'Multi-homed prefix' is 'originated via'.  is it transited via/through
> >> or originated by/from?
> >>
> >> ...
> >>
> >>    3.1.  Single Announcement
> >>
> >>    An organization (Org A with ASN 64496) has been allocated the prefix
> >>    192.168.2.0/24.  It wishes to announce the /24 prefix from ASN 64496
> >>    such that relying parties interpret the route as intended.
> >>
> >> look at rfc 5737 IPv4 Address Blocks Reserved for Documentation
> >
> > From time to time authors choose to use non rfc5737 address blocks as the
> > examples can't often be adequately described or remain uniform with the
> > documentation prefixes.
> >
> >>
> >> i could go on and on.
> >
> > Please do.. send to me off list if you choose.
> >
> > Cheers
> > Terry
> >
> > _______________________________________________
> > sidr mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/sidr
> >
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to