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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Fernando,

Please see inline ...

> -----Original Message-----
> From: Fernando Gont <[e-mail]>
> Sent: 20 October 2020 20:35
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; Owen DeLong <[e-mail]>
> Subject: Re: Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-
> 05: (with DISCUSS and COMMENT)
> 
> 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.
[RW] 

Yes, I appreciate that.  But I don't think that this text makes any more sense to me in RFC7084 either!

From my reading on this document, I would think that using the standard RFC 2119 boilerplate is the best solution, and my reading of RFC 2119 is that it is flexible enough to cover how the terms are being used here.

In particular, RFC 2119 states "Note that the force of these words is modified by the requirement level of the document in which they are used.", and the text in section 6 allows the terms to be used both where it is "required for interoperation" and also "to limit behaviour which has potential to cause harm".

Or, to put it another way, I don't really understand the difference between how the terms are intended to be used here, and how they are normally interpreted.  Further to this thought, it also isn't clear to me whether the terms are meant to be interpreted the same way both in the first part of section 3 that is listing requirements, and also sections 3.1, 3.2, and 3.3 the defines the details.

So, I really think that using the standard boilerplate is the best answer here, or if the terms are defined with different meanings that the text needs to be more explicit about how exactly the terms differ or are expected to be interpreted.  I.e. rather that saying that they are not interpreted the same as 2119, say that they are interpreted the same as 2119, except for X & Y ...  Or alternatively, list the precise meanings that the terms take in this document if they don't follow the definitions in 2119.


> 
> 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.
[RW] 
Okay, I agree that acknowledging people for the work and effort that they have put in is right and important.

Perhaps change:

 "providing valuable comments on [I-D.gont-6man-slaac-renum], on
  which this document is based."

to:

 "providing valuable comments on earlier work from which this
  document is derived."

That could then allow you to drop the reference to gont-6man-slaac-renum?

> 
> 
> 
> >      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.
[RW] 
Agreed.

> 
> Reference #1 is included because the Acks reference such individual
> version (as per explained above).
> 
> Thoughts?
[RW] 

Please see my suggestion above on the acks section.  If you were to make that change then it would allow you to drop this reference.  It just feels odd for a document to have an informative reference to what is logically an partial earlier version of the same work.

But other than the discuss point, these are just comments, and you have the liberty to keep the acks and references as is if you prefer.

Thanks,
Rob


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