On Tue, Oct 13, 2015 at 11:00 PM, Evan Hunt wrote:
> On Tue, Oct 13, 2015 at 10:10:39PM +0100, Ólafur Gušmundsson wrote:
>
>
> > Is reference to RFC4770 security considerations good enough ?
>
> Sorry, which RFC? "vCard Extentions for Instant Messaging" doesn't
> seem likely to be what you mean
> On 7 Oct 2015, at 18:17, 神明達哉 wrote:
>
>
> I've read the 03 version of draft. It's very well written and I've
> not found any critical technical issues. So I basically think it's
> ready to ship.
>
Hi,
Many thanks for the review.
> I have a couple of minor comments, which the authors mi
> On 9 Oct 2015, at 20:53, Joe Abley wrote:
Joe,
Thanks for the review.
> I made a few notes as I read through, but it would be entirely fine with me
> if they were all ignored.
All your suggested rewordings improve the document and have been committed -
thanks.
>
> Section 8: is there
> On 12 Oct 2015, at 11:57, Tony Finch wrote:
>
> Tim Wicinski wrote:
>>
>> This starts a Working Group Last Call for draft-ietf-dnsop-5966bis
>
> I have re-read the draft and it looks good to me.
Thanks.
>
> A couple of suggestions for section 7:
>
> For the avoidance of future doubt,
> On 12 Oct 2015, at 21:35, Mark Andrews wrote:
>
>
> For de-multiplexing the responses off the socket the *only* field
> you should be using is the ID field. There are error conditions
> that result in only the DNS header being returned. All responses
> are *supposed* to be constucted in the
On 14/10/2015 13:53, Sara Dickinson wrote:
> Ah, OK. So, would the following be acceptable?
>
> Since pipelined responses over TCP can arrive out-of-order, clients MUST
> match
> responses to outstanding queries using the DNS query ID and the
> transport tuple (protocol, source and desti
On 14 Oct 2015, at 8:20, Sara Dickinson wrote:
> Section 6.2.3 Idle Timeouts
>
> @@ -477,6 +477,12 @@
> specified in [RFC1035]. Servers MAY use zero timeouts when
> experiencing heavy load or are under attack.
>
> + DNS messages delivered over TCP might arrive in multiple segments. A
> +
Ray Bellis wrote:
> On 14/10/2015 13:53, Sara Dickinson wrote:
> > Ah, OK. So, would the following be acceptable?
> >
> > Since pipelined responses over TCP can arrive out-of-order, clients MUST
> > match
> > responses to outstanding queries using the DNS query ID and the
> > transport tupl
> On Tue, 13 Oct 2015 22:20:50 +0100,
> Tony Finch wrote:
> >
> > The first-last convention has the minor advantage of accommodating
> > non-CIDR delegations
>
> That's an interesting advantage. I had not thought of that. Perhaps you
should mention it in the draft. You might convince some of us
On 14/10/2015 15:55, Tony Finch wrote:
> Yes. Perhaps "transport tuple" is an excessively clever way of saying
> "same connection". When I wrote that I wanted to allow independent choice
> of query ID per connection (rather than implying a single global ID).
Hmm, §6.2.1 talks about not re-using
Bob Harold wrote:
> That's an interesting advantage. I had not thought of that. Perhaps you
> should mention it in the draft. You might convince some of us to change
> our minds.
Already done for the next version :-)
https://git.csx.cam.ac.uk/x/ucs/u/fanf2/rfc2317bis.git/commitdiff/72b9ebbe
On Wed, 14 Oct 2015, Bob Harold wrote:
On Tue, 13 Oct 2015 22:20:50 +0100,
Tony Finch wrote:
>
> The first-last convention has the minor advantage of accommodating
> non-CIDR delegations
That's an interesting advantage. I had not thought of that. Perhaps you
sho
On Wed, Oct 14, 2015 at 09:49:59AM +0100, Ólafur Guðmundsson wrote:
> Sorry for the typo : RFC4470
>
> Minimally Covering NSEC Records and DNSSEC On-line Signing
Ah, thanks. Yes, the first and second points mentioned in the security
considerations there are both applicable.
--
Evan Hunt -- e.
> On 14 Oct 2015, at 16:02, Ray Bellis wrote:
>
>
>
> On 14/10/2015 15:55, Tony Finch wrote:
>
>> Yes. Perhaps "transport tuple" is an excessively clever way of saying
>> "same connection". When I wrote that I wanted to allow independent choice
>> of query ID per connection (rather than imply
On 14/10/2015 17:15, Sara Dickinson wrote:
> Yes, it says:
>
> “ When sending multiple queries over a TCP connection clients MUST take
>care to avoid Message ID collisions. In other words, they MUST NOT
>re-use the DNS Message ID of an in-flight query. "
>
> So maybe that should actua
Ray Bellis wrote:
> On 14/10/2015 17:15, Sara Dickinson wrote:
> >
> > So maybe that should actually read (to avoid any doubt):
> >
> > " When sending multiple queries over a TCP connection clients MUST take
> >care to avoid Message ID collisions. In other words, they MUST NOT
> >re-use
At Wed, 14 Oct 2015 13:20:39 +0100,
Sara Dickinson wrote:
> > Section 8: is there benefit perhaps in including a matching SHOULD for the
> > desired server behaviour? The paragraph notes that servers may respond in
> > an unhelpful way if the message length and the message itself don't arrive
At Wed, 14 Oct 2015 11:55:02 +0100,
Sara Dickinson wrote:
> > I've read the 03 version of draft. It's very well written and I've
> > not found any critical technical issues. So I basically think it's
> > ready to ship.
> > I have a couple of minor comments, which the authors might want to
> >
18 matches
Mail list logo
