[dhcwg] draft-ietf-dhc-rfc8415bis: normative language, IA Address and option-len

[Jen Linkova <[e-mail]>]

Hello,

While addressing various comments for draft-ietf-dhc-addr-notification
(which is on the Telechat agenda for the next week), we've noticed a
few interesting things in RFC8415/draft-ietf-dhc-rfc8415bis, which I'd
like to bring to the WG attention.

1. Both RFC8415 and draft-ietf-dhc-rfc8415bis are using [RFC2119]
[RFC8174] normative language. However there are 23 cases where 'must'
(lower case) is used (vs 200+ cases of MUST).

The case which concerns me mostly is Section 21.6 (IA Address option). It says:

"The IA Address option must be encapsulated in
   the IA_NA-options field of an IA_NA option (see Section 21.4) or the
   IA_TA-options field of an IA_TA option (see Section 21.5)."

It is not MUST, so, strictly speaking, it's not a normative language.
Now I'm wondering; is it really not mandatory), is it just an
oversight or  was it left untouched in -bis just in case there are
implementations which do not treat 'must' and 'MUST' so changing
'must' to MUST would break them or make them violating 8415bis?

(Sorry if it has been discussed already..)

2. If 'must' in Section 21.6 is actually 'MUST', then
draft-ietf-dhc-addr-notification clearly violates it: that draft is
using IA Address option in ADDR-REG-INFORM and ADDR-REG-REPLY w/o any
encapsulation.

Shall we rephrase section 21.6 to smth like:

"The IA Address option is used to specify an address associated with
an IA_NA or an IA_TA.  In that case the IA Address option must be
encapsulated in
   the IA_NA-options field of an IA_NA option (see Section 21.4) or the
   IA_TA-options field of an IA_TA option (see Section 21.5).  The
   IAaddr-options field encapsulates those options that are specific to
   this address.
IA Address option MAY be used with or without encapsulation in other
options and messages, when an address needs to be specified."

Another possible action plan would be to wait 6 days and if
draft-ietf-dhc-addr-notification is approved for the publication, add
a reference to 8415bis (AFAIR it was proposed before but at that time
there was a risk of delaying 8415bis by doing so).

3. Last but not least...Another point raised during
draft-ietf-dhc-addr-notification review is that we do specify how the
sender shall set the option-len (MUST be zero) but we do not specify
the behaviour on the receiving side, if that MUST is violated. The
current text is consistent with 8415 - I could not find any text there
specifying the behavior for unexpected option-len value.  I assume
it's intentional, as per the robustness principle - but I'd like to
confirm.

Thanks!

-- 
Cheers, Jen Linkova