Hello Ted and Tom,
I'm going to reply to both of you at once.
First of all, I'm not going to push for wire format change any longer.
Your replies show that there is a lot of thoughts behind the document
*but* these are not captured in the document itself nor dnsop mailing
list. (Maybe I'm just i
> On Aug 18, 2017, at 11:12 AM, Petr Špaček wrote:
>
> We can certainly call TLVs "extension" but renaming it does not remove
> the fundamental problem:
> TLVs are largely incompatible with the code we already have widely
> implemented and deployed everywhere in all the DNS implementations and
>
El 18 ag 2017, a les 11:12, Petr Špaček va escriure:
> My objections are in the end about engineering costs, which was nicely
> summarized by Paul Vixie in another thread (about SWILD, but applicable
> to session signaling as well):
> https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0
Hello Ted and dnsop,
I'm trying really hard to find out why we do not understand each other
so I dug into to dnsop archives and draft-bellis-dnsop-session-signal-00
to see if my questions were already answered somewhere. Hopefully I have
better understanding and will focus on technical questions.
Petr, forgive me for holding your feet to the fire on this, but you make
several statements along the lines of "for me, ... is stretching the
definition too far," "I disgree that this is less significant," et cetera,
but you don't actually raise any technical objections—you just expressed
uneasy fe
Hello Ted and dnsop,
and sorry for delayed answer (below). Your message forced me to think
more about the draft, this time without focus on the wire format.
Spoiler alert: I still do not like the proposal in its current form.
Please see below.
On 21.7.2017 10:22, Ted Lemon wrote:
> I am hearing
I am hearing from a number of people that this is "a new protocol" and
hence requires careful thought and perhaps a new working group, along with
the associated delay. I do not _entirely_ disagree with this position,
although it would be really inconvenient from my perspective.
However, I would
On 20.7.2017 19:09, Andrew Sullivan wrote:
> On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote:
>>> But it's certainly another step along the way to DNSbis by accident.
>>
>> Would it be useful to make it not "by accident"?
>
> Yes. That was basically the point I was trying to make at t
On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote:
> > But it's certainly another step along the way to DNSbis by accident.
>
> Would it be useful to make it not "by accident"?
Yes. That was basically the point I was trying to make at the
beginning of today's session, about overall ana
Praha 3, Czech Republic
mailto:ondrej.s...@nic.czhttps://nic.cz/
- Original Message -
> From: "Andrew Sullivan"
> To: "dnsop"
> Sent: Thursday, 20 July, 2017 18:50:44
> Subject: Re: [DNSOP] I-D Action: d
For TCP connections, being able to signal session liveness policy is useful
for DNS, not just DNSSD. It seems likely that DNS Push is useful for
things other than DNSSD. I think this is generally useful, not just for
DNSSD. Rather than thinking of this as a DNSSD-specific enhancement,
think o
On Thu, Jul 20, 2017 at 06:45:25PM +0200, Ondřej Surý wrote:
> Is this useful for DNS at all, or is this targeted at DNS-SD only?
I can think of at least one way it would be useful. Large
authoritatives often have a clear population of query sources that ask
a lot -- the "top talkers". It would
Hey,
there's one thing I don't really understand from this draft.
Is this useful for DNS at all, or is this targeted at DNS-SD only?
I think this needs some explaining and perhaps a clear cut is needed.
Although it's not mentioned anywhere in the document, the draft makes
much more sense to me,
On 27/04/2017 08:40, Petr Špaček wrote:
> Other people already commented on semantics so I will focus on message
> format:
>
> My attempts to find reasoning for the new TLV format in archives did not
> yield an elaborate explanation. Assuming I did not miss anything, it
> seems to me that the c
On 21.3.2017 20:34, Jan Komissar (jkomissa) wrote:
> Hi,
>
> I have one comment for this draft. In Section 3.3 Message Format, I would
> prefer that if a Session Signaling message is received where any of the
> section count fields are not zero, the receiver MUST respond with an error
> code, e
Hi,
I have one comment for this draft. In Section 3.3 Message Format, I would
prefer that if a Session Signaling message is received where any of the section
count fields are not zero, the receiver MUST respond with an error code, e.g.
FORMERR, but MUST NOT terminate the connection. My reason i
16 matches
Mail list logo
