Re: [homenet] congrats!

[Eric Vyncke (evyncke)]

[Extending to homenet as the concluded WG list should still exist]

Indeed, congratulations to the authors, shepherds, WG chairs !

It has been a long path, but all main documents are now published, and SNAC WG 
(a spin-off) is thriving.

Regards

-éric

On 29/01/2024, 11:36, "Stephen Farrell" mailto:stephen.farr...@cs.tcd.ie>> wrote:




Well done on getting those ex-homenet drafts over the line!


Cheers,
S.



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] FW: Protocol Action: 'Service Identity in TLS' to Proposed Standard (draft-ietf-uta-rfc6125bis-15.txt)

[Eric Vyncke (evyncke)]

FYI,

Once this document is published, it will unblock the last two approved but not 
yet published Homenet documents:
- draft-ietf-homenet-front-end-naming-delegation-27
- draft-ietf-homenet-naming-architecture-dhc-options-24

See also https://www.rfc-editor.org/cluster_info.php?cid=C472 (even if it 
appears a little inconsistent)

So, those two will probably be published around end of 2023 ;-)

Regards

-éric


On 15/08/2023, 18:52, "iesg on behalf of The IESG" mailto:iesg-boun...@ietf.org> on behalf of iesg-secret...@ietf.org 
> wrote:


The IESG has approved the following document:
- 'Service Identity in TLS'
(draft-ietf-uta-rfc6125bis-15.txt) as Proposed Standard


This document is the product of the Using TLS in Applications Working Group.


The IESG contact persons are Murray Kucherawy, Paul Wouters and Francesca
Palombini.


A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/ 









Technical Summary


Many application technologies enable secure communication between two
entities by means of Transport Layer Security (TLS) with Internet
Public Key Infrastructure Using X.509 (PKIX) certificates. This
document specifies procedures for representing and verifying the
identity of application services in such interactions.


This document obsoletes RFC 6125.


Working Group Summary


There was broad consensus and positive feedback. The only thing
worth mentioning was an issue on IDNA2008 vs UTS-46 that was raised.
Chairs ran a call for consensus and concluded that the working group had no
consensus to profile or elaborate in great detail on the differences
between IDNA2008 and UTS-46.


Document Quality


As it is a bis document with advise, implementations out there (hopefully)
used the help from this document. The document provides further clarifications
and help for applications with proper verification of TLS server certificates.


Personnel


The Document Shepherd for this document is Orie Steele. The Responsible
Area Director is Paul Wouters.





___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Closing Homenet (was Re: Homenet Mission accomplished ?)

[Eric Vyncke (evyncke)]

Dear Homenet WG members,

With all the 2 remaining WG documents in the RFC Editor queue (but pending on a 
missing reference[1]), as the current responsible AD for Homenet and in 
agreement with the current chairs (Kiran Makhijani and Stephen Farrel), I am 
closing the working group.

The mailing list will be kept active as it is usually the case.

6 RFCs have been published since this WG creation in July 2011. Even, if we had 
higher expectation for deployments than in the reality, this WG was a forum for 
discussion. Let's hope that the child WG, SNAC, will be a success.

Thank you and congratulations to all participants, past and active chairs, past 
AD for the hard work done.

Regards

-éric

[1] draft-ietf-uta-rfc6125bis

From: homenet  on behalf of "Eric Vyncke (evyncke)" 

Date: Wednesday, 1 February 2023 at 10:07
To: "homenet@ietf.org" 
Subject: [homenet] Homenet Mission accomplished ?

Dear Homenet,

As you may have read on https://datatracker.ietf.org/wg/homenet/documents/ the 
last WG documents have been approved for publication:
- draft-ietf-homenet-front-end-naming-delegation-26 had a major rewrite end of 
2022 and the intended status is now experimental per IESG request
- draft-ietf-homenet-naming-architecture-dhc-options-24 was approved mid-2022 
but I was delaying its approval until the main I-D was finally approved, the 
change of status in the main document has created a downref (i.e., a formal 
reference to an experimental I-D), but this downref was accepted by the IESG

All in all, it seems that the Homenet WG can now be closed. As the responsible 
AD for Homenet, I will discuss with the chairs when to close this long-lasting 
WG ;-) Of course, the mailing list will be kept active.

Note: the perimeter security item of the charter will not be completed.

As usual, comments are welcome.

Regards and thanks for all the hard work done in Homenet

-éric
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Homenet Mission accomplished ?

[Eric Vyncke (evyncke)]

Dear Homenet,

As you may have read on https://datatracker.ietf.org/wg/homenet/documents/ the 
last WG documents have been approved for publication:
- draft-ietf-homenet-front-end-naming-delegation-26 had a major rewrite end of 
2022 and the intended status is now experimental per IESG request
- draft-ietf-homenet-naming-architecture-dhc-options-24 was approved mid-2022 
but I was delaying its approval until the main I-D was finally approved, the 
change of status in the main document has created a downref (i.e., a formal 
reference to an experimental I-D), but this downref was accepted by the IESG

All in all, it seems that the Homenet WG can now be closed. As the responsible 
AD for Homenet, I will discuss with the chairs when to close this long-lasting 
WG ;-) Of course, the mailing list will be kept active.

Note: the perimeter security item of the charter will not be completed.

As usual, comments are welcome.

Regards and thanks for all the hard work done in Homenet

-éric
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

[Eric Vyncke (evyncke)]

Well-deserved break for the R&E community, I also took about 10 days off ;-)

More seriously, there was a major rewrite between -18 (the first IESG telechat) 
and -25 (yesterday telechat):
https://author-tools.ietf.org/iddiff?url1=draft-ietf-homenet-front-end-naming-delegation-18&url2=draft-ietf-homenet-front-end-naming-delegation-25&difftype=--html

But you are correct, even my French-reading eye spot two grammar errors: "needs 
to be made available" (rather than "need") and "how an this" (rather weird).

As you may have read in the Homenet WG list [1], there are some ways forward 
about the intended status. Let's wait for authors/WG/IETF community feedback.

Regards

-éric

[1] https://mailarchive.ietf.org/arch/msg/homenet/dnGJ6yFaTDNU1yUPB0q7n-47EKo/

From: Tim Chown 
Date: Friday, 6 January 2023 at 14:03
To: Eric Vyncke 
Cc: "int-...@ietf.org" , 
"draft-ietf-homenet-front-end-naming-delegation@ietf.org" 
, 
"homenet@ietf.org" , "last-c...@ietf.org" 
Subject: Re: Intdir telechat review of 
draft-ietf-homenet-front-end-naming-delegation-25

Hi Eric,

Sorry, the R&E world closes for 2 weeks over the holiday period :)

I just read the IESG comments now, and your comment that "The flow and the text 
(grammar, English) had also a rewrite”, but the diffs from 24 (my review) to 25 
(new) are very
minor and the abstract for example still has six typos or errors in just two 
paragraphs.  I don’t think any of the errors confuse semantics, but it’s in a 
very poor state compared to other draft that I’ve reviewed at a close to Ready 
state.

The suggestion to move it to Experimental is good, imo.

Tim


On 6 Jan 2023, at 11:56, Eric Vyncke (evyncke)  wrote:

Thank you very much Tim for your review for int-dir.

Even if a little too late for the IESG telechat, I am sure that the authors 
will take your review in consideration. I personally like your suggestion to 
add an appendix section on the deployment/operation timeline.

Regards


-éric


On 05/01/2023, 16:12, "Tim Chown via Datatracker" mailto:nore...@ietf.org>> wrote:


Reviewer: Tim Chown
Review result: Almost Ready


Hi,


I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.


This document describes an architecture by which names and IP addresses of
hosts or services may be made available in the public DNS through the use of a
homenet naming authority (HNA) and associated (hidden) primary DNS function
resident in the home network and a DNS outsourcing infrastructure (DOI)
function which through a distribution manager also acts as a secondary. Methods
for synchronisation and control of the information between the HNA and DOI are
presented.


I would say this document is getting close to being Ready, but still has issues.


A significant problem is that the document is not particularly well written.
The quality of the text is poor, with at least six typos or mistakes in just
the initial two paragraph abstract, which does not put the reader in a good
frame of mind to read the main body of the document. There are mistakes
throughout the document. I would suggest that a full check, from start to
finish, is required before the draft can progress.


It may be the fact that the draft is now over 10 years old means it has been
“cobbled” over a long period and perhaps it therefore doesn’t flow as well as
it would were it written from scratch today.


General comments:


The introduction section introduces a lot of new terms and language, and notes
on how various elements and components are related, and communicate. A clear
diagram would be really helpful here. There is one in 5.1, but a high-level
one in section 1 would improve the document.


Otherwise, I am ok with the general principle of what is proposed, i,.e. a
‘hidden’ primary and a secondary in the DOI part, feeding the publicly
accessible servers. But this could also be done with a standard DNS approach -
should thus be noted and a section added pointing out the pros and cons of each
approach?


I would like to see, perhaps as an Appendix, a clear list of steps that would
happen, to go from the starting point (presumably arrangement for the domain(s)
and startup of the HNA function) to a steady operational state, maybe even as a
state diagram. This could include a clearer view of how the user updates the
information they wish to make available. There’s hints of parts of this in the
document, but not a whole view.


Is the HNA typically a function in the home router? Do we expect CPE vendors
to implement t

Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

[Eric Vyncke (evyncke)]

Thank you very much Tim for your review for int-dir.

Even if a little too late for the IESG telechat, I am sure that the authors 
will take your review in consideration. I personally like your suggestion to 
add an appendix section on the deployment/operation timeline.

Regards


-éric


On 05/01/2023, 16:12, "Tim Chown via Datatracker" mailto:nore...@ietf.org>> wrote:


Reviewer: Tim Chown
Review result: Almost Ready


Hi,


I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.


This document describes an architecture by which names and IP addresses of
hosts or services may be made available in the public DNS through the use of a
homenet naming authority (HNA) and associated (hidden) primary DNS function
resident in the home network and a DNS outsourcing infrastructure (DOI)
function which through a distribution manager also acts as a secondary. Methods
for synchronisation and control of the information between the HNA and DOI are
presented.


I would say this document is getting close to being Ready, but still has issues.


A significant problem is that the document is not particularly well written. 
The quality of the text is poor, with at least six typos or mistakes in just
the initial two paragraph abstract, which does not put the reader in a good
frame of mind to read the main body of the document. There are mistakes
throughout the document. I would suggest that a full check, from start to
finish, is required before the draft can progress.


It may be the fact that the draft is now over 10 years old means it has been
“cobbled” over a long period and perhaps it therefore doesn’t flow as well as
it would were it written from scratch today.


General comments:


The introduction section introduces a lot of new terms and language, and notes
on how various elements and components are related, and communicate. A clear
diagram would be really helpful here. There is one in 5.1, but a high-level
one in section 1 would improve the document.


Otherwise, I am ok with the general principle of what is proposed, i,.e. a
‘hidden’ primary and a secondary in the DOI part, feeding the publicly
accessible servers. But this could also be done with a standard DNS approach -
should thus be noted and a section added pointing out the pros and cons of each
approach?


I would like to see, perhaps as an Appendix, a clear list of steps that would
happen, to go from the starting point (presumably arrangement for the domain(s)
and startup of the HNA function) to a steady operational state, maybe even as a
state diagram. This could include a clearer view of how the user updates the
information they wish to make available. There’s hints of parts of this in the
document, but not a whole view.


Is the HNA typically a function in the home router? Do we expect CPE vendors
to implement this? Which begs the question are there at least two independent
implementations of what is described in this text? Is what’s written here
theory, or has it been proven? The ideas for this approach have clearly been
around for some 10 years at least.


The HNA signs the zone for DNSSEC, but is this a MUST? DNSSEC is mentioned
many times, but this is unclear. In 5.1 and in 6.1 the sentence about this
doesn’t say MUST, but later in section 11 it does. If it is a MUST, say so
earlier. Of course, DNSSEC is not exactly pervasive as it is.


Specific comments:


Abstract:


“The names and IP address of the home network are present in the Public Homenet
Zone by the Homenet Naming Authority (HNA)“ - “are present” needs correcting.


“Home networks are increasingly numbered using IPv6 addresses, which makes this
access much simpler.” - well, it means global addresses are available, but the
issues of for example naming, numbering, firewalling and appropriate access
control remain.


Section 3:


ULA use here should be very strongly discouraged. For a “Public Homenet Zone”
should we not use strong language for GUA? Documents talking about ULAs tend
to take a long time to get published :)


Section 4:


In 4.1.1 the method in bullet point 3 seems very ugly.


Section 5:


In the diagram, does the DOI in fact cover the public authoritative servers,
given you say “The DOI will serve every DNS request of the Public Homenet Zone
coming from outside the home network.“ As it is the diagram shows the DOI only
populating the public authoritative servers?


In 5.2 does “protected” mean provision of confidentiality?


Section 6:


In 6.1, “perhaps and” ?


In 6.5, the use of a DNS zone transfer to provide commands seems ugly.


Section 12:


Talks about power cycling of the HNA. This implie

Re: [homenet] Datatracker State Update Notice:

[Eric Vyncke (evyncke)]

Dear authors, dear Homenet WG,

Happy New Year !

As you may have noticed, the I-D was not approved on yesterday telechat.

The IESG was unanimous to say that the latest revision is much more readable 
and clearer.

Barring the DNS-directorate and the late GENART reviews (to be addressed at 
least by replying to the emails), the IESG had a long discussion on this I-D. 
As I stressed the specific points that reverse DNS zones are not handled by 
dyndns.org and that HNA and DOI are different entities, it appeared that some 
ADs may ballot 'no objection' on this version (due to Christmas vacations, the 
ballot count was short of 1 vote ☹ ).

The core of the discussions was about the intended status of "proposed 
standard":
1) if the authors & WG agree to change it to experimental, then it will 
probably be approved (this will require another IETF last call though)
2) Daniel (if not mistaken) hinted that the 3GPP wants to re-use this 
specification, if the 3GPP issues a liaison statement to the IETF or Homenet 
WG, then proposed standard will be also granted. Would it be possible ?
3) Murray hinted that this I-D is rather an 'applicability statement' (per 
section 3.2 of RFC 2026) as it does not specify a new protocol but rather how 
*existing* protocols could be used together. This would also lead to a proposed 
standard. Of course, the abstract & introduction would need to be changed to 
make it clear that this I-D is an applicability statement and another IETF Last 
Call to be done.

The good will and energy on this document are draining fast (and thanks again 
to the authors' resilience, which was also respected by the IESG), hence as the 
responsible AD, I would like to know the authors' intention to address the 
situation. My own plan, in case this I-D is not approved by 1st of Feb 2023, is 
to declare it dead (i.e., it won't be published as a Homenet RFC) and close 
homenet.

Regards

-éric


On 06/01/2023, 04:32, "IETF Secretariat" mailto:ietf-secretariat-re...@ietf.org>> wrote:


IESG state changed:


New State: IESG Evaluation::Revised I-D Needed


(The previous state was IESG Evaluation)




Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
 








___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

[Eric Vyncke (evyncke)]

Geoff,

Thank you very much for this detailed review, I am sure that it will assist the 
IESG in their 2nd evaluation.

Regards

-éric


On 18/12/2022, 00:36, "Geoff Huston via Datatracker" mailto:nore...@ietf.org>> wrote:


Reviewer: Geoff Huston
Review result: Ready with Issues


I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir 


I am surprised that this draft has had 24 prior iterations and still has
managed to raise so many questions on the part of this reviewer.


These are not necessarily "major" issues, but there are many of them, including 
some
questions about the precise role of this document, noted below, so I think
"ready with issues" best encompasses my review advice.


It strikes me that the overall intent canm be summarised in one sentence: If
a homenet domain wished to publish in the DNS a number of homenet-located
services in the DNS and does not want to use a conventional DNS zone
delegation then a hidden primary DNS configuration may be appropriate.


The document does not make it clear if it is a discussion of design choices
or a normative protocol specification and the flip between the two modes is
highly confusing to the reader.


It may not be the normal practice in the Homenet working group but this
specificatiopn seems to be begging for at least two independent
implementations with proven interoperabil;ity as a precondition to
publication. The specification seem to be indistinct and vague in some
aspects as noted in the detaled comments and some feedback from
implementation might help


There are a few instances of lower case "must". Given that this uses
the normative terms it would be helpful to use a different word
if the normative MUST is not intended here, and use a capitalized version if
it was.


Document walk-through:


Section 2


It would be useful to include a catchall that explains that all other DNS
terms are used in the document with meanings as described in RFC8499


The definition of "Public Authoritative Service" includes the comment that
"for higher resiliency networks, are often implemented in an anycast
fashion" which seems like a spurious comment to me in the context of this
document.


On a more general note I find it curious that the documnent is inventing 
new names for existing DNS concepts - "Homenet Zone" is just a Zone, 
"Registered Homenet Domain" is just a domain. Aside from adding "Homenet"
everywhere, does this deviation from a standard nomenclature for DNS
components provide some essential additional clarity to the document? This 
reviewer tends to answer this question in the negative.




Section 4.1 CPE Vendor


The text notes: "Such a domain name is probably not human friendly, and may
consist of some kind of serial number associated with the device being
sold." The use of a specific reference to a serial number in the domain name
is not clear to this reviewer. Surely the point is that such a
pre-configured domain name is unique to each individual CPE device.


4.1.1. Agnostic CPE


s/roof/proof/


It is not clear to me that the issue of circularity in the use of ACME has been
appropriately considered. If the role of ACME is for the name holder is 
attempting
to demonstrate their control of an as-yet-undelegated domain via ACME then
how can the CA test this control if the domain is not delegated?


5. Architecture Description


Grammar: "this prevents HNA to handle the DNS traffic from the Internet
associated with the resolution of the Homenet Zone." surely this should read
"HNA from handling"?


"The DOI benefits from a cloud infrastructure" - This is not necessarily the
case. What technology the publically accessible DNS authoritative name
servers (or what this documnent oddly calls "DOI") uses to implemment their
service (cloud or otherwise) is up to them, not this document.


"In the case the HNA is a CPE, outsourcing to the DOI protects the home
network against DDoS for example." If only this were the case. If the CPE
uses a public network address then all form of unsolocited traffic can be
directed to it. Directing DNS authoritative server queries elsewhat does not
really provide any meaningful DDOS protection.


"The description of such a synchronization mechanism is the purpose of this
document." At this point I am left wondering about the purpose of this
document. If you strip the customised nomenclature then this document
advocates the use of a hidden primary for homenets. How secondaries
synchronise from a hidden primary is already existing practice. Why do we
need a dedicated document to add the work "homenet" to an already well
understood mechanism?


"The HNA signs t

Re: [homenet] Next actions for I-D Action: draft-ietf-homenet-front-end-naming-delegation-24.txt

[Eric Vyncke (evyncke)]

I would suggest to upload a clean -25 to avoid other people in the IETF 
community or in the IESG also calling idnits and complaining ;-)

-éric

From: Daniel Migault 
Date: Wednesday, 7 December 2022 at 14:25
To: Michael Richardson 
Cc: Eric Vyncke , "homenet@ietf.org" , 
"d...@fl1ger.de" , "v6...@globis.net" 
Subject: Re: Next actions for I-D Action: 
draft-ietf-homenet-front-end-naming-delegation-24.txt

just one clarification: do we prefer to have a version 25 being published or 
should we leave it as version 24 ?
Yours.
Daniel

On Wed, Dec 7, 2022 at 8:11 AM Daniel Migault 
mailto:mglt.i...@gmail.com>> wrote:


On Wed, Dec 7, 2022 at 7:56 AM Michael Richardson 
mailto:mcr%2bi...@sandelman.ca>> wrote:

Eric Vyncke (evyncke) mailto:evyn...@cisco.com>> wrote:
> As the text has changed a lot, not so much on the technical content but
> more or completeness and readability, I will re-submit it to another
> IESG evaluation early January in the hope that the IESG will approve
> this draft.

Thank you.

> May I kindly request the authors to fix the idnits issues ?
> 
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-24.txt
> it is about a reference to RFC 6125 or its -bis and the use of
> obsoleted RFC 5077.

The text says:

   The HNA will validate the DM's control channel certificate by doing
   [RFC6125]/[I-D.ietf-uta-rfc6125bis] DNS-ID check on the name.

The word "an" ought to be in front of [RFC6125].
I think that idnits is confused.

I thought the UTA document was just a patch on RFC6125, but I see that it's a
complete replacement, so referencing both makes less sense.
Just removed rfc6125
As for RFC5077. I have replaced it with RFC8446 (TLS1.3), section 4.6.1, but
the reference feels less useful now.


--
Michael Richardson mailto:mcr%2bi...@sandelman.ca>>   . 
o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide





--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Next actions for I-D Action: draft-ietf-homenet-front-end-naming-delegation-24.txt

[Eric Vyncke (evyncke)]

As already written, thanks again to the authors (and mainly Michael and Daniel 
who recently updated the document).

As the text has changed a lot, not so much on the technical content but more or 
completeness and readability, I will re-submit it to another IESG evaluation 
early January in the hope that the IESG will approve this draft.

May I kindly request the authors to fix the idnits issues ? 
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-24.txt
 it is about a reference to RFC 6125 or its -bis and the use of obsoleted RFC 
5077.

Thanks in advance

-éric


On 05/12/2022, 19:06, "homenet on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Home Networking WG of the IETF.

Title   : Simple Provisioning of Public Names for 
Residential Networks
Authors : Daniel Migault
  Ralf Weber
  Michael Richardson
  Ray Hunter
  Filename: draft-ietf-homenet-front-end-naming-delegation-24.txt
  Pages   : 42
  Date: 2022-12-05

Abstract:
   Home network owners may have devices or services hosted on this home
   network that they wish to access from the Internet (i.e., from a
   network outside of the home network).  Home networks are increasingly
   numbered using IPv6 addresses, which makes this access much simpler.
   To enable this access, the names and IP addresses of these devices
   and services needs to be made available in the public DNS.

   The names and IP address of the home network are present in the
   Public Homenet Zone by the Homenet Naming Authority (HNA), which in
   turn instructs an outsourced infrastructure to publish the zone on
   the behalf of the home owner.  This document describes how an this
   Home Naming Authority instructs the outsourced infrastructure.


The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

There is also an HTML version available at:

https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-24.html

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-24


Internet-Drafts are also available by rsync at 
rsync.ietf.org::internet-drafts


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet NA bike shed opportunities: terminology DOI

[Eric Vyncke (evyncke)]

[Obviously with any hat on a late Sunday evening...]

Michael,

Let's work on bike shedding [1], it is always easier and funnier ;-)

DOS: DNS Outsourcing Services
EDI: External DNS Infrastructure

Or somehow more seriously:
NOS: Naming Outsourcing Services
NES: Naming External Services
NEOS: Naming Externally Outsourced Services


Regards

-éric

[1] as I learned this term only about 3 years ago (actually when I was selected 
as area director!) I may not be the only one who was clueless when reading 
"bike shedding", here is a pointer 
https://en.wikipedia.org/wiki/Law_of_triviality

On 02/12/2022, 03:27, "homenet on behalf of Michael Richardson" 
 wrote:


In draft-ietf-homenet-front-end-naming, we have the term: DOI.

DNS Outsourcing Infrastructure (DOI):
: is the infrastructure responsible for receiving the Public Homenet Zone 
and publishing it on the Internet.
It is mainly composed of a Distribution Manager and Public Authoritative 
Servers.


I never liked the acronym ("DOI" means evil old ISAKMP/IKEv1 things to me),
but I never had a better term.RFC8499 has a bunch of terms, but none of
them seem to be helpful here.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] AD submission for draft-ietf-homenet-front-end-naming-delegation

[Eric Vyncke (evyncke)]

Bonjour Daniel,

As it seems that you and Michael have worked a lot of this I-D and as it 
appears to be ready for submission, may I suggest that you submit it manually 
*even* during this no-submission period ? I will then approve it as it may 
unblock the DISCUSS points.

Send the XML to supp...@ietf.org with me in cc and in 
the email body request that I confirm the submission.

Hope this helps the publication of the last two Homenet documents ;-)

Regards

-éric

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Lars Eggert's Abstain on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)

[Eric Vyncke (evyncke)]

Michael's point is indeed important: reverse DNS and, IMHO, justifies the whole 
effort of the two related I-Ds. Whether they will be implemented is still a 
valid question...

Regards

-éric

On 21/10/2022, 08:50, "homenet on behalf of Michael Richardson" 
 wrote:

Lars Eggert via Datatracker  wrote:
> this document tries to describe would see adoption, it's become very
> clear that dynamic DNS services as described in Section 4 have won out
> here. These services are far from perfect, but at least some of the
> limitations in Section 4 have been addressed, and others are arguably 
a
> feature and not a limitation.

so, perhaps you could explain to me how to use some service to host my IPv6
reverse DNS then.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] FW: Formal IESG Teleconference WebEx and Dial-in Information:20 October 2022

[Eric Vyncke (evyncke)]

Dear Homenet,

You may find interesting to attend as a silent observer to this telechat next 
week as the last 2 remaining I-D of our Homenet WG will be balloted and 
hopefully approved by the IESG. I expect the Homenet document to be discussed 
within the first hour.

This is of course *optional* even for authors, but if you want to learn what is 
happing in the publication process, this could be interesting.

Regards

-éric


On 13/10/2022, 23:50, "IETF-Announce on behalf of IESG Secretary" 
 wrote:

All members of the community are welcome to attend formal IESG telechats
as observers. Observers are not invited to participate in the
discussion.

The next formal IESG telechat will be held on Thursday, October 20,  
2022 at 07:00 US/Canada Pacific (14:00 UTC). The meeting is scheduled 
for two hours (07:00-09:00 US/Canada Pacific). Webex and Dial-in 
information 
is at the bottom of this message.

The agenda for the upcoming telechat can be found at


A calendar of upcoming public telechats can be downloaded or subscribed
to at:

https://calendar.google.com/calendar/ical/ietf.org_egdabaf39ch5v8a13dt39mvee4%40group.calendar.google.com/public/basic.ics


Topic: IESG Formal Telechat
Date: October 20, 2022
Time: 07:00 US/Canada Pacific 
09:00 US/Canada Central
10:00 US/Canada Eastern
14:00 UTC
15:00 United Kingdom
16:00 Germany, France, Belgium, Sweden
17:00 Finland, Kenya
 22:00 Beijing, China

---
JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m38beb3706c7e5a24dd749a50d7e87dfd
Meeting number: 642 944 708
Meeting password: 1234


JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 642 944 708

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [dnsdir] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18

[Eric Vyncke (evyncke)]

Thank you for your first (if not mistaken) review at the IETF: it is detailed 
and I am sure that the authors will also reply to you.

Regards

-éric

On 12/10/2022, 14:26, "dnsdir on behalf of Anthony Somerset via Datatracker 
via dnsdir"  wrote:

Reviewer: Anthony Somerset
Review result: Ready with Nits

Hello

I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

There are are clear and direct references to various DNS RFC's and this 
draft is not in any major conflict with the wider DNS space but the 
following specific suggestions relating to DNS are made. 

Major Issues: None

Minor Issues:

Section 2 - Public Authoritative Servers

I would suggest that we don't specifically mention the resiliency 
comments but instead point readers to the relevant RFC which looks to be
RFC1034 Section 4.1 to be specific, this is because RFC1034 suggests the
requirement is MUST and not SHOULD so would otherwise appear to be 
conflicting

Section 3.2 = "SHOULD remain pointing at the cloud provider's server IP 
address
 - which in many cases will be an anycast addresses."

I don't believe its correct to include this assumption about anycast 
addresses 
and is largely irrelevant to the content of the draft so i don't believe 
there
is value in keeping the text after the hyphen

Other Editorial comments and NITs please feel free to ignore these. Please
note that these are not exhaustive.

The intro is very long and talks about things that don't get explained 
until 
much later in document and could cause some confusion, it may be better to 
make 
the intro more concise and move some of these aspects into the relevant 
sections.

Section 1.2 - to me this would flow better if it was its own section after 
the 
solution is explained

NITs

1.1 2nd Para says that "the HNA would then collect the IPv6 address(es)" 
but 
following para says "A device or service may have Global Unicast Addresses 
(GUA) (IPv6 [RFC3787] or IPv4)..." 

is the former a typo that accidentally excludes IPv4? and would it be 
better to 
say IPv6 and IPv4 addresses

1.2 - "Dynamic Updates solution are not" possible typos? 
should it be "Dynamic Update solutions are not"

3.1 - Typo "Resolver as detaille din further details below." should be 
"Resolver as detailed in further details below."

4.5.1

this section initially talks about communicating with the DM (Distribution 
Manager) via an AXFR but then refers to the DOI in the same context as a 
responder but they are described as different components in glossary - This 
should probably be clarified

I think there would be merit in this going for security review 
additionally. 
My specific minor concerns about this is about the concept of having a DNS 
service exposed to the internet on a CPE to enable the transmission of data 
between Homenet Naming Authority and Distribution Manager. 


-- 
dnsdir mailing list
dns...@ietf.org
https://www.ietf.org/mailman/listinfo/dnsdir

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16

[Eric Vyncke (evyncke)]

Merci Daniel,

By looking at the diff -17-18, you have addressed all my concerns 😊

It would be ready for IETF Last Call, but you were too energetic when removing 
the last sentence of section 6.2, you have actually removed the whole paragraph 
😲 and the IANA registry must have a registration policy. So, we need to keep

"Future code points are assigned under RFC Required as per [RFC8126]."

Regards

-éric-waiting-for-19 ;-)

Also waiting for the revision of 
draft-ietf-homenet-front-end-naming-delegation-17 as my plan is to group the 
two I-D for the last call

From: Daniel Migault 
Date: Tuesday, 20 September 2022 at 15:05
To: Eric Vyncke 
Cc: "ralf.we...@akamai.com" , 
"tomasz.mrugal...@gmail.com" , Stephen Farrell 
, "homenet@ietf.org" 
Subject: Re: [homenet] AD review of 
draft-ietf-homenet-naming-architecture-dhc-options-16

Hi,

I just submitted version 18. All comments have been addressed except moving the 
appendices to a companion document. I would be a bit hesitant to start a full 
process of adoption, last call while this can be shipped in an appendix.  If 
that is not the case and there is a strong incentive toward having a companion 
document we can easily publish such a document.

Yours,
Daniel

On Tue, Sep 20, 2022 at 8:17 AM Eric Vyncke (evyncke) 
mailto:evyn...@cisco.com>> wrote:
Daniel, Ralf, Tomek,

Thank you for posting the -17 revision.

Before requesting the IETF Last Call, I kindly request one small changes in -17 
in the IANA section + a couple of minor suggestions that can be ignored, see 
below for EV>

Stephen, as the doc shepherd, would you mind explaining why "PS" is the right 
intended status?

We can aim to request the Last Call still this week if this I-D and the 
architecture revised I-Ds are quickly posted.

Regards

-éric


From: homenet mailto:homenet-boun...@ietf.org>> on 
behalf of Daniel Migault mailto:mglt.i...@gmail.com>>
Date: Friday, 12 August 2022 at 02:04
To: "Eric Vyncke (evyncke)" 
mailto:40cisco@dmarc.ietf.org>>
Cc: "homenet@ietf.org<mailto:homenet@ietf.org>" 
mailto:homenet@ietf.org>>
Subject: Re: [homenet] AD review of 
draft-ietf-homenet-naming-architecture-dhc-options-16

Hi Eric,

Thank you for the review. Please find inline how we addressed your comments.

You can also find the change on github on the link below:
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662

I will also send the IANA section for additional review to the IANA.

Yours,
Daniel

On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) 
mailto:40cisco@dmarc.ietf.org>> wrote:
As usual, I do my own review before requesting the IETF Last Call for all 
documents. The intent is to give another polishing pass on the I-D.

For this review, the MD format is used.

Hope this helps

Regards

-éric


# Éric Vyncke, INT AD, comments for 
draft-ietf-homenet-naming-architecture-dhc-options-16

CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points, some non-blocking COMMENT 
points (but replies would be appreciated even if only for my own education).

Special thanks to Stephen Farrel for the shepherd's detailed write-up including 
the WG consensus, *but* it lacks the justification of the intended status (and 
the WGLC was extended to the DHC WG).

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

### Section 4.2 port ?

The DHCP option does not allow to run DoT over a non-standard port. Or if 
another transport is defined without an associated default port, then there is 
no way to specify a port.

That is correct, the rationale was to minimize the number of arguments and 
reduce the complexity of handling the DHCP Option. If we would consider adding 
ports, these should be added to every supported transport. This would move the 
Supported Transport field being a list of ( transport, port ). While not 
technically infeasible, that seemed to introduce too much complexity with 
regard to using a dedicated IP address for the DM.
If the DM really needs to use another port  one may think of storing such 
information in the DNS.

EV> it would have been nice to have some text explaining this reasoning. Up to 
the authors to decide whether it is worth adding it.
### Section 6 registry

s/IANA is requested to maintain a new number space/IANA is requested to create 
a new registry/

done
Also follow RFC 8126 section 1.3 (and others) by notably adding a description, 
the parent grouping (DHC I guess)

 The sub section has been updated as follows:

## Supported Transport parameter

IANA is requested to maintain a new registry of Supported Transport parameter 
in the Distributed Manager Option (OPTION_DIST_MANAGER) or the Reverse 
Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different 
pa

Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16

[Eric Vyncke (evyncke)]

Daniel, Ralf, Tomek,

Thank you for posting the -17 revision.

Before requesting the IETF Last Call, I kindly request one small changes in -17 
in the IANA section + a couple of minor suggestions that can be ignored, see 
below for EV>

Stephen, as the doc shepherd, would you mind explaining why "PS" is the right 
intended status?

We can aim to request the Last Call still this week if this I-D and the 
architecture revised I-Ds are quickly posted.

Regards

-éric


From: homenet  on behalf of Daniel Migault 

Date: Friday, 12 August 2022 at 02:04
To: "Eric Vyncke (evyncke)" 
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] AD review of 
draft-ietf-homenet-naming-architecture-dhc-options-16

Hi Eric,

Thank you for the review. Please find inline how we addressed your comments.

You can also find the change on github on the link below:
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662

I will also send the IANA section for additional review to the IANA.

Yours,
Daniel

On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) 
mailto:40cisco@dmarc.ietf.org>> wrote:
As usual, I do my own review before requesting the IETF Last Call for all 
documents. The intent is to give another polishing pass on the I-D.

For this review, the MD format is used.

Hope this helps

Regards

-éric


# Éric Vyncke, INT AD, comments for 
draft-ietf-homenet-naming-architecture-dhc-options-16

CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points, some non-blocking COMMENT 
points (but replies would be appreciated even if only for my own education).

Special thanks to Stephen Farrel for the shepherd's detailed write-up including 
the WG consensus, *but* it lacks the justification of the intended status (and 
the WGLC was extended to the DHC WG).

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

### Section 4.2 port ?

The DHCP option does not allow to run DoT over a non-standard port. Or if 
another transport is defined without an associated default port, then there is 
no way to specify a port.

That is correct, the rationale was to minimize the number of arguments and 
reduce the complexity of handling the DHCP Option. If we would consider adding 
ports, these should be added to every supported transport. This would move the 
Supported Transport field being a list of ( transport, port ). While not 
technically infeasible, that seemed to introduce too much complexity with 
regard to using a dedicated IP address for the DM.
If the DM really needs to use another port  one may think of storing such 
information in the DNS.

EV> it would have been nice to have some text explaining this reasoning. Up to 
the authors to decide whether it is worth adding it.
### Section 6 registry

s/IANA is requested to maintain a new number space/IANA is requested to create 
a new registry/

done
Also follow RFC 8126 section 1.3 (and others) by notably adding a description, 
the parent grouping (DHC I guess)

 The sub section has been updated as follows:

## Supported Transport parameter

IANA is requested to maintain a new registry of Supported Transport parameter 
in the Distributed Manager Option (OPTION_DIST_MANAGER) or the Reverse 
Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different 
parameters are defined in {{tab-st}} in {{sec-st}}.

The Name of the registry is: Supported Transport parameter

The registry description is:  The Supported Transport field of the DHCPv6 
option is a tow byte field that indicates the supported transport protocols.
Each bit represents a specific transport mechanism.

The parent grouping is Dynamic Host Configuration Protocol for IPv6 (DHCPv6) at 
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2.

New entry MUST specify the bit position, the Transport Protocol Description a 
Mnemonic and a Reference as defined in {{tab-iana}}.

The initial registry is as specified in {{tab-iana}}.

Changes of the  format or policies of the registry is left to the IETF via the 
IESG.

Future code points are assigned under Specification Required as per 
{{!RFC8126}}. The expert is expected to be familiar with DHCP.

EV> -17 has 'RFC required' (which is better -- see my previous point), but 
there is no expert for RFC/Spec required policies. So, remove the last sentence 
:)



~~~
Bit Position | Transport Protocol Description |  Mnemonic | Reference
-++---+---
  0  | DNS over TLS   | DoT   | This-RFC
 1-15| unallocated|  -|  -
~~~
{:#tab-iana title="Supported Transport" }
## COMMENTS

### Shepherd's review, intended status
Stephen, as noted above, please include some justification for the intended PS 
status.

[homenet] FW: [Snac] WG Review: Stub Network Auto Configuration for IPv6 (snac)

[Eric Vyncke (evyncke)]

As this is the follow-up of Ted Lemon's work on 'stub neworks' in the Homenet 
WG, you may find useful to review this proposed WG charter.

-éric

On 10/09/2022, 07:01, "The IESG"  wrote:


A new IETF WG has been proposed in the Internet Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (i...@ietf.org) by 2022-09-19.

Stub Network Auto Configuration for IPv6 (snac)
---
Current status: Proposed WG

Chairs:
  Marc Blanchet 
  Kiran Makhijani 

Assigned Area Director:
  Éric Vyncke 

Internet Area Directors:
  Erik Kline 
  Éric Vyncke 

Mailing list:
  Address: s...@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/snac
  Archive: https://mailarchive.ietf.org/arch/browse/snac/

Group page: https://datatracker.ietf.org/group/snac/

Charter: https://datatracker.ietf.org/doc/charter-ietf-snac/

Stub Network AutoConfiguration proposed charter

A stub network is a network that can be connected to an existing
infrastructure network and, to the extent possible, participate as part of
that infrastructure. A stub network must be able to connect to an
infrastructure network without modifications to that infrastructure network,
even if MAC address lengths differ (e.g., IEEE 802.15.4). Hosts connected to
the stub network should be able to do anything that hosts directly connected
to the infrastructure network can do. Stub networks are leaf networks: they
do not support the attachment of additional stub networks.

The simplest use case for a stub network (e.g., a IEEE 802.15.4-based
entertainment or lighting system) is to connect to an infrastructure network
(e.g., a home network) that is a single layer-2 link (hence not running any
routing protocol), without requiring any new behaviour from this
infrastructure network. Hence a solution that only provides transparent
connectivity between the stub network and the infrastructure link to which 
it
is directly connected is an important first step. Multiple distinct stub
networks should be able to connect to the same infrastructure network.

A more involved use case is to connect to an infrastructure network that can
delegate an IPv6 prefix to the stub network and support unicast service
discovery. The infrastructure network may be a single-link unmanaged network
(e.g., a home network) or a managed multi-link network infrastructure. The
multi-link use case may require the stub network prefix to be included in 
the
routing plane of the infrastructure network.

Both use cases are in scope for the working group.

For all types of stub networks, the goal of the working group is to allow
IPv6-only stub networks to connect automatically to an infrastructure
network, so that hosts and services on the stub network can communicate as 
if
they were connected directly to the infrastructure network. Hosts on the 
stub
network(s) and the infrastructure network must be mutually discoverable, and
mutually reachable. Discoverability refers to service discovery, e.g., DNSSD
(RFC6763). In addition, hosts on the stub network should be able to connect
to the Internet (via the infrastructure network), if desired, just as well 
as
hosts on the infrastructure network are able to.

The working group will coordinate with other relevant working groups, such 
as
DNSSD or 6MAN or DHC, for any changes required in protocols and will make
sure that those groups are included in major document reviews at appropriate
times.

Deliverables:

* A framework document that explains how one or more stub routers connect 
one
or more stub networks to a single unmanaged infrastructure link. This
includes providing IP addresses required for communication, routes and
routing required for communication, and providing service discovery for the
stub network and the adjacent infrastructure link.

* A document describing the set of services that must be provided by a
multi-link infrastructure network in order for stub networks to be added to
the infrastructure providing full mutual reachability, addressability, and
discoverability between stub network hosts and hosts on adjacent and
non-adjacent infrastructure links. This would address, for example, a
building management network or an enterprise network.

Milestones:

  Jan 2023 - Framework I-D adopted by the WG

  Jun 2023 - Services for multi-link adopted by the WG

  Nov 2023 - Framework I-D publication requested to the IESG

  Nov 2024 - Services for multi-link publication requested to the IESG

___
homenet maili

[homenet] Status of draft-ietf-homenet-front-end-naming-delegation and draft-ietf-homenet-naming-architecture-dhc-options after the AD review

[Eric Vyncke (evyncke)]

Just want to check what is the current status of those 2 documents after my AD 
review of the 8th of August.

AFAIK, the authors have prepared a revised I-D addressing all the comments, so 
we should be ready to launch the IETF Last Call once the revised IETF drafts 
are uploaded. And I understand that today, Monday 5th, is a day off in Canada 
and USA.

Regards

-éric

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16

[Eric Vyncke (evyncke)]

As usual, I do my own review before requesting the IETF Last Call for all 
documents. The intent is to give another polishing pass on the I-D.

For this review, the MD format is used.

Hope this helps

Regards

-éric


# Éric Vyncke, INT AD, comments for 
draft-ietf-homenet-naming-architecture-dhc-options-16

CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points, some non-blocking COMMENT 
points (but replies would be appreciated even if only for my own education).

Special thanks to Stephen Farrel for the shepherd's detailed write-up including 
the WG consensus, *but* it lacks the justification of the intended status (and 
the WGLC was extended to the DHC WG).

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

### Section 4.2 port ?

The DHCP option does not allow to run DoT over a non-standard port. Or if 
another transport is defined without an associated default port, then there is 
no way to specify a port.

### Section 6 sub-sections

As there are two IANA requests, please use 2 sub-sections, one per request.

### Section 6 reference

For the request about option codes, in the table add the obvious 'this 
document' in the to-be-added column 'Reference' + the relevant section number.

### Section 6 registry

s/IANA is requested to maintain a new number space/IANA is requested to create 
a new registry/

Also follow RFC 8126 section 1.3 (and others) by notably adding a description, 
the parent grouping (DHC I guess)

### Appendix B and its sub-sections

Please use foo.example to stick to the example TLDs.

## COMMENTS

### Shepherd's review, intended status
Stephen, as noted above, please include some justification for the intended PS 
status.

### Abstract

An 'agnostic' HNA is only defined in the appendix of the main document and is 
unclear without this context. Suggest to remove this word.


### Section 2 DOI

Isn't it 'DNS Outsourcing Infrastructure' ?

### Section 2 DOI or DM ?

```
   This document describes how a network can provision the HNA with a
   specific DOI.
```
Is it DOI or DM?

### Section CE or CPE

Please use CPE to be consistent with the companion document.

### Section 4.2 option name

By consistency with section 4.3, should this be OPTION_FORWARD_DIST_MANAGER ?

### Section 4.2 FQDN

Some explanations about the use of a FQDN vs. IP addresses would be welcome.

### Section 4.2.1 flow

As this section is also used by section 4.3, suggestion to move it after 
section 4.3 as section 4.4

### Section 6 spec required

I am concerned that 'spec required' is enough for such a 16-bit flags field. 
Should it be 'RFC required' ?

### References

Unsure whether ietf-homenet-front-end-naming-delegation is normative, it is 
rather informative. Same for RFC 9103 and RFC 7858

### App B

The 1st and 3rd paragraph are quite repetitive.

### Appendix, why here ?

There is little DHCP-related content in the appendix and the scenario would 
probably be more useful in the companion document.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] AD review of draft-ietf-homenet-front-end-naming-delegation-16

[Eric Vyncke (evyncke)]

As usual, I do my own review before requesting the IETF Last Call for all 
documents. The intent is to give another polishing pass on the I-D.



For this review, the MD format is used.



Hope this helps



Regards



-éric



# Éric Vyncke, INT AD, comments for 
draft-ietf-homenet-front-end-naming-delegation-16

CC @evyncke



Thank you for the work put into this document. Multiple nits and typos are 
identified in the end of this review, I would have expected a document that has 
been through spell and grammar checkers.



Please find below one blocking DISCUSS points (easy to address), some 
non-blocking COMMENT points (but replies would be appreciated even if only for 
my own education), and some nits.



Special thanks to Stephen Farrel for the shepherd's detailed write-up including 
the WG consensus, *but* it lacks the justification of the intended status.



I hope that this review helps to improve the document,



Regards,



-éric



## DISCUSS



### id-nits, references to be updated



Please have a look at 
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-16.txt
 and address the updated references.



### id-nits, downref



As noted by Stephen in his review (and I second his proposal), several 
normative references should probably "just" informative.



### HNA certs



From my reading of the text, it is really unclear whether HNA certs are / may 
be self-signed and what the subject alt name is (IP address ? FQDN ? other).



### Section 1, multiple IP addresses



In `A device may have a Global Unicast Address (GUA),`, it appears by the use 
of 'a' that devices can have only one. Suggest removing 'a'.



In the same vein, even in residential network, there may be global IPv4 
addresses.



### Section 1.2, 1 to 3 ?



Please justify the limit to 3 in `For a very few number (one to three) of hosts`



### Section 1.2, requirements ?



Please add a reference (or rephrase) the requirement in `Such dependence does 
not meet the requirement for`.



### Section 2, Homenet Authoritative Servers:



For which zones `Homenet Authoritative Servers:` ?



### Section 3.2



The I-D proposes to use DoH & DoQ as transport, but did the authors check that 
AXFR operations can be made over DoH ?



### Section 4.5.4 SHOULD ?



Please explain when the 'SHOULD' does not apply.



### Section 5, port XX



As the XX on DM is 853, does it require the HNA to also listen on XX == 853 ?



### Section 5

```

   The use of a primary / secondary mechanism is RECOMMENDED instead of

   the use of DNS Update

```



What is 'primary/secondary mechanism' ? Missing transfer ?



'DNS update' is it the HTTP RESTful one ? Is it the same as 'DNS UPDATE 
[RFC2136]' used later in the section ?



### Section 11.3



Who is the end user in :

```

   ... For

   that reason end users may choose not to respond to PTR DNS queries

   and MAY instead return a NXDOMAIN response.

```



### Appendix A, why in appendix ?



Is there a reason why the reverse zone is in the appendix ? There should at 
least be a forward reference in the introduction to the appendix but better to 
move in the main body.



## COMMENTS



### Shepherd's review, intended status



Stephen, as noted above, please include some justification for the intended PS 
status.



### Section 1, devices or services ?



```

   Home network owners often have devices that they wish to access

   outside their home network - i.e., from the Internet using their

   names.

```



As DNS contains more than mere IP addresses and as a single device can host 
many services with different IP addresses, propose to use 'devices and 
services'.



This issue also appears in other sections (e.g., sect 1.1)



### Section 1.1, un-parsable ?



Is it parsable for a native-English speaker ?

```

   While this document does not create any normative mechanism by which

   the selection of names to publish,

```



### Section 1.1, inside ?



Please define (or add a reference) for `on the inside of the home`.



### Section 1.1, DHCP rebinding ?



The reference to RFC 6644 is a little weird to me, either use 'DHCP rebind' or 
use the right RFC for DHCPv6.



### Section 1.1, RFC 1918 or private



Please add a reference to ULA and use 'private IPv4 addresses' rather than 'RFC 
1918 addresses' ?



### Section 1.1, TLS ?



Why is TLS mentioned here ? It should rather be in the security section.



### Section 1.1



This is probably the reverse:

```

A direct advantage of enabling local

   communication is to prevent communications even in case of Internet

   disruption.

```



### Section 1.2



`As there are some commonalities provides by individual home` possibly a typo.



### Section 3.1, which network ?



In `When the request is coming within the network`, which network ? Even if 
guessable, let's be clear.



### Section 3.1



Should '.local' also appear in figure 1?



### Section 3.2

Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-front-end-naming-delegation-16.txt

[Eric Vyncke (evyncke)]

Daniel, and other authors,

Does this version address all comments received during the 2021 WG last call 
[1] ?

There is also a new version of the DHCP part, does this version also address 
all comments received during the 2021 WG last call ?

Thank you very much for the work done, I know that the last mile can be very 
painful...

Regards

-éric

[1] https://mailarchive.ietf.org/arch/msg/homenet/2yussyqUPAFf9gKNFNGw43ywA_Y/


From: homenet  on behalf of Daniel Migault 

Date: Monday, 13 June 2022 at 11:07
To: homenet 
Subject: [homenet] Fwd: I-D Action: 
draft-ietf-homenet-front-end-naming-delegation-16.txt

Hi,

Please find an update of the draft that describes the  Provisioning of Public 
Names for Residential Networks. We essentially, clarify the document and move 
to the appendices the informative sections. We would like to thank Kiran for 
all her comments that have led to the current version. We believe this version 
addresses the comment regarding the readability of the document.

Yours,
Daniel

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Jun 13, 2022 at 12:55 PM
Subject: [homenet] I-D Action: 
draft-ietf-homenet-front-end-naming-delegation-16.txt
To: mailto:i-d-annou...@ietf.org>>
Cc: mailto:homenet@ietf.org>>



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking WG of the IETF.

Title   : Simple Provisioning of Public Names for Residential 
Networks
Authors : Daniel Migault
  Ralf Weber
  Michael Richardson
  Ray Hunter
Filename: draft-ietf-homenet-front-end-naming-delegation-16.txt
Pages   : 38
Date: 2022-06-13

Abstract:
   Home network owners often have devices that they wish to access
   outside their home network - i.e., from the Internet using their
   names.  To do so, these names needs to be made publicly available in
   the DNS.

   This document describes how a Homenet Naming Authority (HNA) can
   instruct a DNS Outsourcing Infrastructure (DOI) to publish a Public
   Homenet Zone on its behalf.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-front-end-naming-delegation-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-16


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Eric Vyncke (evyncke)]

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.

You may also have noticed that Ted’s ‘stub networking’ work is going in a SNAC 
BoF at IETF-114 (please attend and contribute to the 
s...@ietf.org<mailto:s...@ietf.org> mailing list).

Therefore, the plan is to close Homenet early July 2022 if nothing changes.

Hoping to see you in “Philly” to celebrate the achievments of Homenet !

Regards

-éric

From: homenet  on behalf of "Eric Vyncke (evyncke)" 

Date: Thursday, 14 April 2022 at 09: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 still in WG Last Call since May 2021:

-  draft-ietf-homenet-front-end-naming-delegation

-  draft-ietf-homenet-naming-architecture-dhc-options

AT IETF-113, there was a meeting with two authors, the chairs, and I (as the 
responsible AD for Homenet). The plan is to give the authors a chance to issue 
a revised I-D considering Chris Blox's review as well as trying to improve the 
readability and flow of the text (which suffers from multiple revisions that 
have rendered the I-D difficult to read). Once done, the chairs will close the 
WGLC and will request publication to continue the process. This should be done 
by IETF-114 (July 2022) if not earlier.

About the DynDNS discussion of last year, I am in favor of going forward anyway 
with the homenet drafts and wait for the IETF Last Call + IESG evaluation to 
get a broader scope than the Homenet WG on this very specific topic.

Final point, the chairs and I have decided that once those 2 drafts have been 
approved by the IESG [1], then the Homenet WG can be closed after 11 years [2].

Of course, feedback and comments on the above are welcome.

Regards

-éric

[1] or if the publication is not requested before IETF-114, then I will declare 
those two I-D as "dead" and proceed anyway with the closing of Homenet.
[2] a new home will need to be found for Ted Lemon's drafts on "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 22, 2021 at 12:31 PM Chris Box 
mailto:chris.box.i...@gmail.com>> wrote:
Daniel,

On Wed, 16 Jun 2021 at 01:27, Daniel Migault 
mailto:mglt.i...@gmail.com>> 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 SHOULD be allowed.
The separation looks good, but I'd like to tweak the second paragraph. By "only 
packets associated to that protocol" do you mean destination port filtering?

To me IP and port filtering are implemented by the previous line. "only packets 
associated with that protocol" to me means that only TLS packets are allowed.   
The reason we are not mentioning TLS explicitly is that other protocols may be 
used.

Ah, I see, so this is about the payload of the packets. But surely intelligent 
validation of the incoming packets is always going to happen? This is a key 
property of any security protocol.
If the DM is listening on TCP 443, and the incoming packet is not a TLS Client 
Hello that it is happy with, it'll get ignored.
If the DM is listening on UDP 500, and the incoming packet is not an 
IKE_SA_INIT that it is happy with, it'll get ignored.

So I'm not disagreeing with you, I'm just questioning whether the sentence is 
needed. I don't really mind if it stays.
This may not be necessary, but the reason I would prefer to keep it is to head 
up that additional checks - when possible - may be performed in addition to 
port filtering. So unless you have a strong preference, I would prefer to keep 
this additional check that could be performed by the terminating node or a 
firewall.


I'm not concerned about the additional round trip. I was more concerned that 
the DM could be implemented as a frontend/backend architecture. The FQDN would 
resolve to the front end, and this is likely to be a small list of addresses, 
or even a single address. But the backend servers would have distinct, 
different addresses. Connections from the DM to the HNA might be initiated from 
the backend. If the HNA only looked up the FQDN, it would drop legitimate 
connections. This suggests we need a way to inform the HNA of the set of 
legitimate source addresses.


What did you think of this last point?

I see your point.   The architecture document e

Re: [homenet] naming drafts

[Eric Vyncke (evyncke)]

Dear Homenet,

After 9 months, it is time to resurrect this email thread and move forward with 
the 'naming drafts', which are still in WG Last Call since May 2021:

  *   draft-ietf-homenet-front-end-naming-delegation

-  draft-ietf-homenet-naming-architecture-dhc-options

AT IETF-113, there was a meeting with two authors, the chairs, and I (as the 
responsible AD for Homenet). The plan is to give the authors a chance to issue 
a revised I-D considering Chris Blox's review as well as trying to improve the 
readability and flow of the text (which suffers from multiple revisions that 
have rendered the I-D difficult to read). Once done, the chairs will close the 
WGLC and will request publication to continue the process. This should be done 
by IETF-114 (July 2022) if not earlier.

About the DynDNS discussion of last year, I am in favor of going forward anyway 
with the homenet drafts and wait for the IETF Last Call + IESG evaluation to 
get a broader scope than the Homenet WG on this very specific topic.

Final point, the chairs and I have decided that once those 2 drafts have been 
approved by the IESG [1], then the Homenet WG can be closed after 11 years [2].

Of course, feedback and comments on the above are welcome.

Regards

-éric

[1] or if the publication is not requested before IETF-114, then I will declare 
those two I-D as "dead" and proceed anyway with the closing of Homenet.
[2] a new home will need to be found for Ted Lemon's drafts on "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 22, 2021 at 12:31 PM Chris Box 
mailto:chris.box.i...@gmail.com>> wrote:
Daniel,

On Wed, 16 Jun 2021 at 01:27, Daniel Migault 
mailto:mglt.i...@gmail.com>> 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 SHOULD be allowed.
The separation looks good, but I'd like to tweak the second paragraph. By "only 
packets associated to that protocol" do you mean destination port filtering?

To me IP and port filtering are implemented by the previous line. "only packets 
associated with that protocol" to me means that only TLS packets are allowed.   
The reason we are not mentioning TLS explicitly is that other protocols may be 
used.

Ah, I see, so this is about the payload of the packets. But surely intelligent 
validation of the incoming packets is always going to happen? This is a key 
property of any security protocol.
If the DM is listening on TCP 443, and the incoming packet is not a TLS Client 
Hello that it is happy with, it'll get ignored.
If the DM is listening on UDP 500, and the incoming packet is not an 
IKE_SA_INIT that it is happy with, it'll get ignored.

So I'm not disagreeing with you, I'm just questioning whether the sentence is 
needed. I don't really mind if it stays.
This may not be necessary, but the reason I would prefer to keep it is to head 
up that additional checks - when possible - may be performed in addition to 
port filtering. So unless you have a strong preference, I would prefer to keep 
this additional check that could be performed by the terminating node or a 
firewall.


I'm not concerned about the additional round trip. I was more concerned that 
the DM could be implemented as a frontend/backend architecture. The FQDN would 
resolve to the front end, and this is likely to be a small list of addresses, 
or even a single address. But the backend servers would have distinct, 
different addresses. Connections from the DM to the HNA might be initiated from 
the backend. If the HNA only looked up the FQDN, it would drop legitimate 
connections. This suggests we need a way to inform the HNA of the set of 
legitimate source addresses.


What did you think of this last point?

I see your point.   The architecture document envisioned this case by 
specifying the dm_acl parameter in the informative section 14.
We did not include it into the DHCP option as we were requested to implement 
the simplest use case that is envisioned. My understanding was that DHCP 
Options had some history where complex options had been designed but hardly 
used.
That said, if that is something you believe is really needed, we may bring this 
discussion and add this parameter to the current DHCP Options. It still 
represents a minor change as already considered in the architecture document.

Another alternative may also consider adding an extension so the acl may be 
negotiated through the control channel, which I see more scalable than 
designing large DHCP options. At that point, I would rather keep the 
architecture as it is a let such option for future work - though fairly easy to 
set.




Chris


--
Daniel Migault
Ericsson

[homenet] Barbara is officially stepping down as homenet and dnssd chair

[Eric Vyncke (evyncke)]

Barbara Stark just contacted me and the Homenet chairs (Stephen Farrel and 
Kiran Makhijani) with the message that she is ready to step down from her 
duties as the Homenet co-chair.

This was announced months ago, and Kiran has stepped forward as co-chair for 
Homenet.

I am sure that Barbara will continue to follow the IETF work and especially the 
work done in DNSSD and HOMENET WG !

The last line of Barbara's email was "Till we meet again," so see you soon 
Barbara ! and very sincere thank you for all the work done at the IETF, which 
goes beyond this WG.

Kind regards

-éric


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Looking for a Homenet co-chair

[Eric Vyncke (evyncke)]

Dear all,

Even if the Homenet WG will probably close in the coming months, I am adding a 
third chair to the WG (planning for Barbara's departure from her active role) 
and am happy to announce that Kiran Makhijani has accepted to take the position 
of the 3rd chair. So, please welcome her ;-)

Welcome Kiran !

-éric

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Should homenet continue ?

[Eric Vyncke (evyncke)]

[Changing the subject header to better reflect the current discussion]

Stephen, I agree with you: let's continue this thread about homenet WG 
continuation until mid-September.

To be honest, I am wondering whether there is WG momentum as only active IETF 
drafts authors are replying to this thread. Let's hope that the change of 
Subject will trigger more vivid reactions.

Regards

-éric   

PS: I am pretty sure that the 'stub network' I-D could find another home
-Original Message-
From: homenet  on behalf of Stephen Farrell 

Date: Tuesday, 31 August 2021 at 17:41
To: Daniel Migault , Michael Richardson 
Cc: "homenet@ietf.org" , Ted Lemon 
Subject: Re: [homenet] Looking for a Homenet co-chair


Hiya,

On 31/08/2021 15:53, Daniel Migault wrote:
> I also support that homenet work being made in homenet. It is unclear to 
me
> why we are looking at an alternate way to proceed.

 From my POV, mostly because, as co-chair, it's very hard
to be confident that we have sufficient participation to
usefully claim WG consensus for the (good) work being done
when we put that forward for e.g. IETF LC.

As a WG, we're suffering from lack of input and at some
point (and now being a good point) we should consider whether
or not the WG is still tractable or not.

Cheers,
S.

PS: As it's still just about vacation season, I figure
it makes sense to let this discussion go on for another
week or two, so if someone hasn't yet chimed in, it's
still a fine time to do that!


> Yours,
> Daniel
> 
> On Fri, Aug 27, 2021 at 7:05 AM Michael Richardson  
wrote:
> 
>>
>> Michael Richardson  wrote:
>>  >> progress the stub networks draft because I've been too busy doing
>>  >> dnssd work, but that would be an example. I'd really like to
>> progress
>>  >> that draft /somewhere/, and it seems a /bit/ off-topic for 
dnssd. It
>>  >> could go in v6ops, but it's pretty off-topic for v6ops. Same with
>>  >> intarea.
>>
>>  >> But of course the stub networks document isn't what Homenet set 
out
>> to
>>  >> do.  It's just a building block that might lead there. The 
original
>>  >> work of homenet doesn't seem to have caught on in the market, 
and I
>>  >> think it's because we didn't have an adoption strategy. 
Personally I
>>  >> think stub networks is a good bottom-up beginning to a strategy 
that
>>  >> could ultimately produce an adoptable version of what we 
originally
>>  >> tried to do. But again, only if people here want to pursue that.
>>
>>  > I thought that you *wanted* to go to INTAREA with this document.  
I
>>  > agree that it's an important document.
>>
>> If we need to keep HOMENET open to do stub networks, then let's do that.
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Looking for a Homenet co-chair

[Eric Vyncke (evyncke)]

Dear all,

As you are probably aware, Barbara Stark is retiring from her WG chair position 
after IETF-112 and I now have ‘mission impossible n++’ to find a new WG chair 
to assist Stephen Farrel.

As Stephen is an experimented WG chair, having a ‘junior’ co-chair would be 
welcome (of course ‘senior’ as well!), i.e., even if you are new at the IETF 
and if you have never been a WG chair, then feel free to reply unicast[1] to 
me: we can then have a chat about the job and the motivation. The job itself is 
not a big chunk of time outside the IETF weeks but requires human skills 
(herding cats !) and of course good technical knowledge.

Looking forward to reading your email about you or about any suggestion

Regards

-éric

[1] unicast is preferred but not required
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Editorial Errata Reported] RFC8375 (6378)

[Eric Vyncke (evyncke)]

Dear all,

I will reject the errata as the WG consensus is to reject it.

Kulvinder, thank you for submitting it (even if finally rejected)

Regards and Happy New Year to all

-éric

-Original Message-
From: homenet  on behalf of "STARK, BARBARA H" 

Date: Saturday, 2 January 2021 at 22:48
To: 'Stephen Farrell' , 'Kulvinder' 
, 'Ted Lemon' 
Cc: 'Erik Kline' , Eric Vyncke , 
"'pierre.pfis...@darou.fr'" , "'homenet@ietf.org'" 

Subject: Re: [homenet] [Editorial Errata Reported] RFC8375 (6378)

> > My apologies, you are correct. I’ve now seen RFC 1034 which details the
> terminator.
> 
> Grand so. I'll ask Eric V. to hit the reject button on this
> when he gets back to work after the holidays.

Agreed. Thx, all. Happy New (Gregorian) Year.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] ISPs using DHCP for individual clients

[Eric Vyncke (evyncke)]

Probably, but others, could do it and have a collision (unsure whether those 
set the U/L bit correctly)

-éric

-Original Message-
From: Mikael Abrahamsson 
Organization: People's Front Against WWW
Date: Saturday, 21 November 2020 at 17:43
To: Eric Vyncke 
Cc: Daniel Migault , homenet 
Subject: Re: [homenet] ISPs using DHCP for individual clients

On Sat, 21 Nov 2020, Eric Vyncke (evyncke) wrote:

> The idea to identity the kind of devices (hence any QoE) based on MAC 
> address (probably on the OUI part) has work for many years; but, now 
> more and more OS do MAC address randomization (cfr the MADINAS BoF at 
> IETF-109), so, I am afraid that this 'easy/smart' technique is a thing 
> of the past... Or, am I missing something ?

I doubt STB or ATA box will do MAC address randomization. Why would they?

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] ISPs using DHCP for individual clients

[Eric Vyncke (evyncke)]

Hi Mikael,

The idea to identity the kind of devices (hence any QoE) based on MAC address 
(probably on the OUI part) has work for many years; but, now more and more OS 
do MAC address randomization (cfr the MADINAS BoF at IETF-109), so, I am afraid 
that this 'easy/smart' technique is a thing of the past... Or, am I missing 
something ?

Regards

-éric


-Original Message-
From: homenet  on behalf of Mikael Abrahamsson 

Organization: People's Front Against WWW
Date: Friday, 20 November 2020 at 10:08
To: Daniel Migault 
Cc: homenet 
Subject: Re: [homenet] ISPs using DHCP for individual clients

On Fri, 20 Nov 2020, Daniel Migault wrote:

> Hi,
>
> While designing the DHCP options to configure the HNA we asked ourselves
> how likely ISP are:
>
> A) How an ISP is likely to perform an action that is user specific based 
on
> a DHCP request. In our case the HNA sends to the DHCP server the
> certificate it will use to authenticate itself to a server the ISP has
> control on. The action is that the ISP will need to provision the server
> with that certificate.
>
> B) How an ISP is likely to provide a DHCP response that is specific to an
> individual user. The specific information is typically expected to be
> something provisioned for that user.

I'm not 100% sure I understand your question but let me write some text 
and see if it helps.

In Sweden, ETTH is often delivered with an L2 switch of some kind, can be 
media converter or just CPE. Into this, you can connect a router, an ATA 
(PSTN box), a TV STB, and based on the MAC address and possibly the 
contents of the DHCP request, you'll get different responses, possibly 
even that the device reconfigures ports into different VLANs etc. The term 
used is called "free seating" (I have no idea where this came from) and 
the idea is to reduce customer support calls when customers plug in 
equipment into the "wrong" port, so instead just let customers plug into 
any port and it just works. The DHCP responses might also be different 
depending on type of device etc.

We also have cases where you register your HGW MAC address in a portal and 
depending on this MAC address, your HGW will either receive IPv4 GUA or 
end up behind CGN. So this differentiation is done on MAC address. Don't 
know if you consider this "part of DHCP request" or not.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation

[Eric Vyncke (evyncke)]

Daniel, thank you for the update on this draft.

May the WG expect a revised I-D (and possibly one for the DHCPv6 draft) in the 
coming days?

Regards

-éric

From: homenet  on behalf of Daniel Migault 

Date: Friday, 9 October 2020 at 19:22
To: homenet 
Subject: [homenet] draft-ietf-homenet-front-end-naming-delegation

Hi,

I have reviewed the draft. I have addressed some nits and clarification.  I 
believe the draft is in a good shape and should be ready for WGLC soon. It 
seems to me that the only thing to do is to document how provisioning the HNA 
can be done automatically or at least requiring a minimal configuration steps  
from the end user. I expect this to be set in the next two weeks and a clean 
version being published.

Initially, we wanted to request an authorization token to establish the channel 
between the HNA and the DM. However, we have not seen any mechanisms that 
enable to carry this OAUTH token via TLS -only. As a result, we envisioned the 
end user authenticate to a registrar, provide a token to the HNA. The HNA uses 
that token to a resource server from where the DM retrieves the certificate 
used for its authentication by the DM.

Please find other comments below:

[1] 
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

1.

"""
The main one is that the Dynamic DNS update
would also update the zone's NS records, while the goal is to update the
Distribution Master's configuration files.
"""

We maybe need to clarify why the zone's NS RRset needs to be updated.

2.
This specification also assumes the same transport protocol and ports
used by the DM to serve the Control Channel and by the HNA to serve the
Synchronization Channel are the same.

I think the sentence can be clarified. I think what we want to say is that the 
specification assumes that:
* the DM serves both the Control Channel and Synchronization Channel on a 
single IP address, single port and with a single transport protocol.
* the HNA uses a single IP address for both  the Control and Synchronization 
channel by default. However, the HNA MAY use disctinct IP addresses - see 
section {{sec-sync}} for more details.

I would like to add that DNS over TLS SHOULD be supported.

3.
Should we replace Outsroucing Infrastructure by OI ? At some point I believe 
that would ease the reading. Ss most of the document describes interactions 
between DM and HNA and the DM belongs to the Outsourcing Infratsructure.

4.
It seems that the Envisionned deployment scenarios section can be removed or at 
least merged with hna-provisionning section.

5.
section "Example: HNA necessary parameters for outsourcing 
{#sec-configuration-parameters}" may also be removed / merged with 
hna-provisionning

6.
Maybe hna-provisionning section can be put in the appendix.


--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] https://tools.ietf.org/id/draft-ietf-mboned-ieee802-mcast-problems-09.txt

[Eric Vyncke (evyncke)]

Ray and Christophe and others,

As the responsible AD for this draft, would you mind forwarding/adding 
mbo...@ietf.org to the recipient list? So that authors 
can read your valuable comments?

Thank you

-éric



From: homenet  on behalf of "Ray Hunter (v6ops)" 

Date: Wednesday, 23 October 2019 at 10:55
To: Dave Taht 
Cc: HOMENET , cerowrt-devel 

Subject: Re: [homenet] 
https://tools.ietf.org/id/draft-ietf-mboned-ieee802-mcast-problems-09.txt


Dave Taht wrote on 23/10/2019 08:56:


has anyone here had much chance to review this?


Thanks for the prompt.

>From a pure Homenet perspective, it reinforces that L3 routing is the correct 
>solution for segmenting networks where end nodes have different 
>characteristics. e.g. battery powered or different underlying LAN technology. 
>And maybe we need a firewall in front of those segments to prevent inbound 
>scanning traffic overloading the link.

Other than that I'm not sure it says much more than "Multicast is great for 
efficiency, until it isn't".

Section 3.2.4:
> On a wired network, there is not a huge difference between unicast, multicast 
> and broadcast traffic.

I'd dispute this statement as being overly generic. Anyway, it doesn't add much 
to the discussion (about wireless).

The majority of modern wired Ethernets are actually effectively point to point 
networks, with multicast and broadcast being emulated in silicon or software.

Although maybe having a less visible impact than on wireless, multicast and 
broadcast can also have some similar operational impact on wired networks 
(waking nodes unnecessarily, switching via a slow (software) path in the main 
processor,  https://tools.ietf.org/html/rfc6583 etc.).

--
regards,
RayH
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Hackathon about SADR and OpenVPP

[Eric Vyncke (evyncke)]

Ole Troan and I will participate in the OpenVPP (http://fd.io ) Hackathon in 
Buenos Aires.

One goal is to implement source address dependant routing 
(draft-ietf-rtgwg-dst-src-routing) in VPP. Any other takers?

-éric
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] HNCP: avoiding renumbering

[Eric Vyncke (evyncke)]

I think that Brian has summarized this renumbering avoidance as "desirable
but nothing to be depended on"

-éric


On 17/08/15 08:57, "homenet on behalf of Toerless Eckert (eckert)"
 wrote:

>On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote:
>> Just like in some other old workplace, cough, ???if it does not work
>>without IPsec, do not expect it to work with it???.
>
>Should i even try to understand that reference  ? ;-)
>
>> I do not expect homenet stuff to do much better here, unless we want to
>>make it crazily complicated.
>> 
>> Normal, graceful renumberings are a part of IPv6 and should work
>>equally well given single 7084 router and homenet router network. IPv4
>>???renumbering??? will be bit less graceful no matter what, I am afraid,
>>but that???s outside the architecture RFC mandate anyway and done just
>>as a public service.
>
>I don't know why Juliusz called stable storage bad. I think it's great.
>Where would i be without stable storage for my routers software, policy
>configuration, passwords, logs and the like. Why should it be bad to
>memorize addressing ? I think it's mandatory for IPv4, and for IPv6,
>i'd love to have some option to either re-number when i click - to weed
>out bad apps/OS problems - or a switch for persistency of addresses
>(one to improve reality, one to live with it).
>
>Cheers
>Toerless
>
>___
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

[Eric Vyncke (evyncke)]

On 12/08/15 15:18, "Teco Boot"  wrote:
>
>How works *seamless* WiFi handover with same SSID, with different IPv6
>subnets?
>Single subnet for a neighborhood, with all the multicast suppression?
>Single subnet for a country?

Not sure whether 'community wifi' belongs to this alias but anyway, there
are working solutions with host routes and/or tunnels... Nothing optimum
and probably not really scalable for a whole country.

I will take your single /64 for the whole country as a joke :-)  OTOH,
there are actually solutions for this kind of deployment, let's wait until
Pascal chimes in ;-)

-éric

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

[Eric Vyncke (evyncke)]

>
>
>
>While I pay for it, I never use the millions of WiFi access points I can
>use here in the Netherlands. I tried it once, walking in a small city. At
>the time the handover was completed, the connectivity was gone. It might
>have to do with IEEE and IETF mismatch. Same SSID shall have same IP
>subnet (IEEE) versus each link has its own subnet (some of IETF, no
>formal statement...).

Of course, if every SSID has its own 192.168.0.0/24, oups, this is legacy
IP, so, not a Homenet topic :-O

Sorry could not resist

-éric

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

[Eric Vyncke (evyncke)]

On 12/08/15 07:51, "homenet on behalf of Henning Rogge"
 wrote:
>
>The problem is we are dealing with more and more wireless devices, so
>the medium starts to become congested more easily.
>
>0.1% - 1% packet loss (not frame loss) is possible for unicast, but
>0.1% multicast packet loss is unrealistic.

Some empirical measurements done on large WLAN are worse than those
numbers: range of 10% to 20% of mcast packets lost...

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] 802.11 is just fine for IPv6 [was: Despair]

[Eric Vyncke (evyncke)]

To come back on the discussion why mcast matters for IPv6 while bcast does
not for IPv4:
- IPv6 uses heavily mcast while in IPv4 (ND is quite chatty)
- IPv6 uses many more addresses than IPv4 (hence even more chatty)

A couple of us running very large (more than 1 STA) WiFi network have
experimented issues on dual-stack WiFi deployment cause by this chattiness
of IPv6 over mcast. (and not so much about the packet loss as far as I can
remember but more about wasting airtime to transmit 'tons of mcast'), and,
noticing as a side effect than battery life was impacted.


-éric


On 7/08/15 09:36, "homenet on behalf of Juliusz Chroboczek"

wrote:

>> However, I do think that 802.11 needs to point out to its members that
>>if
>> they don't implement assured multicast replication, IP doesn't work
>> properly.
>
>That's an overstatement.  IPv6 works just fine over 802.11, it just
>suffers from increased multicast packet loss and lower rate.  I don't
>think there's anything in the IPv6 architecture that requires (link-local)
>multicast performance to match unicast performance.
>
>While it would be nice to have better multicast performance, I don't think
>it's productive to be overly alarmist ("IPv6 obsolete before it gets
>deployed, according to IETF spokesperson.  News at eleven.").
>
>-- Juliusz
>
>___
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet