Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

[Jeffrey Haas <[e-mail]>]

On Sat, Jun 07, 2014 at 01:50:50AM +0000, Dean Bogdanovic wrote:
> On Jun 6, 2014, at 4:57 PM, Susan Hares <[e-mail]> wrote:
> > Thank you for the complete review of version 3.   Great review! 
> > 
> > On readability, Jeff Haas suggest putting all the requirements in the front.
> > Would that make it better?  It's an easy switch (other than listening to
> > Jeff say "I told you so").   
> I don't like giving Jeff opportunity to use that sentence, but I'm in agreement with Jeff. Putting the requirement list upfront makes more sense and then you don't have to repeat the whole requirement, you can just list it.

Married life has taught me that "I told you so" is something better to think
than ever say. :-)

As mentioned elsewhere on-list by me, I think we'll probably end up
summarizing the various requirements to the wiki before we're done.  As long
as they're centralized in the document, I'm not highly concerned about where
they live in that document as long as it contributes to easy reading.

> > On REQ01/02 - (01) Read/write access  versus  (02) notification and REQ08/09
> > - (08) Write versus (09) read/notify status --- I agree these could be
> > combined if the WG desires or split on read/write versus notification. Do
> > you have any preference? 
> My preference would be read/notify and write. The reason is that read/notify are used for operational and analytic purposes and write is an action based on operational and analytical result.

A model that may be worth considering is the MIN-ACCESS/MAX-ACCESS form used
by SNMP.  In particular, this lets you distinguish between contents that may
be retrieved (read*) vs. only delivered in notifications
(accessible-for-notify).

-- Jeff