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

[Fernando Gont <[e-mail]>]

On 21/10/20 06:14, Rob Wilton (rwilton) wrote:
[....]
>>> 
>>> 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.
[....]
>> 
>> 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!

I'll let our AD (Warren) weigh in, since this would probably be a 
decision that would need his advice...



> 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".

But in all cases the terminology seems to be directed at protocol 
specifications more than the kind of thing we are doing here.



> 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.

That is indeed a valid point. Since there are places where we're quoting 
requirements from protocol specs (and hence the keywords should be 
interpreted as in RFC2119), while our own requirements should be 
interpreted as discussed in Section 2. SO I guess that at the very least 
this should be clarified.



> 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.

Fair enough. The later would seem to me like the easier way forward.



[....]
>>> 7.  Acknowledgments
>>> 
[....]
>>> 
>>> 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.
>> 
[....]
>> 
>> 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?

I don't mind doing that. Will do.


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

Fair enough.

Will apply the change.

Thanks!

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