Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Suresh,
Thanks for your review.
Please see the discussion below.
We have things to talk about.

Al

...
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> * Section 4
> 
> Since this behavior is clearly forbidden in RFC8200 
[acm] 
Although much of the IETF community shares your view,
"forbidden" is much too strong a word to describe this 
sentence/statement in RFC8200

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

"are not" would not translate to "forbidden" in any SDO I know.
I understand that some folks proposed to update the wording to 2119
terms, and were found to be in the rough. Would someone outside IETF
reading RFC8200 interpret this sentence as an absolute requirement?
I won't list the many possible interpretations.


> there is no need to add a
> special case for this (as middleboxes perform any number of 
> transformations that not standards compliant).
[acm] 
Right, but we would want to know those translations happened.
Keep in mind that IPPM is in the measurement business,
and our systems work better if we detect the unexpected.
So, If you are reading the bullet text below as some form of
encouragement to insert/delete headers, it is not. 

> Given that safe header insertion/deletion is a
> hard problem that has not been solved, I would remove this text or
> significantly augment it to describe potential issues that may occur due to
> header insertion/deletion (similar to the sections related to 6lowpan and
> translation).
[acm] 
I think we would be glad to cite several references to cover
the potential issues that you provide, but this bullet point has real 
value to the measurement community.
 
> 
>    o  Extension Header insertion or deletion: Although such behavior is
>       not endorsed by current standards, it is possible that Extension
>       Headers could be added to, or removed from the header chain.  The
>       resulting packet may be standard-formed, with a corresponding
>       Type-P.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> * Section 3
> 
> Please add RFC6398 as the reference for Router Alert as it provides significant
> guidelines regarding usage similar to what RFC7045 does for hop-by-hop
> options.
[acm] 
OK

> 
> * Section 4
> 
> I think this text should be removed
> 
>    [RFC8250] endorses the use of IPv6 extension headers for measurement
>    purposes, consistent with other approved IETF specifications.
> 
> as RFC8250 uses a destination option and defining new extension headers has
> been explicitly recommended against by section 4.8 of RFC8200.
[acm] 
Then how was RFC8250 approved? This RFC was developed in IPPM, too.
We are clearly not on the same page for this topic, and IPPM's 
new charter including In-situ OAM may insert more space between us.

> 
> * Minor
> 
> => The reference for 6lowpan is wrong throughout the document (typo?). It
> should be RFC4944 instead of RFC4494 (which is a crypto spec).
[acm] 
OK
> 
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Dq_PPI7bw5x3XowoNQz62vxNvxK8o
> RsRIikvAT5Hv1I&s=84DjJ_D-LNGA7NE1iHRKnpMOHEQ_0VcYNGt9Iq8YpIo&e=