Subject: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 19 Apr 2017 04:31:43 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6man-rfc2460bis-09: Discuss

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-6man-rfc2460bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm changing this discuss because I believe changes regarding any text in
section 4.8 would mostly be editorial at this point if any. I would still
like to see more background information explaining the situation and
risks, rather than just giving a general recommendation that might even
out-date in cases routers get updated accordingly in future.

However, I holding this discuss, because the ECN issue I originally only
raised as a question in the comment section really needs to be addressed.
Hope to wrap this up soon.

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

My discuss was mainly on text in section 4.8 (also based on the tsv-art
review -> Thanks Martin!):

I find the recommendation to basically just not use hop-by-hop headers in
section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't it
be maybe time to just deprecate the current hop-by-hop number an assign a
new one? I know that also has deployment problem but maybe it's worth a
try. I guess the assignment could happen in a new document though, but
the deprecation could be done here.

This related to this comment from Martin's review, also proposing a
potential way forward:
"- Section 4.8. "Defining New Extension Headers and Options":
It says new hop-by-hop headers must never ever defined. This is
problematic, as this closing the door forever, even if future instances
of the IETF do would like to wish to define new hop-by-hop headers. A
better way would have to say "that new hop-by-hop headers must have IETF
consensus".

- Section 4.8. "Defining New Extension Headers and Options":
Also the „not recommended“ to define new extension headers looks strange,
especially with the phrase "There has to be a very clear justification".
The term "clear justification" is not an exact engineering specification.
Why not using "technical protocol specification and real word use case
required, plus IETF consensus"?"

As a side note, there is at least one experimental RFC that defines a
destination option to be inspected by a network device, given the know
problems of hop-by-hop option which renders them unusable.

One question because I'm not sure if I interpret this correct to make it
part of my discuss:
Section 4.5: "The number and content of the headers preceding the
Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet."
Does this mean the ECN codepoint (part of the Traffic Class field) is
copied from the first fragment? This doesn't seem to be correct, however,
also not sure what the correct answer is. I know this was not changed in
this revision but maybe we can still get this right.