>The problem occurs when common operating systems start shipping validating
>resolvers, then users will not be able to browse to http://router.home to
>configure their device.
Since the device and the browser will not be online when you do the
initial configuration, it seems to me that if you use
On 16/01/14 08:25, Paul Vixie wrote:
> speaking for the authors of the draft below, i request adoption by
> dnsop. --vixie
>
Hi Paul and the rest of the authors.
> https://datatracker.ietf.org/doc/draft-dulaunoy-kaplan-passive-dns-cof/
>
> Internet Engineering Task Force
L. Aaron Kaplan wrote:
>
> Since I am the only user of the sensor_id field right now, I'd say we remove
> the
> text:
> "The sensor_id is an opaque byte string as defined by RFC 5001 in
>section 2.3 [RFC5001]. The sensor_id MUST be escaped as defined in
>section 2.6 of RFC4627 [RFC4627
On Feb 27, 2014, at 6:04 PM, Tony Finch wrote:
> L. Aaron Kaplan wrote:
>
>> I agree. You probably meant
>>
>> ws = *(
>> %x20 | ; Space
>> %x09; Horizontal tab
>> )
>
> Er yes, typo
L. Aaron Kaplan wrote:
> I agree. You probably meant
>
>ws = *(
>%x20 | ; Space
>%x09; Horizontal tab
> )
Er yes, typo :-)
> > How are sensor_id octet strings encoded as JSON stri
Hi Tony,
Thanks a lot for your very valuable feedback.
On Jan 16, 2014, at 3:27 PM, Tony Finch wrote:
> Paul Vixie wrote:
>
>> speaking for the authors of the draft below, i request adoption by
>> dnsop. --vixie
>>
>> https://datatracker.ietf.org/doc/draft-dulaunoy-kaplan-passive-dns-cof/
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2014 05:43 PM, L. Aaron Kaplan wrote:
Thanks for feedback and updates.
> So, the changes are currently in our github repository. Waiting for Alexandre
> to submit them again.
The -02 is now available at
https://github.com/adulau/pdns-qof/
(chair bit enabled)
On Feb 26, 2014, at 9:56 PM, Mark Andrews wrote:
> In message <20140226233907.6214.qm...@joyce.lan>, "John Levine" writes:
>>
>>> Perhaps all that is missing is some guidance that says "you shouldn't hijack
>>> namespaces that you don't control, even for non-DNS applications
Jim Reid wrote:
> On 27 Feb 2014, at 12:21, Tony Finch wrote:
>
> > The problem occurs when common operating systems start shipping validating
> > resolvers, then users will not be able to browse to http://router.home to
> > configure their device.
>
> An what do these users currently do when ro
On 27 Feb 2014, at 12:21, Tony Finch wrote:
> The problem occurs when common operating systems start shipping validating
> resolvers, then users will not be able to browse to http://router.home to
> configure their device.
An what do these users currently do when router.home or whatever doesn't
Jim Reid wrote:
> On 27 Feb 2014, at 11:55, Mark Andrews wrote:
> >
> > And the moment you have a validating brower / app they *will* break.
>
> And this is a problem because... ?
>
> I doubt there will ever be validating browsers/apps for accessing CPE
> from the inside. They have no need for DN
On 27 Feb 2014, at 11:55, Mark Andrews wrote:
>
> In message , Jim Reid
> writes:
>> On 27 Feb 2014, at 07:42, Mark Andrews wrote:
>>
>>> DNSSEC will eventually be on by default and squatting like this will
>> have negative consequences.
>>
>> Er, no. Vendors who pluck domain names out of th
In message , Jim Reid writes:
> On 27 Feb 2014, at 07:42, Mark Andrews wrote:
>
> > DNSSEC will eventually be on by default and squatting like this will
> have negative consequences.
>
> Er, no. Vendors who pluck domain names out of the ether and use them in
> their products will by definition no
On 27 Feb 2014, at 07:42, Mark Andrews wrote:
> DNSSEC will eventually be on by default and squatting like this will have
> negative consequences.
Er, no. Vendors who pluck domain names out of the ether and use them in their
products will by definition not have the DNS clue required for deploy
14 matches
Mail list logo
