Re: [v6ops] Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

[Fernando Gont <[e-mail]>]

Hello, Robert,

Thanks so much for your feedback! In-line....

On 19/10/20 15:49, Robert Wilton via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Hi,
> 
> Hopefully this isn't hard to resolve, but I don't understand the meaning of the
> text in section 2:
> 
>      2.  Requirements Language
> 
>         Take careful note: Unlike other IETF documents, the key words "MUST",
>         "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
>         "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
>         described in [RFC2119].  This document uses these keywords not
>         strictly for the purpose of interoperability, but rather for the
>         purpose of establishing industry-common baseline functionality.  As
>         such, the document points to several other specifications (preferable
>         in RFC or stable form) to provide additional guidance to implementers
>         regarding any protocol implementation required to produce a
>         successful CE router that interoperates successfully with a
>         particular subset of currently deploying and planned common IPv6
>         access networks.
> 
>         Note: the aforementioned terms are used in exactly the same way as in
>         [RFC7084], with the above explanation copied verbatim from
>         Section 1.1 of [RFC7084].
> 
> This paragraph tells me how these words are not used. But it doesn't seem to
> explain how they are meant to be interpreted.
> 
> My only assumption is that these words have no special meaning in this document
> at all, but they than raises the question as to why not to write them all in
> lower case.  Alternatively, following the standard RFC 2119 rules and
> boilerplate would also seem to make sense ...

These words are used in exactly the same way as RFC7084, the RFC this 
document is meant to update.

In a way, caps are employed to flag the advice. But since the use of 
caps might be otherwise confusing for folks that might interpret them as 
in RFC2119, we include the above text (as RFC7084 did).


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
>      3.2.  LAN-side Option Lifetimes
> 
>         CE Routers SHOULD override the default PIO "Preferred Lifetime" and
>         "Valid Lifetime" values from [RFC4861], and employ shorter lifetime
>         values to improve the robustness to renumbering events, while
>         complying with the requirements from Section 2.1 of this document and
>         the recommendations in [RFC7772].
> 
> The reference to Section 2.1 should probably be to section 3?

It should reference Section 3.1. -- somehow the reference was hardcoded 
(as opposed to an xml reference), and hence it wasn't updated when we 
updated the draft. (Good grief! We'll fix this).



>      7.  Acknowledgments
> 
>         The authors would like to thank Owen DeLong, Philip Homburg, and Ted
>         Lemon, for their valuable help in improving this document via
>         successive detailed reviews.
> 
>         The authors would like to thank Mikael Abrahamsson, Brian Carpenter,
>         Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo
>         Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade,
>         Pete Resnick, Mark Smith, Job Snijders, Sander Steffann, Ole Troan,
>         Loganaden Velvindron, Timothy Winters, Christopher Wood, and
>         Chongfeng Xie, for providing valuable comments on earlier versions of
>         this document.
> 
>         The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim
>         Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick
>         Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon,
>         Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael
>         Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for
>         providing valuable comments on [I-D.gont-6man-slaac-renum], on which
>         this document is based.
> 
> Is the third paragraph definitely needed in this document?  Perhaps
> ietf-6man-slaac-renum which is based on gont-6man-slaac-renum could contain
> this acknowledgement?  Or perhaps you could merge the two paragraphs into one,
> if this is an earlier version of this document.  This would also allow you to
> remove one of the references to similarly named documents in the references.

Clarification:
draft-gont-6man-slaac-renum originally contained what became three 
separate documents:
* draft-ietf-6man-slaac-renum
* draft-ietf-v6ops-slaac-renum
* draft-ietf-v6ops-cpe-slaac-renum

So the early feedback on draft-gont-6man-slaac-renum has benefited all 
three document. My personal policy regarding Acknowledgements is to be 
as generous as possible, since I appreciate the time and effort spent by 
participants to help improve the documents.

That said, I try to be factually correct regarding what they have 
reviewed, for at least two reasons:
* I don't want to pretend that some participant has reviewed something 
that he/she has not reviewed (e.g., I don't want to pretend that the 
document passed their filter).
* I don't even know if claiming that a participant has reviewed a 
document he/she has not might have implications in the presence of IPRs 
or other kind of similar stuff.

That's why the Acks are spelled out like that.



>      8.2.  Informative References
> 
>         [I-D.gont-6man-slaac-renum]
>                    Gont, F., Zorz, J., and R. Patterson, "Improving the
>                    Robustness of Stateless Address Autoconfiguration (SLAAC)
>                    to Flash Renumbering Events", draft-gont-6man-slaac-
>                    renum-08 (work in progress), May 2020.
> 
>         [I-D.ietf-6man-slaac-renum]
>                    Gont, F., Zorz, J., and R. Patterson, "Improving the
>                    Robustness of Stateless Address Autoconfiguration (SLAAC)
>                    to Flash Renumbering Events", draft-ietf-6man-slaac-
>                    renum-01 (work in progress), August 2020.
> 
>         [I-D.ietf-v6ops-slaac-renum]
>                    Gont, F., Zorz, J., and R. Patterson, "Reaction of
>                    Stateless Address Autoconfiguration (SLAAC) to Flash-
>                    Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work
>                    in progress), August 2020.
> 
> I was surprised that this document has informative references to three other
> very similarly named documents!  I would think that at least the first
> reference is not required since it is superseded by ietf-6man-slaac-renum and
> thus could be elided?

In retrospective, we should have probably named the files differently 
(lesson learned!).

Refs #2 and #3 are needed, since those two are complementing documents 
to the present one.

Reference #1 is included because the Acks reference such individual 
version (as per explained above).

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492