Subject: Re: [Netconf] [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt toProposed Standard

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 3 May 2009 21:47:24 +0200

Hi Dan,

I reviewed the document draft-thomson-beep-async-02.txt in general and
for its operational impact.

Summary: 
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol
framework for the development of application protocols.  This document
describes an BEEP feature that enables asynchrony for individual
channels.

Review summary:

The draft is an extension feature to the BEEP (Blocks Extensible
Exchange Protocol) protocol.
BEEP provides already asnychrony based on pipelining (intra-channel) and
parallelism (inter-channel). This documents provides a feature as an
extension to BEEP, that enables the creation of an asynchronous channel,
which is not limited to pipelining. I.e. a serving peer can process
requests and respond in any order.

The document aims to become a proposed standard RFC but there is no
discussion on why an asynchronous channel is really needed additional to
the already existing asynchrony mechanisms in the original BEEP
protocol, IOW why are the existing mechanisms are not sufficient. The
documents claims the necessity but there are also no examples of
applications which would need the described mechanism.
 
Although the document introduces additional state information which
needs to be stored and managed it does not discuss scalability
sufficiently. The document also does not introduce a configurable
parameter for the 'maximum count of allowed parallel asynchronous
channels'. 
Also the document misses to disscuss what happens when a response does
not follow a request, i.e. is missing the exception handling thereafter.

Configurability in general has not been discussed in the document. 
Performance considerations have not been discussed in the document. 

The reviewer couldn't find the mail archive at the URL given in the
concluded BEEP WG charter page. The current maillist seems to be linked
on www.beepcore.org and the "asynchronous BEEP" thread is under:
http://groups.google.com/group/beepwg/browse_thread/thread/db0255c634c7e
b0c/982e385e39fef215?lnk=gst&q=+Asynchronous+BEEP#982e385e39fef215

The document shepherding info states that are a few seconders on the
maillist. The reviewer of the document found a lot of mails questioning
the sense of such an extension to the BEEP protocol (see URL above, e.g.
"Anyways, reading through the draft, I think one reason I am resistant
to this feature is that I do not fully understand when it would better
than the alternatives.").

Review Questions:

Is the document readable?

	Yes.

Does it contain nits?

      Yes (see below). 

  Miscellaneous warnings:
 
------------------------------------------------------------------------
----

  == The document doesn't use any RFC 2119 keywords, yet seems to have
RFC
     2119 boilerplate text.

  == The document seems to lack a disclaimer for pre-RFC5378 work, but
was
     first submitted before 10 November 2008.  Should you add the
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

Is the document class appropriate?

      No. I would have nothing against such an extension if it would be
Informational. I do not think this is a really necessary and
long-awaited standard feature.

Is the problem well stated?

      The mechanism has been described to some extent but exception
handling and scalability discussion is not sufficient.

Is the problem really a problem?

      The reviewer is not sure whether this feature is really needed as
a standard. The necessity of the feature has been also questioned on the
maillist.

Does the document consider existing solutions?

     Obviously, there are a few products using BEEP
(http://www.beepcore.org/products.html). The reviewer would like to see
some use cases asking for the mechanism and requirements from BEEP
users.

Does the solution break existing technology?

     No.

Does the solution preclude future activity?

     No.

Is the solution sufficiently configurable?

    Configuration parameters are not discussed in the document.
    Additional parameters supporting scalability would be interesting to
have.

Can performance be measured?  How?

    Performance considerations have not been discussed in the document. 

Does the solution scale well?

    A configurable parameter for the 'maximum count of allowed parallel
asynchronous channels' would support scalability. 

Cheers, 
Mehmet 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Romascanu, 
> Dan (Dan)
> Sent: Monday, April 27, 2009 11:32 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [OPS-DIR] FW: Evaluation: 
> draft-thomson-beep-async-02.txt toProposed Standard
> 
> 
>  
> 
> 
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-thomson-beep-async-0
> 2.txt-02.t
> xt
> 
> Technical Summary
> 
>    The Blocks Extensible Exchange Protocol (BEEP) provides a protocol
>    framework for the development of application protocols.  This
>    document describes a BEEP feature that enables asynchrony for
>    individual channels.
> 
> Working Group Summary
> 
>    This is an individual submission.
> 
> Document Quality
> 
>    This was reviewed on the mailing list for the concluded BEEP WG.
>    There was moderate controversy about whether this extension was
>    needed as it is possible to work-around the lack of this feature
>    in BEEP at the next layer up.  No other technical objections were
>    raised and there was explicit support from several parties.
>    At least one open source BEEP library implementation has agreed
>    to implement this extension.
> 
> Personnel
> 
>    Chris Newman is the document shepherd.  This has been reviewed for
> the
> 
> 
>    IESG by Alexey Melnikov.  Marshall Rose and other 
> participants of the
>    BEEP WG mailing list reviewed this proposal.
> 
> RFC Editor Note
> 
>   (Insert RFC Editor Note here or remove section)
> 
> IANA Note
> 
>   (Insert IANA Note here or remove section)
> 
> 
> 
> 
> 
> 
> _______________________________________________
> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir
>