Re: [dhcwg] Roman Danyliw's No Objection on draft-ietf-dhc-dhcpv6-yang-24: (with COMMENT)

[[e-mail]]

Hi Roman,

First of all, many thanks for the detailed review and my apologies that it’s taken so long for me to
reply.

Please see inline below.

Thanks,
Ian


> On 15. Dec 2021, at 00:06, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-yang-24: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Vincent Roca for the SECDIR review.
> 
> ** (Editorial) Regex constraining hex strings.  When I first read the pattern
> constraining typedef duid-base (and the same is true in other places), I didn’t
> appreciate that this regex was operating on a string containing a hex
> representation of octets.

[if - I’ve added the following text to the ‘duid-base’ description:

Type 'string' is used to represent the hexadecimal DUID value so that pattern constraints can be applied.]

> 
> ** There are a few places in the three yang modules where it appears that
> human-readable messages are being returned.  What is the expected approach (if
> any) for conveying a language tag per the guidance in Section 4.2 of BCP18?  An
> incomplete list of these places are:
> 
> -- Section 4.1. grouping status and status-code-option-group has a leaf message
> 
> -- Section 4.2. rpc delete-address-lease and delete-prefix-lease return a leaf
> return-message
> 
> -- Section 4.3. leaf return-message in the rpcs

[if - I’ve updated each occurrence of ‘return-message’ (2 instances in the server module and 3 in
Relay) with the following:

        description                                                     
          "Response message from the server. If available, a language   
          identifier should be included in the message.";               
        reference "BCP 14 (RFC 2277) IETF Policy on Character Sets         
          and Languages, Section 4.2.";   

RFC2277 has been added to the normative references.]

> 
> ** Section 4.1. grouping status has a leaf message which is explicitly
> described as of “type string” and is clarified as being a “UTF-8 encoded string
> ... that isn’t null-terminated”.  No issues with that guidance.  I’m wonder
> whether the other strings mentioned in the previous comment should also be
> described in this way.

[if - The requirement for the status-message format is taken directly from RFC8415 sec. 21.13.
However,  the return-messages as described above are not defined or mentioned in RFC8415,
As they are implementation specific, no format (or even their availability) can be assumed.]

> 
> ** Section 5.  Additionally threats to document would be:
> 
> -- Generalize the threat of redirecting clients to services under the
> attackers’ control (e.g., DNS server or WPAP).  Say:
> 
> OLD
> * Various attacks based on re-configuring the contents of DHCPv6
>      options, leading to several types of security or privacy threats.
>      For example, changing the address of a DNS server supplied in a
>      DHCP option to point to a rogue server.
> 
> NEW
> * Various attacks based on re-configuring the contents of DHCPv6 options,
> leading to several types of security or privacy threats.  These options could
> redirect clients to services under an attacker’s control. For example, changing
> the address of a DNS server supplied in a DHCP option to point to a rogue
> server.

[if - Changed]

> 
> -- Ability to read the leases from the Server or Relay could help the attacker
> fingerprint device types.
> 
> OLD
> These subtrees and
>   data nodes can be misused to track the activity of a host:
> 
> NEW
> These subtrees and data nodes can be misused to track the activity or
> fingerprint the device type of the host:

[if - Changed]
> 
> 
>