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,

> -----Original Message-----
> From: Fernando Gont <[e-mail]>
> Sent: 21 October 2020 11:17
> 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)
> 
> 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...
> 
[RW] 

Note, I'm not suggesting that we change the text in RFC 7084 (water under the bridge), but I do think that the text in this document should be clear.

Probably this will get discussed in the telechat tomorrow.

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

Yes, I agree that applying RFC 2119 language to a list of requirements can seem a bit strange.

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

Another choice would be to just use "must not"/"should"/"must"/"should not" for the requirements L-15 to L-18 in section 3, and then you could use the standard RFC 2119 boiler plate for the usage of these terms in the rest of the document.



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

Regards,
Rob


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