Hi Juergen,

Please see my responses/resolutions below.  I'll be submitting
a version -03 with these changes (plus a couple wording changes from Dean).

Thanks for the review!
Alia

On Fri, Jun 6, 2014 at 11:27 AM, Juergen Schoenwaelder <
[email protected]> wrote:

> On Thu, Jun 05, 2014 at 04:29:38PM -0400, Jeffrey Haas wrote:
>
> > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
> > Have you read the problem statement draft?
> > Do you think it is ready to be published as a RFC?
> > (If no, please respond to the list with issues.)
>
> I have read <draft-ietf-i2rs-problem-statement-01.txt> (and the diff
> for -02). I have a couple of comments that I like to see addressed,
> some are purely editorial (and may be left to the RFC editor), others
> are I think clarification or suggestions for more appropriate wordings.
>
> - Please make sure the central figure fits on a single page since a
>   page break in the middle is kind of disturbing.
>
> - What is a "_clear_ transfer syntax"? Perhaps simply remove 'clear'.
>

Replaced "clear" with "concise"...


> - What are "_semantic-aware_ data models"? Either remove
>   _semantic-aware_ or define it.
>

Replaced with "meaningful"


> - s/MIBs/MIB modules/


Done


> - s/MIB Notifications/MIB notifications/


Done


>  - This is not quite correct:


>     [...] nor is there the
>     standardized ability to set up the router to trigger different
>     actions upon an event's occurrence so that a rapid reaction can be
>     accomplished.
>
>   I believe the MIB modules that were created by the Distributed
>   Manaement (DISMAN) working group provide this functionality. You may
>   want to rephrase this so that it says that such MIB modules were not
>   successfully deployed or something like that, but it is not correct
>   that there are no standardized MIB modules for this.
>
> - I find some of the high throughput "desired aspect" of the protocol
>   problematic, e.g. "should be able to handle a considerable number of
>   operations per second above what basic Netconf or a propretiary CLI
>   can". I find this ill defined. I see this got fixed in -02 which
>   just got posted and I appreciate that fix.
>

Replaced with "While a few of these (e.g. link up/down)
      may be available via MIB notifications today, the full range is
      not - nor has there been successfully deployed the standardized
      ability to set up the router to trigger different actions upon
      an event's occurrence so that a rapid reaction can be
      accomplished. "



> - s/NetConf/NETCONF/
>
> - The NETCONF community was forced to follow a sequential process and
>   it took us time to create YANG after NETCONF and we are now getting
>   core data models out (some published, some in the RFC queue, some in
>   the hands of the IESG). Hence I like the following to be rephrased:
>
>   OLD:
>
>     However, the lack of
>     standard data models have hampered the adoption of NetConf.
>
>   NEW:
>
>     However, the initial lack of
>     standard data models has hampered early adoption of NETCONF.


Done.



> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to