> On Jul 21, 2016, at 4:45 PM 7/21/16, Ted Lemon <[email protected]> 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 protected] > <mailto:[email protected]>> 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 protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/homenet > <https://www.ietf.org/mailman/listinfo/homenet> > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
