Subject: [homenet] Thinking about the implementer - my comments at mic about .home and RFC 7788

From: Dan York <[email-masked]>
Date: Wed, 20 Jul 2016 20:10:50 +0000

Just relaying to the list the comments I made at the mic in the WG session on Monday...

I did not agree with any of the four choices offered by the chairs to the WG for the resolution of the RFC 7788 / .home issue.

I've spent a good bit time over the past four years helping people try to implement standards that we create for technologies such as IPv6, DNSSEC, TLS, etc.  Developers often attempt to use the RFCs and many wind up finding it too confusing of an experience. A few observations:

- Some developers don't pay attention to (or don't see) the "errata" that exists on some of the RFCs. (There was a comment in the room on Monday that some views of the RFCs don't make it easy to find the errata - I've not explored that myself to confirm.) [1]

- Some developers don't understand how our systems work with regard to "updates".  They don't understand that an RFC may be updated by another RFC and that update may fundamentally alter the original RFC.

They are generally told "you need to implement RFC <####> - go do it!" and are left to figure that out.

In talking to a couple of developers over the years, they just go to their favorite search engine, enter the RFC number and pretty much take the first link they find (which may or may not be one of our primary repositories).

I think the easier we can make it for developers to figure out how to implement our standards, the better the chance for more deployment.  If we want HOMENET to be widely used, we need to make the standards as easy to understand and implement.

To me that means a couple of things with regard to RFC 7788 and the .home issue:

1. I would NOT publish any changes we want to make as "errata".

2. I would NOT publish a new RFC that "updates" RFC 7788.

3. I would NOT publish a new RFC that is filled with "internal" analysis of how the process broke down AND THEN also updates RFC 7788.  (Someone seeking to implement the standard is not going to want to wade through the analysis.)

I think the cleanest, simplest thing we can do *for the implementers* is to publish a new RFC that *obsoletes* RFC 7788.  We can then promote the new RFC as the definitive standard for HNCP.  RFC 7788 can get a big "Obsolete" warning in the places we publish it - and documentation and other new RFCs can reference the new RFC.

Just my 2 cents,
Dan

[1] I also know that RFCs are sometimes copied to other locations on the Internet where things such as errata and update links are sometimes lost.  I realize that's not something we can really address - and we can only hope developers seek out the "official" source - but that is also a reality.

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 21 Jul 2016 08:56:01 +0200

Hello Dan, 

> I did not agree with any of the four choices offered by the chairs to the WG for the resolution of the RFC 7788 / .home issue.
[...]
> I think the cleanest, simplest thing we can do *for the implementers* is to publish a new RFC that *obsoletes* RFC 7788.  We can then promote the new RFC as the definitive standard for HNCP.  RFC 7…

If my memory is correct, what you describe was actually choice #1, which got little humming in the room compared to 3 and 4 (and 5...).

Cheers,

- Pierre

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Jul 2016 16:45:55 +0200

The problem with option 1 is that it amounts to the IESG making a change to
a document that the authors don't want made and that doesn't have working
group consensus, or else you open up the document.   I think that right now
we are not really in danger of widespread implementation of homenet,
although I would be overjoyed to hear you tell me that I am wrong (Dan).

So I think the more expedient and kinder route to go is to just do a
follow-on document for now, and wrap the ultimate change, which I hope will
be to allocate .homenet as the default, into the next genuine rev of the
document.   This is less likely to demotivate the authors and the working
group by compressing the update schedule for the document, or by forcing
them/us to do a rev with only one change.

This is _not_ to say that your point (Dan) was wrong.   Just that I don't
think your proposed approach is necessary.   We still do need to consider
implementors, and that's why I think that doing two updates and _then_ a
7788bis is better than just waiting until 7788bis.   However, if we are
going to have a big fight over the followon-document that allocates a
special-use TLN for homenets, that might change my opinion.

On Thu, Jul 21, 2016 at 8:56 AM, Pierre Pfister <[email-masked]>
wrote:

> Hello Dan,
>
> > I did not agree with any of the four choices offered by the chairs to
> the WG for the resolution of the RFC 7788 / .home issue.
> [...]
> >
> > I think the cleanest, simplest thing we can do *for the implementers* is
> to publish a new RFC that *obsoletes* RFC 7788.  We can then promote the
> new RFC as the definitive standard for HNCP.  RFC 7788 can get a big
> "Obsolete" warning in the places we publish it - and documentation and
> other new RFCs can reference the new RFC.
> >
>
> If my memory is correct, what you describe was actually choice #1, which
> got little humming in the room compared to 3 and 4 (and 5...).
>
> Cheers,
>
> - Pierre
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Jul 2016 13:59:25 +0200

> On Jul 21, 2016, at 4:45 PM 7/21/16, Ted Lemon <[email-masked]> wrote:
> 
> The problem with option 1 is that it amounts to the IESG making a change to a document that the authors don't want made and that doesn't have working group consensus, or else you open up the document.   I think that right now we are not really in danger of widespread implementation of homenet, although I would be overjoyed to hear you tell me that I am wrong (Dan).
> 
> So I think the more expedient and kinder route to go is to just do a follow-on document for now, and wrap the ultimate change, which I hope will be to allocate .homenet as the default, into the next genuine rev of the document.   This is less likely to demotivate the authors and the working group by compressing the update schedule for the document, or by forcing them/us to do a rev with only one change.

Ted - can you say more about what, exactly, would be in your follow-on document, and how it would affect the status of RFC 7788?  Or, (below) what would be in two updates and then a 7788bis?

My suggestion is to publish an RFC 7788bis as soon as possible.  7788bis would omit sections 7.4 and 8, which describe DNS matters in HNCP, and include appropriate modifications to section 10.  7788bis would also obsolete RFC 7788.  Note there is an errata filed (but not verified) against section 7.4 that would be resolved by this step.

In my opinion, 7788bis would capture the good work in the document and clearly make the rest of the good technology in RFC 7788 available for implementation.  The WG would then revise sections 7.4 and 8 and publish a second RFC that extends 7788bis with the TLVs and behavior for the DNS matters from RFC 7788, including a name to be used as the default for the Domain-Name TLV and appropriate instructions to IANA to add the name to the Special Use Names registry.  This second RFC would take advantage of the IANA Registry and basic function in 7788bis to extend the protocol for the DNS matters.

- Ralph

> 
> This is _not_ to say that your point (Dan) was wrong.   Just that I don't think your proposed approach is necessary.   We still do need to consider implementors, and that's why I think that doing two updates and _then_ a 7788bis is better than just waiting until 7788bis.   However, if we are going to have a big fight over the followon-document that allocates a special-use TLN for homenets, that might change my opinion.
> 
> 
> On Thu, Jul 21, 2016 at 8:56 AM, Pierre Pfister <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Dan,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/homenet <https://www.ietf.org/mailman/listinfo/homenet>
>