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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 19 Oct 2020 11:49:40 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-v6ops-cpe-slaac-renum-05: Discuss

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-cpe-slaac-renum/

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

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

    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.

    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?

Regards,
Rob

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 16:34:36 -0300

Hello, Robert,

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

On 19/10/20 15:49, Robert Wilton via Datatracker wrote:
[....]

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

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

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

> reference is not required since it is superseded by ietf-6man-slaac-renum and

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 21 Oct 2020 09:14:48 +0000

Hi Fernando,

Please see inline ...

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

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

> Refs #2 and #3 are needed, since those two are complementing documents
[RW] 
Agreed.

> version (as per explained above).
[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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 07:16:49 -0300

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

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.

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

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,

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 21 Oct 2020 14:22:29 +0000

Hi Fernando,

> Sent: 21 October 2020 11:17
[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.

[RW] 

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

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

> > what is logically an partial earlier version of the same work.

Thanks for accommodating.

Regards,
Rob

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 11:44:48 -0300

Hi, Rob,

On 21/10/20 11:22, 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]
>>> 
> 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.
> 

I see your point. I just meant that I'd like the input from our AD, such
that I don't screw things up myself. :-)

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

I'm all for making things more clear. I've sent a heads-up to Warren and 
see if he weighs in, so that we can all converge on what might be the 
best way forward.

Does that sound reasonable?

Thanks a lot!

Regards,