Re: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-rfc6555bis-06: (with COMMENT)

[Tommy Pauly <[e-mail]>]

Hello Adam,

Thanks for the review! We've just pushed an -07 version of the draft that should address your comments, and adds the obsolete note to the abstract as several others had requested.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ <https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-07 <https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-07>
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-07 <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-07>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-07 <https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-07>

Best,
Tommy

> On Oct 23, 2017, at 5:56 PM, Adam Roach <[e-mail]> wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-v6ops-rfc6555bis-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Summary:
> 
> I think it's great that we continue to refine the means for making rapid
> connections in dual-stack environments, and want to thank the authors and
> working group for putting together a well-written and easy-to-follow document.
> I have some concerns about distinguishing normative requirements from an
> "example algorithm" that can be used to meet them, and would like to see better
> clarity around the relationship between this document and existing, deployed
> implementations of RFC6555.
> 
> Details:
> 
> The abstract claims that the document provides an "example" algorithm, while
> the main text of the document describes the algorithm as "RECOMMENDED" (using
> normative language), as well as having a variety of other normative statements
> made regarding its implementation. Given that the document is serving the dual
> purpose of laying out requirements and giving an exemplary (which I would take
> to mean "non-normative") algorithm that satisfies that algorithm, I would
> *strongly* recommend removing normative language from the description of the
> exemplary algorithm.
> 
> In order to make that task easier -- and to clarify the intention of the
> lower-cased word "recommended" in phrases like "The recommended minimum value
> is 100 milliseconds" -- I would further suggest that this document adopt the
> new RFC8174 template instead of using the old RFC2119 template.
> 
> That said, there appears to be a random mix of uppercase and non-uppercase
> "recommended" even when describing the same general concept (e.g., the timer
> cited above is "recommended," while the timeout for processing DNS responses
> after a connection is "RECOMMENDED") -- I suggest an editing pass that
> generally looks at how these terms are used and ensures that normative versus
> non-normative uses are properly distinguished.
> 
> The reason I'm focusing so carefully on normative versus non-normative language
> use in general, and on carefully making the algorithm itself non-normative in
> particular ties to the rationale for obsoleting RFC6555. In an earlier response
> to Mirja's DISCUSS, Tommy Pauly said:
> 
>> A "simple" implementation of the 6555bis algorithm is still
>> aligned with the algorithm in 6555, and we would like to see
>> new implementations taking the nuances of the new algorithm
>> description into account.
> 
> Which makes perfect sense. I've seen evidence that this point -- that an
> implementation of the RFC6555 algorithm is fully compliant with the v2 document
> -- has been broadly missed by the implementation community. See, for example:
> https://groups.google.com/a/chromium.org/forum/m/#!topic/net-dev/GQaqi5WVlPY 
> (and, FWIW, I've had similar private feedback from the relevant decision makers
> inside Mozilla regarding web browser implementations).
> 
> To clarify this situation, I think it is really necessary to include text in
> Appendix A that indicates roughly the same thing as Tommy's text above does.
> 
>