Subject: [babel] Mirja Kühlewind's No Objection on draft-ietf-babel-rfc6126bis-17: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Fri, 07 Feb 2020 02:03:59 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-babel-rfc6126bis-17: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for all the work to address my discuss points. I still think that it is
important for PS spec to normatively define default values as part of the main
spec, also because it is rather uncommon to use normative language in the
appendix. However, there are references to the appendix in all relevant places
in the spec now and I'm okay to clear my discuss on this basis.

Please note that the following comment from my discuss ballot is not fully
addressed: "In section 4.1.1 the update interval needs a lower limit (e.g. 3
seconds) and a recommend default value would be could as well (Note that there
are other part in section 3 where the update value is discussed as well)." We
had a long discuss about this value specifically and the recommended default in
the appendix is fine with me. However, section 4.1.1 does not have a pointer to
the appendix. Further I think it would be appropriate to add a warning here
that low values mean higher network load which can have a negative impact in
certain networks.

-------------------------------
Old comments (here for the record; didn't check these points):

1) While this point might not raise discuss-level, it would probably also be
good to provide more concrete advise on how to implement jitter: Sec 3.1.: “  
A moderate amount of jitter may be applied to packets sent by a Babel
   speaker: outgoing TLVs are buffered and SHOULD be sent with a small
   random delay.”
Sec 4: “a Babel node SHOULD
   buffer every TLV and delay sending a packet by a small, randomly
   chosen delay [JITTER].”

2) Sec 4.1.2. (Router-Id) should probably state again that the router-id is
assumed to be unique within a domain.

3) Sec 4: “The most-significant bit of the sub-TLV, called the mandatory bit,
   indicates how to handle unknown sub-TLVs.”
I would recommend to also indicate this bit in the image.

4) Sec 4.4:
“If a TLV has a self-terminating format, then it MAY
   allow a sequence of sub-TLVs to follow the body.”
Initially I wasn’t quite sure what you wanted to say here. I guess you say that
the length would indicate a larger value that needed for the body and therefore
a subTLV might be present? I recommend to clarify this here a bit.

5) I recommend to move Appendix C (Considerations for protocol extensions) in
the body of the document.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 7 Feb 2020 11:40:58 -0500

Hi Mirja,

Thanks for clearing your DISCUSS.

Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]