Last Call Review of draft-ietf-capport-rfc7710bis-04
review-ietf-capport-rfc7710bis-04-genart-lc-bryant-2020-05-11-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-capport-rfc7710bis-04-genart-lc-bryant-2020-05-11

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-capport-rfc7710bis-04
Reviewer: Stewart Bryant
Review Date: 2020-05-11
IETF LC End Date: 2020-05-13
IESG Telechat date: Not scheduled for a telechat

Summary:

Ready to publish, though there are a few minor points that the authors could usefully consider.

Major issues: None

Minor issues: 

The maximum length of  the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer
than 255 bytes should not be provisioned via IPv6 DHCP nor IPv6 RA
options.

SB> Some people maintain that operator actions are not covered by RFC2119 language, but one of the purposed of RFC2119 is to draw the readers eye to important points to note, and thus I think it would be useful if an RFC2119 SHOULD NOT was used in the above,

=========

   If the URIs learned via more than one option described in Section 2
   are not all identical, this condition should be logged for the device
   owner or administrator; it is a network configuration error if the
   learned URIs are not all identical.

SB> In a similar vein, I think that ought to be an RFC 2119 SHOULD

=========

7.3.  URIs

   [1] https://tickets.meeting.ietf.org/wiki/IETF106network#Experiments

   [2] https://tickets.meeting.ietf.org/wiki/CAPPORT

   [3] https://community.polycom.com/t5/VoIP-SIP-Phones/DHCP-
       Standardization-160-vs-66/td-p/72577

SB> I am not sure there is anything to be done about it, but I worry about the stability of the above references in a Standard. wiki's are by definition unstable and vendor websites change at a whim.


Nits/editorial comments:

There are two instances of 

   The maximum length of the URI that can be carried in IPv4 DHCP is 255
   bytes, so URIs longer than 255 bytes should not be provisioned via
   IPv6 DHCP options.

SB> This is fine text, but one could take the view that given the earlier explanation all that is needed is:

URIs longer than 255 bytes SHOULD NOT be provisioned via  IPv6 DHCP options.

Alternatively it might be less oblique to say

For consistency with IPv4 DHCP limitations URIs longer than 255 bytes SHOULD NOT be provisioned via IPv6 DHCP options.