Re: [Nbd] NBD_CMD_DISC

[adding qemu list and Dan into the mix] On 04/09/2016 05:02 PM, Alex Bligh wrote: > > On 9 Apr 2016, at 22:12, Eric Blake wrote: > >>> How would the client know that? I'm using Go's TLS library, and there is >>> no way (as far as I can tell) to ensure that. >> >> Likewise -

Re: [Nbd] [PATCHv6] Improve documentation for TLS

On 04/09/2016 06:06 AM, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I believe > and as

Re: [Nbd] NBD_CMD_DISC

On 9 Apr 2016, at 22:12, Eric Blake wrote: >> Disconnection >> = >> >> Client side >> --- >> >> Where the client wishes to disconnect safely, it MUST follow the following >> procedure: >> >> * First it must wait until there are no inflight commands,

Re: [Nbd] NBD_CMD_DISC

On 9 Apr 2016, at 22:12, Eric Blake wrote: >> How would the client know that? I'm using Go's TLS library, and there is >> no way (as far as I can tell) to ensure that. > > Likewise - if it's qemu's fault for not flushing the outgoing queue, > then what's the right way to get

Re: [Nbd] [PATCHv3] Improve documentation for TLS

Wouter, On 9 Apr 2016, at 12:38, Wouter Verhelst wrote: > On Sat, Apr 09, 2016 at 12:21:03PM +0100, Alex Bligh wrote: >> An alternative route would be to delete OPTIONALTLS, and make some of >> the MUST requirements in SELECTIVETLS say "MUST xyz unless there are >> no TLS-only

Re: [Nbd] [PATCHv3] Improve documentation for TLS

On Sat, Apr 09, 2016 at 12:21:03PM +0100, Alex Bligh wrote: > An alternative route would be to delete OPTIONALTLS, and make some of > the MUST requirements in SELECTIVETLS say "MUST xyz unless there are > no TLS-only exports". However, this makes it rather harder to read, > so I described that

Re: [Nbd] [RFC PATCH] doc: In STRUCTURED_REPLY, make error types easy to recognize

On 9 Apr 2016, at 11:44, Wouter Verhelst wrote: > It's always easier to add new data at the end rather than in the middle. > With the former, you can just use a struct to read data off the wire, > and it won't change because someone changed the message. With the > latter, that

Re: [Nbd] NBD_CMD_DISC

On 9 Apr 2016, at 11:28, Wouter Verhelst wrote: >>> This will be effectively the same thing. The reply to NBD_CMD_DISC could >>> even have the FIN flag set, too, resulting in no net benefit to the >>> above. >> >> I can't remember now exactly what Eric was suggesting (I think it

Re: [Nbd] [RFC PATCH] doc: In STRUCTURED_REPLY, make error types easy to recognize

On Sat, Apr 09, 2016 at 11:17:50AM +0100, Alex Bligh wrote: > > > > So, let's use two examples, of two different NBD_REPLY_TYPE_ERROR_OFFSET > > messages (one with string, the other without). As I originally wrote the > > RFC, they would be sent over the wire as: > > > > With my original RFC,

Re: [Nbd] [PATCHv3] Improve documentation for TLS

On Sat, Apr 09, 2016 at 11:26:23AM +0100, Alex Bligh wrote: > > On 9 Apr 2016, at 11:11, Wouter Verhelst wrote: > > Since you say zero here, how is it different from OPTIONALTLS? > > > > If "not at all", just drop optional. > > As per previous message, because SELECTIVETLS

Re: [Nbd] [PATCH] Improve documentation for TLS

On Sat, Apr 09, 2016 at 11:04:09AM +0100, Alex Bligh wrote: [...] > > [...] > >> +The server MUST NOT send `NBD_REP_ERR_TLS_REQD` in reply to > >> +any command if TLS has already been neogitated. The server > > > > negotiated > > I'd make sure you're looking at the latest version as Eagle Eyed

Re: [Nbd] [PATCH] Improve documentation for TLS

On Sat, Apr 09, 2016 at 11:05:16AM +0100, Alex Bligh wrote: > > On 9 Apr 2016, at 10:50, Wouter Verhelst wrote: > > > So if I want to swap to qemu-nbd, I cannot also have encrypted > > connections to the same server. Got it. > > AFAIK qemu-nbd only supports a single export so

Re: [Nbd] NBD_CMD_DISC

On Sat, Apr 09, 2016 at 10:51:38AM +0100, Alex Bligh wrote: > Wouter, > > On 9 Apr 2016, at 10:16, Wouter Verhelst wrote: > > > On Wed, Apr 06, 2016 at 02:32:59PM -0600, Eric Blake wrote: > >> New client, old server: server does not send reply, client is stuck > >> waiting for a

Re: [Nbd] [PATCHv3] Improve documentation for TLS

On 9 Apr 2016, at 11:11, Wouter Verhelst wrote: > Since you say zero here, how is it different from OPTIONALTLS? > > If "not at all", just drop optional. As per previous message, because SELECTIVETLS requires INFO, but OPTIONALTLS doesn't. > I'm not *that* well versed in the

Re: [Nbd] [RFC PATCH 00/18] NBD protocol additions

On Fri, Apr 08, 2016 at 04:05:40PM -0600, Eric Blake wrote: > This series is for qemu 2.7, and will probably need some rework > especially since some of it is trying to implement features > that are still marked experimental in upstream NBD. > > Included are some interoperability bug fixes, code

Re: [Nbd] [PATCHv3] Improve documentation for TLS

On Thu, Apr 07, 2016 at 07:32:47PM +0100, Alex Bligh wrote: [...] > +### Server-side requirements > + > +There are four modes of operation for a server. The > +server MUST support one of these modes. > + > +* The server operates entirely without TLS ('NOTLS'); OR > + > +* The server makes TLS

Re: [Nbd] [PATCH] Improve documentation for TLS

On 9 Apr 2016, at 10:55, Wouter Verhelst wrote: > > Yes. > >> That way, a client can send ANY option to learn if TLS is required (even >> an option that the server does not recognize); where NBD_OPT_INFO and >> NBD_OPT_LIST are probably the two most useful options, but where ANY

Re: [Nbd] [PATCH] Improve documentation for TLS

On 9 Apr 2016, at 10:50, Wouter Verhelst wrote: > So if I want to swap to qemu-nbd, I cannot also have encrypted > connections to the same server. Got it. AFAIK qemu-nbd only supports a single export so this isn't really an issue. -- Alex Bligh

Re: [Nbd] [PATCH] Improve documentation for TLS

On 9 Apr 2016, at 10:36, Wouter Verhelst wrote: >> +These modes of operations are described in detail below. >> + >> + NOTLS mode >> + >> +If the server receives `NBD_OPT_STARTTLS` it MUST respond with >> +`NBD_REP_ERR_UNSUPP`. The server MUST NOT respond to any > > No. UNSUP

Re: [Nbd] [PATCH] Document NBD_CMD_CLOSE

On Thu, Apr 07, 2016 at 02:55:25PM +0100, Alex Bligh wrote: > This is offered as a straw-man for comment. The rationale for it > has been discussed on-list and is in the documentation. [...] Not commenting on this in detail right now, since (as explained in other mail) I'm not convined this is

Re: [Nbd] NBD_CMD_DISC

Wouter, On 9 Apr 2016, at 10:16, Wouter Verhelst wrote: > On Wed, Apr 06, 2016 at 02:32:59PM -0600, Eric Blake wrote: >> New client, old server: server does not send reply, client is stuck >> waiting for a reply that never comes. But since the server will close >> the connection,

Re: [Nbd] [PATCH] Improve documentation for TLS

On Thu, Apr 07, 2016 at 02:56:48PM +0100, Daniel P. Berrange wrote: > I don't really agree that there's a use case of mixing > tls & non-tls exports in the same server. There is: swap-on-NBD and TLS do not mix. Without special handling, swapping to the network is prone to deadlocks, because the

Re: [Nbd] [PATCH] Improve documentation for TLS

On Thu, Apr 07, 2016 at 12:35:59PM +0100, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I

Re: [Nbd] [PATCH] docs/proto.md: Clarify SHOULD / MUST / MAY etc

On Wed, Apr 06, 2016 at 04:16:15PM -0600, Eric Blake wrote: > On 04/06/2016 03:20 PM, Alex Bligh wrote: > > > > On 6 Apr 2016, at 21:32, Wouter Verhelst wrote: > > > >> Originally I thought this would be just a short discussion, but it's > >> eating up a lot of free time now.

Re: [Nbd] NBD_CMD_DISC

On Wed, Apr 06, 2016 at 02:32:59PM -0600, Eric Blake wrote: > New client, old server: server does not send reply, client is stuck > waiting for a reply that never comes. But since the server will close > the connection, the client can detect that the connection is closed. > Client is no worse off

Re: [Nbd] [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On Thu, Apr 07, 2016 at 10:10:58AM -0600, Eric Blake wrote: > On 04/07/2016 04:38 AM, Vladimir Sementsov-Ogievskiy wrote: > > On 05.04.2016 16:43, Paolo Bonzini wrote: > >> > >> On 05/04/2016 06:05, Kevin Wolf wrote: > >>> The options I can think of is adding a request field "max number of > >>>

[Nbd] Get protection for your car at a price you can afford.

[Nbd] 2/2.5/3 BHK Apartments in Devanhalli, Bengaluru

-- Find and fix application performance issues faster with Applications Manager

[Nbd] Your Guardian Angel has a message for you

Your Guardian Angel has