Subject: [Int-dir] A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Oct 2016 15:22:41 +0000

Dear all :

I am an assigned INT directorate reviewer for https://tools.ietf.org/html/draft-kivinen-802-15-ie-02. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

Document: draft-kivinen-802-15-ie
IEEE 802.15.4 Information Element for IETF
Reviewer: Pascal Thubert
Review Date: October 13, 2016
IETF Last Call Date: TBD

Summary:

Tero's draft was developed outside of the working group but is an enabler for solutions developed at 6lo and 6TiSCH. This review comes after the ones by Pat and then Charlie, who provided the adequate comments regarding IEEE802.15.4 and ANA. This review abstains to comment on that. Also, this review is made in the light of the Charlie's proposed update.

Major issues:

I am not sure that "expert review" is the right policy for section 8 on IANA considerations. This registry is for IETF use only. Suggestion is to use "RFC required":
"
   Future assignments in this registry are to be coordinated via IANA under the policy of "RFC Required" (see RFC 5226).
"

Intended Status for this document: Seems to me that  informational should be the right level; see for instance https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-01
Related: In the -04 that Charlie attached, I saw that uppercase imperatives were added. I do not think that's a good idea:

-         Imperative "MUST" in section 7 refers to the writing of other documents and is probably not appropriate.

-         Imperative "SHOULD" in section 7 does not refer to the behavior of the implementation of this document and is probably not appropriate either.

-         If those go away, ref to RFC 2119 is not needed and the specification can take the informational path, much easier

Minor issues:

 The need for section 5 does not appear until the IANA section. The way it is done works, but leaves the reader puzzled. Swapping 5 and 6 and then one last sentence saying that there is no need to block subtype IDs in the IETF IE for Vendor Specific work would have made the reading a bit smoother.

Do we need 20% of the subtypes for experimentations? 240 to 255 seems enough to me...

Many thanks, Tero, for this much needed work!

Pascal

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 24 Oct 2016 21:07:04 -0700

Hello Pascal,

I hope that the ADs can advise about the level of review required for 
additional assignments.  Your suggestion for RFC required is also 
reasonable, I think, given that the IETF is owning the assignment.  I 
observe that "RFC required" is about the same as "MUST be supported by 
an RFC", which means to me that the word "required" also carries with it 
the meaning specified by 2119. But anyway I am happy to go along with 
whatever people decide about this.  I doubt that there is much room for 
misinterpretation one way or the other.

What do you think about my suggestion to put the "Vendor IE" section 
into the appendix?

Regards,
Charlie P.

On 10/24/2016 8:22 AM, Pascal Thubert (pthubert) wrote:
>
> Dear all :
>
> I am an assigned INT directorate reviewer for 
> https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 
> <https://tools.ietf.org/html/draft-kivinen-802-15-ie-02>. These 
> comments were written primarily for the benefit of the Internet Area 
> Directors. Document editors and shepherd(s) should treat these 
> comments just like they would treat comments from any other IETF 
> contributors and resolve them along with any other Last Call comments 
> that have been received. For more details on the INT Directorate, see 
> http://www.ietf.org/iesg/directorate.html.
>
> Tero’s draft was developed outside of the working group but is an 
> enabler for solutions developed at 6lo and 6TiSCH. This review comes 
> after the ones by Pat and then Charlie, who provided the adequate 
> comments regarding IEEE802.15.4 and ANA. This review abstains to 
> comment on that. Also, this review is made in the light of the 
> Charlie’s proposed update.
>
> Major issues:
>
> I am not sure that “expert review” is the right policy for section 8 
> on IANA considerations. This registry is for IETF use only. Suggestion 
> is to use “RFC required”:
>
> “
>
>    Future assignments in this registry are to be coordinated via IANA 
> under the policy of "RFC Required" (see RFC 5226).
>
> “
>
> Intended Status for this document: Seems to me that  informational 
> should be the right level; see for instance 
> https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-01
>
> Related: In the -04 that Charlie attached, I saw that uppercase 
> imperatives were added. I do not think that’s a good idea:
>
> -Imperative “MUST” in section 7 refers to the writing of other 
> documents and is probably not appropriate.
>
> -Imperative “SHOULD” in section 7 does not refer to the behavior of 
> the implementation of this document and is probably not appropriate 
> either.
>
> -If those go away, ref to RFC 2119 is not needed and the specification 
> can take the informational path, much easier
>
> Minor issues:
>
>  The need for section 5 does not appear until the IANA section. The 
> way it is done works, but leaves the reader puzzled. Swapping 5 and 6 
> and then one last sentence saying that there is no need to block 
> subtype IDs in the IETF IE for Vendor Specific work would have made 
> the reading a bit smoother.
>
> Do we need 20% of the subtypes for experimentations? 240 to 255 seems 
> enough to me…
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Oct 2016 09:13:36 +0000

Hello Charlie

Moving the vendor IE section to appendix would work for me just fine, but then I'd expect a sentence in the IANA section that explains that there is no reservation for vendors subtypes, rationale being in appendix or something. The move is more important if the doc stays standard track, but I do not see a good reason for that.

Note also that things can be required by an RFC without the RFC 2119 imperative (uppercase) form. That form is a clarification.

Take care,

Pascal

From: Int-dir [mailto:[email-masked]] On Behalf Of Charlie Perkins
Sent: mardi 25 octobre 2016 06:07
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Int-dir] [6tisch] A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR

Hello Pascal,

I hope that the ADs can advise about the level of review required for additional assignments.  Your suggestion for RFC required is also reasonable, I think, given that the IETF is owning the assignment.  I observe that "RFC required" is about the same as "MUST be supported by an RFC", which means to me that the word "required" also carries with it the meaning specified by 2119.  But anyway I am happy to go along with whatever people decide about this.  I doubt that there is much room for misinterpretation one way or the other.

What do you think about my suggestion to put the "Vendor IE" section into the appendix?

Regards,
Charlie P.

Summary:

Major issues:

Minor issues:

Pascal

6tisch mailing list

[email-masked]<mailto:[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Oct 2016 15:43:08 +0300

Pascal Thubert (pthubert) writes:
> Major issues:
> 
> I am not sure that “expert review” is the right policy for section 8 on IANA
> considerations. This registry is for IETF use only. Suggestion is to use “RFC
> required”:
> 
> “
> 
>    Future assignments in this registry are to be coordinated via IANA under
> the policy of "RFC Required" (see RFC 5226).
> 
> “

I disagree on that. RFC required has caused issues earlier, and I
think expert review is better. We have used expert review in all IKEv2
related registries (and I am the expert there), and I think expert
review is good option here too.

Why do you think that RFC required is better than expert review?

As this is cross wg registry RFC required might even be lower bar than
expert review, as one WG might put forward and RFC taking for example
28 subtypes (draft-bormann-6lo-coap-802-15-ie-00.txt) and other users
of this registry might not notice that... The expert can make sure
that all relevant WGs are kept in loop for the allocations.

> Intended Status for this document: Seems to me that  informational should be
> the right level; see for instance 

Yes, that is correct. I fixed it to be informational. 

> Related: In the -04 that Charlie attached, I saw that uppercase imperatives
> were added. I do not think that’s a good idea:
> 
> -         Imperative “MUST” in section 7 refers to the writing of other

We have had such texts earlier, and I agree that there is no real
difference whether it is "MUST be described" or "needs to be
described".

I am happy to go with either way.

> -         Imperative “SHOULD” in section 7 does not refer to the behavior of
> the implementation of this document and is probably not appropriate either.

Same here.

> -         If those go away, ref to RFC 2119 is not needed and the
> specification can take the informational path, much easier
> 
> Minor issues:
> 
>  The need for section 5 does not appear until the IANA section. The way it is
> done works, but leaves the reader puzzled. Swapping 5 and 6 and then one last
> sentence saying that there is no need to block subtype IDs in the IETF IE for
> Vendor Specific work would have made the reading a bit smoother.

I now moved the vendor specific IE in IEEE 820.15.4 to appendix, and
added text to IANA considerations saying that we do not need vendor
specific IEs:

7.  IANA Considerations
...
   Note, that there is Vendor specific IEs already defined in the IEEE
   802.15.4 (see Appendix A), and because of this, there is no need to
   reserve any subtype IDs for the vendor-specific uses.
...
Appendix A.  Vendor Specific IE in IEEE 802.15.4

   IEEE 802.15.4 has already several numbers for different Vendor
   Specific IE types.  There is one for the Vendor Specific Header IE
   for Header IEs.  There is one incorrectly named Vendor Specific
   Nested IE for Payload IEs, and there is another one with exactly the
   same name, but under the MLME Nested IE long format.  All of the
   Vendor Specific IEs start with a 3-octet vendor OUI to identify the
   organization.
...

> Do we need 20% of the subtypes for experimentations? 240 to 255
> seems enough to me…

Most likely not, but if we have bit larger space allocated for them,
then people might not always take the first one...

On the other hand, we do have 200 numbers for allocations, I think
that is also enough. If we ever get close to that number, I think we
want to write the new RFC and specify the extension format of for the
subtypes, and while doing that we can make the experimental use space
smaller too.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Oct 2016 15:57:35 +0300

Pascal Thubert (pthubert) writes:
> Moving the vendor IE section to appendix would work for me just fine, but then
> I’d expect a sentence in the IANA section that explains that there is no
> reservation for vendors subtypes, rationale being in appendix or something.
> The move is more important if the doc stays standard track, but I do not see a
> good reason for that.
> 
> Note also that things can be required by an RFC without the RFC 2119
> imperative (uppercase) form. That form is a clarification.

So I have now submitted new version. Things that I did not change are
the RFC 2119 text in the security considerations section, and the IANA
allocation policy.

I left the RFC2119 text there in the security considerations section,
as Charlie wanted it there, my original version did not have RFC2119
text there. I do not really care which way it is...

I also left the IANA allocation policy to expert review, as I think it
is better for this type of registries than RFC required.

----------------------------------------------------------------------
From: [email-masked]
Subject: New Version Notification for draft-kivinen-802-15-ie-04.txt
Message-ID: <[email-masked]>
Date: Tue, 25 Oct 2016 05:53:16 -0700

A new version of I-D, draft-kivinen-802-15-ie-04.txt
has been successfully submitted by Tero Kivinen and posted to the
IETF repository.

Name:           draft-kivinen-802-15-ie
Revision:       04
Title:          IEEE 802.15.4 Information Element for IETF
Document date:  2016-10-25
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-kivinen-802-15-ie-04.txt
Status:         https://datatracker.ietf.org/doc/draft-kivinen-802-15-ie/
Htmlized:       https://tools.ietf.org/html/draft-kivinen-802-15-ie-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-kivinen-802-15-ie-04

Abstract:
   IEEE Std 802.15.4 defines Information Elements (IEs) that can be used
   to extend 802.15.4 in an interoperable manner.  The IEEE 802.15
   Assigned Numbers Authority (ANA) manages the registry of the
   Information Elements.  This document formulates a request for ANA to
   allocate a number from that registry for IETF, and describes how the
   IE is formatted to provide subtypes.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Oct 2016 13:02:35 +0000

Hello Tero:

CC ing Amanda for clarification on "RFC Required". 
For all I know,  with "RFC required", the IANA must also request that the IESG designate an expert to review the new registration.
The difference if I am correct is that "RFC required" adds limit the use of the IETF IE only to address requests from IETF specifications.
Amanda: is this correct?

Tero: Do you think you need assignments for use outside the IETF?  Or that a value could be assigned without an RFC?

Take care,

Pascal

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: mardi 25 octobre 2016 14:43
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR

Pascal Thubert (pthubert) writes:
> is to use “RFC

I disagree on that. RFC required has caused issues earlier, and I think expert review is better. We have used expert review in all IKEv2 related registries (and I am the expert there), and I think expert review is good option here too.

As this is cross wg registry RFC required might even be lower bar than expert review, as one WG might put forward and RFC taking for example
28 subtypes (draft-bormann-6lo-coap-802-15-ie-00.txt) and other users of this registry might not notice that... The expert can make sure that all relevant WGs are kept in loop for the allocations.

> documents and is probably not appropriate.

We have had such texts earlier, and I agree that there is no real difference whether it is "MUST be described" or "needs to be described".

Same here.

> subtype IDs in the IETF IE for Vendor Specific work would have made the reading a bit smoother.

I now moved the vendor specific IE in IEEE 820.15.4 to appendix, and added text to IANA considerations saying that we do not need vendor specific IEs:

7.  IANA Considerations
...

> Do we need 20% of the subtypes for experimentations? 240 to 255 seems 

Most likely not, but if we have bit larger space allocated for them, then people might not always take the first one...

On the other hand, we do have 200 numbers for allocations, I think that is also enough. If we ever get close to that number, I think we want to write the new RFC and specify the extension format of for the subtypes, and while doing that we can make the experimental use space smaller too.
--
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Oct 2016 13:33:59 +0000

Hello Tero:

[Pascal] >> Do we need 20% of the subtypes for experimentations? 240 to 255

> Most likely not, but if we have bit larger space allocated for them,[Pascal]  then people might not always take the first one...

> On the other hand, we do have 200 numbers for allocations, I think that is also enough.
[Pascal] We never know... but that's not my real issue

> If we ever get close to that number, I think we want to write the new RFC and specify the extension format of for the subtypes, and while doing that we can make the experimental use space smaller too.
[Pascal] Well, no. If people have a concern with 16 experimental values, and there is a lot of unallocated space, it is easy to allocate another range from the unallocated space. OTOH, you cannot easily give back from the experimental range, because there may be experiments using it that could collision with the new assignments. I'd rather allocate the extra experimental space from the 00 extension, and leave a maximum of space from the one-octet subtype for mainline RFCs as opposed to experiments...

Makes sense?

Pascal
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Oct 2016 21:12:09 +0300

Pascal Thubert (pthubert) writes:
> For all I know,  with "RFC required", the IANA must also request
> that the IESG designate an expert to review the new registration. 
> The difference if I am correct is that "RFC required" adds limit the
> use of the IETF IE only to address requests from IETF
> specifications. 
> Amanda: is this correct?

I do not think that is correct. When using specification required,
then designated expert is also needed to say whether the specification
is clear enough etc.

When using RFC required, then any RFC is enough, including RFC Editor
Independent submission. There is no expert needed, as the RFCs are
considered to be good enough documents.

>From RFC 5226:

    RFC Required - RFC publication (either as an IETF submission or as
        an RFC Editor Independent submission [RFC3932]) suffices.
	Unless otherwise specified, any type of RFC is sufficient
	(e.g., Informational, Experimental, Standards Track, etc.).

> Tero: Do you think you need assignments for use outside the IETF?

No. This is IETF IE, there should not be any assignments outside the
IETF. 

> Or that a value could be assigned without an RFC?

Most likely not, but expert review makes the early allocations easier,
as experts are usually experts in those registries they take care of,
and can say whether the document is ready enough to get early
allocations (they are not really early allocations as that case, as
early allocations only cover the rfc required etc cases).

When using RFC required, the working group chairs and area director
will make that decision. While we still have working groups, then
there is most likely enough expertise there too, but after WGs are
closed down, there might be issues.
-- 
[email-masked]

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Tue, 25 Oct 2016 18:41:30 +0000

Hi,

> 	(e.g., Informational, Experimental, Standards Track, etc.).

That's correct. The only procedures that require expert review are the Expert Review and Specification Required procedures. 

The next-most-rigorous procedure is RFC Required, which as Tero noted, can mean any type of RFC.

If you want to require an IETF-stream RFC without requiring a standards-track RFC, the procedure you want would be IETF Review. 

There are a few registries that use hybrid registration procedures. If it's what fits the registry best, you could state that the registration procedure is "IETF-stream RFC reviewed by an IESG-designated expert" (or "IETF Review with Expert Review"). 

Alternatively, if an RFC is not required, but there are specific requirements an IESG-designated expert should take into account, these could be listed in a sub-section of the IANA Considerations section. 

Best regards,

Amanda Baber
Lead IANA Services Specialist
PTI