IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
RFC 7042

Note: This ballot was opened for revision 03 and is now closed.

(Joel Jaeggli) (was Discuss, Yes) Yes

Comment (2013-08-29)
No email
send info
clearing due to completion of dicussion with iana.

old comment:

minor  adjustment due to feedback provided by ieee rac is needed.

since this doesn't not impact IETF assignments I think it's fine. imho I reviewed and I do not belive that it impacts the consensus we already have.

from donald.
   	   From -04 to -05	
 	   Re-cast informational material about relevant IEEE assignment	
 	   policies to take into account the planned changes by the IEEE	
 	   Registraion Authority as per [RAC-OUIdraft].	
 	   Add a sentence forshadowing the future possibility of EUI-128 MAC	
 	   Add InfiniBand as example of EUI-64 use.	
 	   Minor editorial changes.

(Sean Turner) (was No Objection) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2013-06-12 for -03)
No email
send info
Thank you for including section 1.1 which helped my review considerably.


Maybe reversing the order of sections 1.1 and 1.2 would make 1.1 easier
to read.


<pedant alert>

   ([RFC5342] had a requirement for parallel unicast and multicast
   assignments under some circumstances even when both types were not
   applied for. That requirement has proven impractical and is
   eliminated in this document.)

s/both types were/one of the types was/


<double pedant alert>

      IANA always sends the Template to an appointed Expert.  If the
         Expert recuses themselves or is non-responsive, IANA may choose
         an alternative appointed Expert or, if none are available, will
         contact the IESG.

s/none are/none is/


I am unwarrantedly bothered by the presence of Appendix B. I struggle to
see that it serves any purpose except to provide a secondary and 
potentially conflicting source of information compared to the 

Would the authors consider removing it and leaving the pointers to the
registries as the only source of information?

(Stephen Farrell) (was Discuss) No Objection

(Brian Haberman) No Objection

(Barry Leiba) (was Discuss) No Objection

(Ted Lemon) (was Discuss, No Objection) No Objection

Comment (2013-07-26 for -04)
No email
send info
What's the point of Appendix B?   If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this list, since what's in this document is doomed to become out of date? I don't find a list like this on the IANA web site. I don't specifically object to Appendix B; I just think that if these lists are useful, they ought to be maintained.

Give that Joe's draft has passed IETF last call, I think my DISCUSS is moot, so I'm dropping it.


Based on Donald's response to the below point, I realize that I should have entered this as a DISCUSS, so I am correcting that mistake.   Here't the original text of the comment:

What is the purpose of section 5.2?   It seems out of place with respect to the rest of this document.   I can't really object to it, since what it says is true, but it seems inappropriate to mention IANA RRTYPE assignments in a document about 802 code points.

Here's my further explanation of the problem:

The use of these RRtypes is not documented in any IETF publication, so documenting it in this one is precedent-setting.   Given that there has been substantial controversy about these RRtypes on the IETF mailing list (although it seems to be in a lull at the moment), publishing a reference to them in a completely unrelated document seems inappropriate.

This document is an individual submission with a clear focus on documenting IEEE 802 code points.   Knowing the authors, I think it is reasonable to assume that it has gotten sufficient review from experts on IEEE 802 code points, and that the consensus of the IETF on those points is valid.

That it additionally documents a DNS RRTYPE code point suggests to me that this section likely slipped under the radar and got no expert review from DNS experts, and that in fact this particular text does not represent any meaningful IETF consensus.

This DISCUSS can be cleared either by removing the text that documents these two RRtypes, or by doing a new last call on the IETF mailing list that specifically points out that this draft documents these two RRtypes.

It may be that there is a similar problem relating to the AFN allocation. It seems similarly unrelated, but probably isn't controversial, so it may be that this part of section 5.2 is not problematic. I will not object if this part of section 5.2 is kept, even if no new consensus call is done.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection