Re: [Spud] updated draft PLUS charter, rev. 1 June

[Ted Hardie <[e-mail]>]

Howdy,

No both is correct. Yes, we want to specify a new protocol, but I wouldn’t
call it a transport protocol, because it’s ‚only‘ a signal shim layer,
which does not have any of the other typical transport feature because
there always has to be a ‚real‘ transport protocol on top. With this first
sentences we wanted to make that clear; maybe it’s still not clear enough.



> I am unclear.  Maybe others are not.  Are you inventing a new ’thing’ by
> not calling it a "shim that is not a transport protocol"?  Is there some
> reason to do so?
>
>
Well, I don't want to speak for Mirja, but from my perspective, you get a
different thing if you want to recreate a re-usable shim/toolkit than what
you get from creating a transport.

Imagine for a moment that we are talking about transporting RTP/UDP, and we
would like signalling from the path to give us icmp-like information.  We
could do that by recreating RTP with a  signalling piece built in to a
protocol replacing UDP; we could do that by updating UDP itself; we could
describe how to encapsulate the RTP/UDP in something that carried
signalling but was otherwise relying on the encapsulated protocol for
everything.  The advantage of doing the last is that you don't have to
recreate each transport when you want to use it with signalling.  You can
also use the standard transports without this, if your deployment doesn't
need it.

YMMV, obviously.

Ted



>
>
> • I’d like to see a comment on PLUS re-enabling ICMP functionality
>
>
> Yes, that’s a very good use case and clearly in scope. However, there are
> other good use cases as well, see the use case draft, and we decided to not
> explicitly outline one (of a subset of them) in the charter.
>
>
> Fair point but I think the charter would benefit from at least a brief
> listing of the benefits that come from light weight, in-band signaling.
> Besides their important role as scoping documents for working groups,
> charters (IMO) should help someone figure out what problems you are
> solving.  This can of course be done at length in a use-case doc but I
> believe providing a clue for the curious outsider as to whether the work is
> relevant.  YMMV.
>
>
> • There’s the obvious & unaddressed question about the relation to QUIC
>
>
> I also think that this does not really belong in the charter. It’s for
> sure important to make this clear in the BoF and that why we have the
> agenda item on 'Relationship to other work in the IETF’.
>
>
> OK.  I probably should have figured that out by who was presenting.
>
>
> • The PLUS Bof description should start something like “This BoF is to
> discuss the proposed PLUS working group.  The wg’s goal is to…”
>
>
> Don’t know; isn’t that implicit for a working group forming BoF…?
>
>
> Meh, I disagree.  Clearly a nit.
>
>
>
> • No discussion of wg anti-goals.  I had heard some interest in ruling
> middlebox to middlebox signaling as out of scope.
>
>
> That’s a good point. I believe that’s out of scope and would be willing to
> add that.
>
>
> Are there other anti-goals?
>
>
> • (To ADs:) Would like to see the QUIC and PLUS BoFs scheduled
> back-to-back.  While I think the topics are mostly separable, if the
> discussion gets out of sync it will be a headache.
>
>
> As AD, we already discussed that we would like to see the QUIC BoF first
> because at least I believe otherwise there is a high risk to have the QUIC
> BoF in the SPUD BoF. However, I don’t think back to back is a good idea (to
> have some cooling down phase in the mean time). And given that both BoFs
> look for a 2.5h slots, they probably will be in two morning slots on
> different days.
>
>
> Fair enough.  My feelings about back-to-back are not strong and I am glad
> you’ve given it thought.
>
> —aaron
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>
>