Re: [Dhcpv6bis] Genart telechat review of draft-ietf-dhc-rfc3315bis-10

"Bernie Volz (volz)" <volz@cisco.com> Thu, 18 January 2018 20:50 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcpv6bis@ietfa.amsl.com
Delivered-To: dhcpv6bis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F3C12D868 for <dhcpv6bis@ietfa.amsl.com>; Thu, 18 Jan 2018 12:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YMaQEbCSwjv for <dhcpv6bis@ietfa.amsl.com>; Thu, 18 Jan 2018 12:50:02 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1694F12D867 for <dhcpv6bis@ietf.org>; Thu, 18 Jan 2018 12:50:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28302; q=dns/txt; s=iport; t=1516308602; x=1517518202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kP5BuUaySNpVNGXFI4Q3nnSFv1hLZg1HcRqwADzmxZc=; b=RTwLNo3RTjIzJAjd+sxF4Re27W+lgIICWx1HLOoOY9SHdt8Af3Jnv5c2 krU4kjzlbPT1SGFhjNc1IHlB8Fn2IC4H14vRZQ0ABAW93/AOZ7Re8j5gF 0V9k2EbkLgF5LPkKFAfqbLZXKE1C1223V5F1uxEVuuYcadXk6vHTIwkgJ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DvAABzB2Fa/4cNJK1eGQEBAQEBAQEBAQEBAQcBAQEBAYMRMGZ0JweDVookjl+CAoNKk2cUggIKJYUWAhqERD8YAQEBAQEBAQEBayiFIwEBAQQjETcODAQCAQgRAwEBAQMCIwMCAgIwFAEICAIEDgUIiisQqgOCJ4lIAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4QqgRiDPgGCBxmBDoMvAgKBSQ4CLQ+CcYJlBYpdGJh6AogNjT6CIoYeigmBVYpxglmJQwIRGQGBOwEfOYFQbxU9giqCVAEbgWd4AYovgTOBFwEBAQ
X-IronPort-AV: E=Sophos;i="5.46,378,1511827200"; d="scan'208";a="58636736"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 20:50:00 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0IKnw8K001341 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Jan 2018 20:49:59 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 18 Jan 2018 14:49:58 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Thu, 18 Jan 2018 14:49:58 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "'dhcpv6bis@ietf.org'" <dhcpv6bis@ietf.org>
CC: Ralph Droms <rdroms.ietf@gmail.com>
Thread-Topic: Genart telechat review of draft-ietf-dhc-rfc3315bis-10
Thread-Index: AQHTkIYxRFPUZBJBQE6BsOqvTpKUZaN59X0A
Date: Thu, 18 Jan 2018 20:49:58 +0000
Message-ID: <2b7a72ccd7064bfa922e6b1964e8a199@XCH-ALN-003.cisco.com>
References: <151629840624.3913.708212946982193405@ietfa.amsl.com>
In-Reply-To: <151629840624.3913.708212946982193405@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.196]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcpv6bis/2T0vFWhk_Ltz-icRwSYMvC6MTd4>
Subject: Re: [Dhcpv6bis] Genart telechat review of draft-ietf-dhc-rfc3315bis-10
X-BeenThere: dhcpv6bis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "DHCPv6 \(RFC3315\) bis discussion list" <dhcpv6bis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcpv6bis>, <mailto:dhcpv6bis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcpv6bis/>
List-Post: <mailto:dhcpv6bis@ietf.org>
List-Help: <mailto:dhcpv6bis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcpv6bis>, <mailto:dhcpv6bis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jan 2018 20:50:06 -0000

Another review ... with a lot of comments (mostly minor).

Some comments inline below (BV>).

Again, we probably need to review and formulate a response.

- Bernie

-----Original Message-----
From: Elwyn Davies [mailto:elwynd@dial.pipex.com] 
Sent: Thursday, January 18, 2018 1:00 PM
To: gen-art@ietf.org
Cc: dhcwg@ietf.org; ietf@ietf.org; draft-ietf-dhc-rfc3315bis.all@ietf.org
Subject: Genart telechat review of draft-ietf-dhc-rfc3315bis-10

Reviewer: Elwyn Davies
Review result: Almost Ready

[This is a Last Call Review, not a telechat review].

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-dhc-rfc3315bis-10
Reviewer: Elwyn Davies
Review Date: 2018-01-18
IETF LC End Date: 2018-01-24
IESG Telechat date: 2018-01-25

Summary:  Amost ready.  To the best of my abiity I have done a thorough check of the merging of the various earlier documents into the new -bis and the incorporation of the various Errata.  All seems to be good from this point of view.  I am slightly surprised that two other RFCs (7283 and 8213) were not subsumed into this document.  Both are pure updates of 3315 with some important improvements and are pretty short in themselves.  I also found that the new document did not do a good job on the interactions between relay-agents and servers.  Particularly on the processing of options between relays and servers and details of reception of Relay-forward messages a little more detail would halp naive readers.  Finally the draft has not made much of an effort to support possible alternative security algorithms - IETF policy now encourages protocols to deal with algorithm flexibility  - DHCPv6 as it stands is pretty thoroughly wedded to HMAC-MD5 and would need some (relatively small) IANA improvements plus some thought to cope with different algorithms.  There are also a fair number of nits, partly due to inconsistent cross referencing in s18.

BV> 7283 actually is partially incorporated. RFC 8213 is not "base" protocol; it is optional. The HMAC-MD5 issue was raised in the security review.

Major Issues:
None

Minor Issues:
Non-incorporation of RFC 7283:  Is there a good reason why the update of relay agent behaviour (which is apparently of general application across DHCPv6) is not incorporated into this document as with several other items?  The update is short and would be readily addressed in s19 here.  As it is one is left with another document with some key modifications left around rather than achieving the unification aim of this -bis.

Non-incoporation of RFC 8213:  Similarly regarding use of IPsec for server-relay agent comms.

Definitions of T1 andT2:  I find the definitions of T1 and T2 as replicated in many places to be a little confusing.  T1 and T2 are actually time intervals rather than absolute times.  I suggest a global substitution as follows: OLD:
The time at which the client contacts the server NEW: The time interval after which the client would be expected to contact the server END

BV> Probably worth doing.

s6: Might be worth pointing out the pitfalls of defining additional stateful services as had to be sorted out with RFC 7550.

s11.2: [This is not explicitly an issue with this document, but affects its usage]  The list of hardware types originally listed for ARP, is now well out of date  - in particular it doesn't cover Ethernet interfaces faster than 10Mb/s.  Perhas somebody could suggest some updates to Carlos Pignatoro (the designated expert).

BV> I think a better document to reference is RFC5494.

s12.2:
> A client must create at least one distinct
>    IA_PD.
Is it not the case that the majority of simple hosts are not concerned with IA_PD?  I think this needs qualifying to say that if a client is interested in obtaining a prefix, then it has to create an IA_PD.

BV> Pointed out in security review, yes should be cleaned up.

s18.3, s18.3.11 and s19, Recording and/or reproduction of the relay address chain in servers: I found the lack of description of server handling of received messages embedded in relay-forward messages in s18.3 required considerable searching to understand what needed to be done, and there is no mention of the expectation that the relay address chain would (or at least
might) need to be recorded to facilitate later generation of Reconfigure messages that are originated by the server.  I think it would be helpful to add some words about this is in s18.3 as follows: ADD (probably as new para 6, et
seq):
   All messages sent from clients may arrive encapsulated in Relay-forward
   messages. For example, if client C sent a message that was relayed by relay
   agent A to relay agent B and then to the server, the server would receive
   the following Relay-forward message to process and, in general, generate an
   appropriate Relay-reply to be returned to the client:

      msg-type:       RELAY-FORWARD
      hop-count:      1
      link-address:   0
      peer-address:   A
      Relay Message option, containing:
        msg-type:     RELAY-FORWARD
        hop-count:    0
        link-address: address from link to which C is attached
        peer-address: C
        Relay Message option: <client message>

                      Figure xx: Relay-forward Example

   Thus the server MUST record the sequence of link addresses and peer
   addresses together with their associated hop count values to allow the
   response to the received message to be relayed through the same relay agents
   as the original client message (see Section 19.3).  The server may also need
   to record this information in association with the client's DUID [I think?]
   in case it is needed to send a Reconfigure message at a later time unless
   the server has been configured with addresses that can be used to send
   Reconfigure messages (see Section 18.3.11). For messages that are not
   encapsulated in a Relay-forward message responses will be sent to the source
   address of the received message; this source address becomes the destination
   of the Relay-reply message in the case of Relay-forward messages (see
   Sections 18.3.10 and 18.3.11).
END

BV> Yes, this would not be bad to add. 

s19:  The treatment of additonal options in communications between relay-agents and servers is extremely sketchy.  It appears that extensive use is now made of this capability which was hardly envisaged when RFC 3315 was written.  I think it would be helpful to include a little more information about how this capability is used and maybe pointers to a couple of examples in other RFCs that represent common usages.

BV> In section 13.1, use of these options (in relay-forwards) exists. I'm not exactly sure what we would say as it really depends and this is fairly well understood practice based on v4 and option-82 processing?

s20.4: Possibility of using alternative HMAC algorithms? Whilst it appears that
HMAC-MD5 is still adequate and not significantly compromised, the draft does not make much provision for possible alternatives  (there are  no registries for alternative parameters in the authentication option (Section 21.11) and s20 is restricted to HMAC-MD5.

BV> This does create a backwards compatibility issue if we were to change. RKAP wasn't thought out all that well for negotiating new algorithms (AUTH option for RKAP is sent by server). And, do we really want to do this as it would likely require a new option for client to communicate to server what RKAP algorithms it supports (default would be HMAC-MD5). If this is important, I think it best to do this in a NEW draft.

Nits/editorial:
General: Conventionally tables are given titles and numbers.

s1, para 1: Might be worth adding in a second sentence to clarify the reason for the relay agents: "The basic operation of DHCP provides configuration for clients connected to the same link as the server."

BV> OK.

s1, para 4: s/provide only/deliver nothing but/

BV> OK. 

s1, para 4: Mention that the stateless mode was defined in RFC 3736.

BV> It was really part of 3315 but 3736 was written to make it clear what a minimal stateless implementation was. Perhaps we should say "While stateless was always part of the original RFC3315 specification, RFC3736 explained which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so  that agent can support stateless DHCP." (Or something like that - that is text for 3736.)

s1.1:  It would be helpful to indicate that all the various Errata have been processed and point at
  Appendix A for complete listing of changes.

BV> Yes, we could add the list in Appendix A, as  new item in that list (or add in section 1.1 if list is fairly small).

s1.1, next to last sentence: s/errate filled/errata filed/ s1.1, last sentence: s/aforementioned/the aforementioned/

BV> OK.

s3, para 1:  The main IPv6 specification is now RFC 8200 rather than RFC 2460 [idnits gets very upset!]

BV> I guess we missed that one. Not sure why.

s3, para 2: s/address scope/address scopes/

BV> OK.

s4.2: The term "encapsulated option" is used in several places in this draft and defined in [RFC7227]. It would be good to have a brief introduction here as well as a pointer to Section 9 of RFC 7227.

BV> Have to look into this some more, but should be able to add to list of definitions.

s4.2, "binding":  Probably worth notng that IA* and DUID are defined later in s4.2.

BV> Not sure this is worth it.

s4.2, "relaying": Add "typically conected to different links".

BV> OK

s4.2, "Singleton option": s/a the/a/

BV> OK

s5.3:
OLD:
The client then performs the earlier described two message exchange.
NEW:
The client then performs the two message exchange as described earlier.
END

BV> OK

s6.1, para 1, 2nd sentence: s/Stateless may be used/Stateless DHCP may be used/

BV> OK

s6.3, para 3: s/hence use/hence the use/ (2 places)

BV> OK

s6.3, para 4: s/provided prefixes/provisioned with prefixes/

BV> OK

s6.5, para 1: Is the reference to RFC 3041 essential?  RFC 4941 obsoletes it.
[and idnits enquires]

BV> Probably.

s6.6, para 3: s/to request larger prefix/to request a larger prefix/

BV> OK

s7.2: The references for the DHCP ports at
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=10
are currently associated with  Jim Bound. Unfortunately Jim has passed on many years ago.  I suggest asking IANA to update the references to this new RFC. 
Also the TCP port numbers are reserved for DHCP and are used in other DHCPv6 functions (e.g., RFC5460 but there is no allocation reference. )

BV> We can look at what to do to correct the UDP usage in this document.

ss9.1/9.2: What options might one get along with the encapsulated message?  If so where are they processed?  See the Minor Issue raised against s19 above.

BV> Interface ID is one. So we could always list that (such as the Interface ID Option).

s11.2, para 1:  The reference for hardware types probably ought to be RFC 5494 and it would handy to add in the IANA page address (https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-2).
 As mentioned in Minor Issues, relevant hardware types for higher speed Ethernets (and potentially other types) are missing from this list.

BV> Yes, see earlier. (RFC 3315 used ARP document.)

s14.2:  T1 and T2 are time intervals: s/time(s)/time interval(s)/g

BV> Or we may want to clarify this in the definition of T1/T2. T1 & T2 when sent over the wire are time intervals (from now). How a client or server deal with them internally is up to the implementation. When discussed in this document, they refer to the values being transmitted (interval) or the absolute time when referenced in actions (such as at the T1 time). 

s15: It would help to indicate that specific values for the various retransmission parameters for each message type are given in the sections 18.2.x and use default values taken from the table in s7.6.  Suggest adding after list of variables: ADD:
   Specfic values for each of these parameters relevant to the usages of the
   various messages are given in the sub-sections of  Section 18.2 using values
   defined in the table in Section 7.6.  The selection algorithm for RAND is
   common across all message transmissions.
END

BV> OK. Thanks for text.

s17.2, para 2: s/(ISP network)/(typically, connected to an ISP network)/

BV> OK.

s18, Fig9:  Would client always send request to non-selected server?  And would it renew/release on non-selected server?

BV> Yes, if normal (non-unicast) transmission are used the message goes to both servers (not because they are sent to both explicitly, but because multicast or relay's deliver to both).

s18 (multiple places):  In many places the first reference to an option in a subsection is accompanied by a pointer to the part of s21 that defines it (Good!).  However this is not consistent.  I have picked up several cases where the reference is missing but there may be others.  Please check and make it consistent.  However, in the case of Client Identifier and Server Identifier options and the IA options, they appear so many times that it might be worth just adding a paragraph about the identifiers with the reference pointers in Section 18.

BV> May need to discuss about best policy. Seems best to be consistent so either do it everywhere or nowhere.

s18.1:
> For a rationale of this
>    approach, see Section 4.2 of [RFC7550].
I think the rationale is in s4.3 of RFC 7550.   IMO I think I would have copied
the rationale across - it is short and 7550 is being obsoleted.

BV> Yup, should be 4.3 of 7550. Will have to look at what text to "copy" from 7550.

s18.2, para 3:  The reference to RFC 7550 does not appear to add any value and since this doc is obsoleting RFC 7550 I think the ref should be removed.

BV> OK, will consider.

s18.2, para 5: s/Server Unicast option Section 21.12/Server Unicast option (see Section 21.12)/

BV> For these edits, see above - need to determine whether to include or exclude the references.

s18.2.1, para 6: s/IA Prefix options/IA Prefix options (see Section 21.22)/

s18.2.1, para 10: s/descynronize/desynchronize/

BV> OK.

s18.2.1, para 12 (after retransmit parameters): s/Rapid Commit option/Rapid Commit option (see Section 21.14)/

s18.2.3, para 5: s/IA Address options/IA Address options (see Section 21.6)/

s18.2.4, para 1: s/IA Address options/IA Address options (see Section 21.6)/, s/IA Prefix options/IA Prefix options (see Section 21.22)/

s18.2.9, para 8: s/The client MUST process SOL_MAX_RT and INF_MAX_RT options/The client MUST process SOL_MAX_RT and INF_MAX_RT options (see Sections
21.24 and 21.25)/

s18.2.10, para 2: (same as last comment)

s18.2.10, para 6: s/Client FQDN option/Client FQDN option [RFC4704]/

BV> OK (I think in this case the reference should be there as it is NOT is the bis document)

s18.2.10.1:
>    -  Record T1 and T2 times, if appropriate for the IA type.
The T1 and T2 'times' received in the message are (as mentioned above) are actually intervals:  The client needs to convert these to absolute times in some way (may of course be by setting an interval timer running!) but should the interval just run from the time of receipt of the message - or something more complicated?  This should be noted here.

BV> See above ... we'll have to think on this.

s18.2.10.1, para 19 (I think):
>    -  Sends a Renew/Rebind if any of the IAs are not in the Reply
>       message, but in this case the client MUST limit the rate at which
>       it sends these messages, to avoid the Renew/Rebind storm.
>

The term Renew/Rebind storm is used here just once and without definition.  I am sure that I can see that one might happen but I think the circumstances envisioned need to be spelled out. Maybe already are at the end of s18.2.12?

BV> I think the refers to the following text:
    However, a client MUST rate limit such
   attempts to avoid flooding a server with requests when there are link
   issues (for example, only doing one of these at most every 30
   seconds).
BV> We can also refer them section 14.1 (Rate Limiting)? Or add a comment that retransmitting immediately is unlikely to be of much benefit as it is unlikely that anything different would happen.

s18.3, para 5: s/Option Request option/Option Request option (see Section 21.7)/

ss18.3.1, 18.3.3, 18.3.5, para 1 in each case: s/regardless if/regardless of whether/

s18.3.2, para 6: s/Status Code option/Status Code option (see Section 21.13)/

s18.3.2, para 11: s/Reconfigure Accept option/Reconfigure Accept option (see Section21.20)/

s18.3.3, last para: s/Status Code option/Status Code option (see Section 21.13)/

s18.3.4, para 9: s/Status Code option/Status Code option (see Section 21.13)/

s18.3.5, para 8: s/Status Code option/Status Code option (see Section 21.13)/

s18.3.7, para 4: s/Status Code option/Status Code option (see Section 21.13)/

s18.3.8, para 4: s/Status Code option/Status Code option (see Section 21.13)/

s18.3.9, para 3: s/Reconfigure Accept option/Reconfigure Accept option (see Section 21.20)/

s18.3.9, para 4: s/Option Request option/Option Request option (see Section 21.7)/

s18.3.10, para 2: s/Interface-id option/Interface-id option (see Section 21.18)/

s18.3.11, para 2: Provide a pointer to Section 20 for DHCP Authentication.

BV> OK, probably 20.4 would be best.

s18.2.11, para 5: I suggested in the Minor Issues that some text be added  to
s18 regarding collection of addressing information for use with Reconfigure messages.  If this is done, a pointer back to this text would be useful here.

BV> I don't see such text fitting into 18.2.11 as that is client (which has received Reconfigure). I think you'd want that in 18.3.11. (I suspect that 18.2.11 was just a typo given the ordering of the comments).

s18.4, para 1:  s/Server Unicast option/Server Unicast option (see Section 21.12)/

s18.4, para 2: s/Status Code option/Status Code option (see Section 21.13)/

s19.1, para 1:  As mentioned above (in Minor Issues), I don't see why the essence of RFC 7283 is not incorporated into this document.

BV> See above (seems reasonable).

s20.3: Does there need to be a registry for RDM values?

BV> No because AUTH is probably dead (except for RKAP usage).

s21: Including a general statement that general numeric values are encoded as unsigned integers would be helpful - this is not done consistently through the options at present.

BV> I'm not sure if that adds anything. Also, in most cases whether signed or unsigned matters little (and things like lengths don’t make sense as signed). Certainly hasn't been a an interop issue?

s21.4, last para: s/is taken to ("infinity")/is taken to mean "infinity"/  I think this para would be more useful as the third last para, i.e., moved up two
paras to just after > The values in the T1 and T2 >    fields are the number of
seconds until T1 and T2.

BV> Yes, should add mean and drop parenthesis around "infinity". And moving is OK.

s21.8: The pref_value should be specified as an unsigned integer.

BV> OK, in this case we can say that.

s24: It would probably good to take on the allocations of well-known ports as owned by this document (see comment of s7.2)  For future proofing of authentication, it might be desirable to start registries for some of the  DHCP Authentication parameters.

BV> Yes, we should do that for the ports specified in this document. Not for AUTH parameters.

BV> Note: DHCPv4 AUTH already set up registries in https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml. Perhaps we should add a reference.

s24, Note (4) on Table 1:  Need to make RFC8156 an informative ref.

BV> Yes.

s27.1:  RFC 7083 is being obsoleted... making it a normative reference is not allowed.

BV> Yes, this should be informational.

s27.2: I would say that RFC 8213 needs to be normative unless (as I would
recommend) the text is brought into this document, in which case it is unnnecessary.

BV> No, we want this to be a separate document and not part of the base specification.