Subject: [dhcwg] IETF-106 DHC WG Draft Minutes

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 Dec 2019 15:13:31 +0000

Hi:

I have published DRAFT minutes for the IETF-106 DHC WG session - see https://datatracker.ietf.org/meeting/106/materials/minutes-106-dhc-00.

They have been reviewed by your co-chairs, but we welcome corrections or other changes.

  *   Bernie & Tomek

---

From: [email-masked]
Date: Mon, 2 Dec 2019 16:54:37 +0100

Hi Bernie,

Thanks for posting them. A couple of comments:

1 question regarding draft-ietf-dhc-dhcpv6-yang - Do we know who volunteered to review?

1 comment regarding draft-fkhp-dhc-dhcpv6-pd-relay-requirements - For the point about the use of RFC2119 language, I noted during that Suresh advised putting the draft back to standards track to solve this, but this is not recorded in the minutes.

Thanks,
Ian

> On 2. Dec 2019, at 16:13, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi:
>  
> I have published DRAFT minutes for the IETF-106 DHC WG session – seehttps://datatracker.ietf.org/meeting/106/materials/minutes-106-dhc-00 <https://datatracker.ietf.org/meeting/106/materials/minutes-106-dhc-00>.
>  
> Bernie & Tomek
> _______________________________________________
> dhcwg mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 Dec 2019 16:12:39 +0000

Hi Ian and thanks for the feedback!

>1 question regarding draft-ietf-dhc-dhcpv6-yang - Do we know who volunteered to review?

No, sorry I don’t recall who it was and we didn’t ask. Perhaps whoever did volunteer will let us know. And, it really would be best to get even more to volunteer!!

>1 comment regarding draft-fkhp-dhc-dhcpv6-pd-relay-requirements - For the point about the use of RFC2119 language, I noted during that Suresh advised putting the draft back to standards track to sol…

OK, I can update the minutes. Though another solution would be to keep it Informational but remove 2119 language. I’m not sure why it has been the case, but many of these kinds of documents seem to be Informational instead of Standards Track.

And, I though you indicated you were following RFC7084 and the slides indicate this:

  *   Follows the RFC7084 approach of an Informational document with RFC2119 requirements language (changed in -v02)
but that is not the case. RFC7084 says:

   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 RFC 2119<https://tools.ietf.org/html/rfc2119> [RFC2119<https://tools.ietf.org/html/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 “are not used as described in RFC 2119”. Whereas your document has:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

   "OPTIONAL" in this document are to be interpreted as described in BCP<https://tools.ietf.org/html/bcp14>

   14<https://tools.ietf.org/html/bcp14> [RFC2119<https://tools.ietf.org/html/rfc2119>] [RFC8174<https://tools.ietf.org/html/rfc8174>] when, and only when, they appear in all

   capitals, as shown here.  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 (preferably

   in RFC or stable form) to provide additional guidance to implementers

   regarding any protocol implementation required to produce a DHCP

   relaying router that functions successfully with prefix delegation.

Though not really sure it makes a difference as it appears that the RFC7084 usage is frowned upon.

  *   Bernie
From: [email-masked] <[email-masked]>
Sent: Monday, December 2, 2019 10:55 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] IETF-106 DHC WG Draft Minutes

Hi Bernie,

Thanks,
Ian

On 2. Dec 2019, at 16:13, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Hi:

I have published DRAFT minutes for the IETF-106 DHC WG session – seehttps://datatracker.ietf.org/meeting/106/materials/minutes-106-dhc-00.

  *   Bernie & Tomek
_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: [email-masked]
Date: Fri, 6 Dec 2019 17:59:56 +0100

Hi Bernie,

Yes, that was a mistake arising from adapting the text from RFC7084 to the newer requirements boilerplate. I’ll fix it depending on which track we go for.

My preference would be to have RFC2119 language. This makes for much simpler discussions with vendors about whether their implementation is compliant or not. As to whether this mean that we need to go for Standards track or not, I don’t know. There are a number of Informational requirements type RFCs that do this (e.g. RFC85885 was published back in May), but I wasn’t involved in the IESG discussions about these. Any guidance here would be appreciated.

Thanks,
Ian

> On 2. Dec 2019, at 17:12, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Follows the RFC7084 approach of an Informational document with RFC2119 requirements language (changed in -v02)
>    described in RFC 2119 <https://tools.ietf.org/html/rfc2119> [RFC2119 <https://tools.ietf.org/html/rfc2119>].  This document uses these keywords
>    "OPTIONAL" in this document are to be interpreted as described in BCP <https://tools.ietf.org/html/bcp14>
>    14 <https://tools.ietf.org/html/bcp14> [RFC2119 <https://tools.ietf.org/html/rfc2119>] [RFC8174 <https://tools.ietf.org/html/rfc8174>] when, and only when, they appear in all
> Bernie
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On 2. Dec 2019, at 16:13, Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi:
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 17:24:23 +0000

Hi:

We may have to ask Suresh or v6ops chairs/Ads as I don’t recall that discussion either.

In https://datatracker.ietf.org/doc/rfc8585/ballot/, I can only find comments by Mirja Kuhlewind that mentions 2119/Informational but doesn’t seem that it was significant.

Mirja KühlewindNo Objection
Comment (2019-01-09 for -12)
Some more processing-related comments:

1) "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document, are not used as described in RFC 2119 [RFC2119]."
While it is not forbidden to define their own language requirements, I find this really confusing. I've seen that RFC7084 uses the same definition but actually I don't think the usage is really that different. I'd say the keywords are used in a similar fashion in other informational docs.

…

Perhaps there are some thoughts from WG members as to whether this should be Informational, Standards Track, or just BCP which from https://tools.ietf.org/rfc/bcp/bcp1.txt seems to be a completely separate process.

From at least from 2119, these keywords are for “standards track”:

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.

Yet, RFC 8174 seems to have relaxed this as it replaces the above with:

   In many IETF documents, several words, when they are in all capitals
   as shown below, are used to signify the requirements in the
   specification.  These capitalized words can bring significant clarity
   and consistency to documents because their meanings are well defined.
   This document defines how those words are interpreted in IETF
   documents when the words are in all capitals.

So, it seems to me that RFC 8174 has extended this usage to any IETF document, regardless of status (Info, Standards, BCP).

Thus, it seems to me there is actually no issue anymore with using these in Informational documents.

  *   Bernie
From: Ian Farrer <[email-masked]>
Date: Friday, December 6, 2019 at 12:00 PM
To: Bernie Volz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dhcwg] IETF-106 DHC WG Draft Minutes

Hi Bernie,

Thanks,
Ian

On 2. Dec 2019, at 17:12, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

  *   Bernie
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, December 2, 2019 10:55 AM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] IETF-106 DHC WG Draft Minutes

Hi Bernie,

Thanks,
Ian

Hi:

  *   Bernie & Tomek

---

From: Eliot Lear <[email-masked]>
Date: Fri, 6 Dec 2019 11:25:57 -0800

> On 2 Dec 2019, at 07:54, [email-masked] wrote:
> 
> Hi Bernie,
> 

I don’t know who volunteered in the meeting, but I can review after the beginning of the year.

Eliot

> [email-masked]