; *From:* Daniel Migault [mailto:mglt.i...@gmail.com ]
> *Sent:* Thursday, June 2, 2022, 6:36 AM
> *To:* Eric Vyncke (evyncke)
> *Cc:* Eric Vyncke (evyncke); homenet@ietf.org; kiran.i...@gmail.com;
> Michael Richardson; Stephen Farrell
> *Subject:* [homenet] naming drafts
>
> W
; Stephen Farrell
*Subject:* [homenet] naming drafts
We are working on it with Kiran, I actually started yesterday to
consider her latest feedback (2nd round) - not yet being pushed, but
that should happen very soon.
Yours,
Daniel
On Thu, Jun 2, 2022 at 7:30 AM Eric Vyncke (evyncke)
wrote
Eric Vyncke (evyncke) wrote:
> As we are halfway between IETF-113 and IETF-114, it is time to make a
> check as I have seen no revised version for those 2 ‘naming’ drafts.
Yes... I think that *I* said that I wouldn't have time.
> You may also have noticed that Ted’s ‘stub
gt; (evyncke)"
> *Date: *Thursday, 14 April 2022 at 09:16
> *To: *"homenet@ietf.org"
> *Cc: *"kiran.i...@gmail.com" , Michael Richardson <
> mcr+i...@sandelman.ca>, Daniel Migault , Stephen
> Farrell
> *Subject: *Re: [homenet] naming drafts
>
&g
:16
To: "homenet@ietf.org"
Cc: "kiran.i...@gmail.com" , Michael Richardson
, Daniel Migault , Stephen Farrell
Subject: Re: [homenet] naming drafts
Dear Homenet,
After 9 months, it is time to resurrect this email thread and move forward with
the 'naming drafts', which are
stub networking"
From: homenet on behalf of Daniel Migault
Date: Tuesday, 13 July 2021 at 23:28
To: Chris Box
Cc: "homenet@ietf.org"
Subject: Re: [homenet] naming drafts
Hi,
Thanks for the follow up Chris. I apologize for the delay.
Yours,
Daniel
On Tue, Jun
Hi,
Thanks for the follow up Chris. I apologize for the delay.
Yours,
Daniel
On Tue, Jun 22, 2021 at 12:31 PM Chris Box wrote:
> Daniel,
>
> On Wed, 16 Jun 2021 at 01:27, Daniel Migault wrote:
>
>>
>>> The HNA SHOULD drop any packets arriving on the WAN interface that are
not issued
Daniel,
On Wed, 16 Jun 2021 at 01:27, Daniel Migault wrote:
>
>> The HNA SHOULD drop any packets arriving on the WAN interface that are
>>> not issued from the DM.
>>>
>>>
>>> Depending how the communications between the HNA and the DM are
>>> secured, only packets associated to that protocol
Hi Chris,
Thanks for the follow-up. Please find more details and specific responses
to your questions and comments below. I also just pushed the changes you
recommended for the DHCP options.
Thanks!
Yours,
Daniel
On Tue, Jun 15, 2021 at 1:10 PM Chris Box wrote:
> Hi Daniel. Responses inline
Hi Daniel. Responses inline below.
On Tue, 15 Jun 2021 at 02:58, Daniel Migault wrote:
>
>>
> """
> Limited exchanges:
> : the purpose of the Hidden Primary Server is to synchronize with the DM,
> not to serve any zones to end users, or the public Internet.
> This results in a limited
Thank you very much Chris for the review. That was very useful. I have
updated the two documents according to your reviews. The resulting
architecture document is available here [1] and the resulting DHCP document
is available here [2].
You can also find a more detailed response inline.
Thanks
Hi everyone
I have belatedly reviewed both drafts. I missed the WGLC due to both
$dayjob and the IETF having a plethora of interesting working groups. But
still, I hope this feedback is useful
In general, I appreciate the aim of the drafts which I will paraphrase as
creating a way to
sf> Sure, and as I said I'm not opposed to that. I suspect the
sf> best thing is for the authors to chat with our AD and see
sf> if he's either willing to AD-sponsor it, or to ask another
sf> WG to adopt, or try find a dispatch-like process to see if
sf> enough interest/review
Hi Stephen,
I am just replying to clarify I am not complaining about you personally or
even your review. If further discussions are needed I am happy to set a
call at any time as email does not seem to me the most constructive path.
Yours,
Daniel
On Tue, Jun 8, 2021 at 10:10 AM Stephen Farrell
Juliusz Chroboczek wrote:
> Michael, it would probably take you 20 minutes to write up an I-D
> describing a reasonable REST-based DDNS protocol, another 5 minutes to
> write a client implementation in Javascript, and one hour to write
> a robust server that is well integrated
Hiya,
On 08/06/2021 14:55, Daniel Migault wrote:
I disagree that discussing whether the proposal will take over DDNS
is a side discussion that unfortunately happens at a bad time.
Sorry, I don't get what you mean.
If I
interpret the WGLC report, it is clearly noted as a lack of support.
I disagree that discussing whether the proposal will take over DDNS is a
side discussion that unfortunately happens at a bad time. If I interpret
the WGLC report, it is clearly noted as a lack of support.
Predictions are not a technical discussion and can be very wrong ( "we will
never make a 32
>> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/
> I didn't find any clear definition of how DDNS works in that email.
[...]
> What's the Performance Specification that describes this process? Yes,
> I know where the vendor specific documentation is.
As far as I'm
Hiya,
On 08/06/2021 10:29, Ray Hunter (v6ops) wrote:
Just trying to understand this hurdle/ line of reasoning.
So in addition to achieving "rough consensus", the IETF standardization
process must also produce drafts that are very likely to gain traction
to displace non-IETF
Stephen Farrell wrote on 07/06/2021 21:32:
Hi Michael,
On 05/06/2021 19:46, Michael Richardson wrote:
Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.
Just to clarify: I don't think/claim DDNS is "better" than
the
Stephen Farrell wrote:
> On 05/06/2021 19:46, Michael Richardson wrote:
>> Well, I'd be happy to discuss with this them again, but they'd have to
>> actually tell us what "DDNS" really is for them.
> Just to clarify: I don't think/claim DDNS is "better" than
> the proposal
Hi Michael,
On 05/06/2021 19:46, Michael Richardson wrote:
Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.
Just to clarify: I don't think/claim DDNS is "better" than
the proposal here, rather I don't find the arguments
Juliusz Chroboczek wrote:
>>> Stephen and Juliusz expressed that they're still not convinced that
>>> DDNS isn't a good enough solution for the use case.
>> Well, I'd be happy to discuss with this them again, but they'd have to
>> actually tell us what "DDNS" really is for them.
Hi Michael,
>> Stephen and Juliusz expressed that they're still not convinced that
>> DDNS isn't a good enough solution for the use case.
> Well, I'd be happy to discuss with this them again, but they'd have to
> actually tell us what "DDNS" really is for them.
STARK, BARBARA H wrote:
> Stephen and Juliusz expressed that they're still not convinced that
> DDNS isn't a good enough solution for the use case.
Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.
What specific
Hi homenet WG,
Stephen and I have been chatting about the status of the 2 naming drafts
(draft-ietf-homenet-front-end-naming-delegation and
draft-ietf-homenet-naming-architecture-dhc-options).
We started a 3-week WGLC about a month ago (04 May). Both drafts received
comprehensive review from
Sounds good to me. Anyone objecting DIstribution Manager ? If not I will
consider this terminology.
Yours,
Daniel
On Wed, May 12, 2021 at 5:11 PM Michael Richardson
wrote:
>
> Daniel Migault wrote:
> > "Distribution Primary" is probably my preferred alternative as the
> > replacement
Daniel Migault wrote:
> "Distribution Primary" is probably my preferred alternative as the
> replacement of Master by Primary makes a smooth transition from what is
> currently used. If that is fine with everyone I will update the
> document with it as well as the DHCP option
"Distribution Primary" is probably my preferred alternative as the
replacement of Master by Primary makes a smooth transition from what is
currently used. If that is fine with everyone I will update the document
with it as well as the DHCP option draft. If not feel free to provide a
better
On 6. May 2021, at 00:06, Michael Richardson wrote:
>
>
> Ole Troan wrote:
>> Is this the same as a hidden primary name server?
>
> That's Stealth Primary.
> The DM is not a stealth primary, because it's not primary.
> It hasn't got the DNSSEC signing keys, for instance.
Distribution hub
Ole Troan wrote:
> Is this the same as a hidden primary name server?
That's Stealth Primary.
The DM is not a stealth primary, because it's not primary.
It hasn't got the DNSSEC signing keys, for instance.
>> On 5 May 2021, at 21:09, Michael Richardson
>> wrote:
>>
>> Ted
Or “Distribution Primary?” I think given this chart that “Distribution
Authority” is less clear, since the real authority is the stealth primary.
> On May 5, 2021, at 3:09 PM, Michael Richardson wrote:
>
>
> Ted Lemon wrote:
>> On May 5, 2021, at 11:51 AM, Michael Richardson
>> wrote:
>>>
Is this the same as a hidden primary name server?
Cheers
Ole
> On 5 May 2021, at 21:09, Michael Richardson wrote:
>
>
> Ted Lemon wrote:
>>> On May 5, 2021, at 11:51 AM, Michael Richardson
>>> wrote:
>>> 3) We would be happy to go with another term, but we don't want to
>>> invent another
Ted Lemon wrote:
> On May 5, 2021, at 11:51 AM, Michael Richardson
> wrote:
>> 3) We would be happy to go with another term, but we don't want to
>> invent another term. So, if the DNS anycast operator has another
>> term, then I'd go with it.
> Authority database?
I
On May 5, 2021, at 11:51 AM, Michael Richardson wrote:
> 3) We would be happy to go with another term, but we don't want to invent
> another term. So, if the DNS anycast operator has another term, then
> I'd go with it.
Authority database?
RFC 8499 appears to have deprecated the term
STARK, BARBARA H wrote:
> I'm hoping not to start divisive discussion, but think it's better to
> discuss inside the WG rather than wait until IETF LC.
> Might the authors consider whether a word other than "Master" could be
> used in the terms Distribution Master, Reverse
I'm hoping not to start divisive discussion, but think it's better to discuss
inside the WG rather than wait until IETF LC.
Might the authors consider whether a word other than "Master" could be used in
the terms Distribution Master, Reverse Distribution Master,
Distribution/Distributed Master
37 matches
Mail list logo
