Re: [ippm] Warren Kumari's No Objection on draft-ietf-ippm-2330-ipv6-05: (with COMMENT)

[Warren Kumari <[e-mail]>]

On Tue, Jun 19, 2018 at 6:38 PM MORTON, ALFRED C (AL) <[e-mail]>
wrote:

> Hi Warren,
> Thanks for your review.
> Let's take a look at your comments.
>
> Co-authors, see Warren's last comment, in particular.
>
> > -----Original Message-----
> > From: Warren Kumari [mailto:[e-mail]]
> > Sent: Monday, June 18, 2018 7:12 PM
> ...
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Rich version of this review at:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__mozphab-
> > 2Dietf.devsvcdev.mozaws.net_D6118&d=DwICaQ&c=LFYZ-
> >
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=G64fdxkDTnWJmF84jgKSBF8S_wrWq
> > gmTfJnCQ7jGiW0&s=Pr5JlVAobowwNzyTQIF_ut6srvRo-hGsprLnyfGh-WA&e=
> >
> > Thank you for writing this. Note that I'm using a new tool for
> > balloting, apologies in advance if it goes Boom!
> > Also apologies for the terseness / tone, still getting use to the
> > tooling, and not sure what shows up where.
> [acm]
>
> Ok. I'm replying the traditional way, but I'll create a login
> (if I can) and try Phabricator, too.
>
>
​I believe that anyone can create a login on this (Mozilla provided)
instance.
It seems to me like it works well, and I think makes reviews and responding
to them friendlier / nicer.

Of course, if you prefer mail, this works too... ​



> >
> > COMMENTS
> > S 1.
> > >      aspects of IP packets can influence its processing during transfer
> > >      across the network.
> > >
> > >      In Section 15 of [RFC2330], the notion of a "standard-formed"
> > packet
> > >      is defined.  However, the definition was never updated to include
> > >      IPv6, as the original authors planned.
> >
> > Nit: This is slightly ambiguous - it is unclear if "As the authors
> > intended, it was not updated", or if the authors planned to update it,
> > and never did.
> [acm]
> I see. How about:
> s/ original authors planned./ authors originally desired to do./
>

​WFM.​



>
> >
> >
> > S 3.
> > >      This suggests we devise a metric or suite of metrics that attempt
> > to
> > >      determine C.
> > >
> > >      Load balancing over parallel paths is one particular example where
> > >      such a class C would be more complex to determine in IPPM
> > >      measurements.  Load balancers often use flow identifiers, computed
> > as
> >
> > I think you might want "load balancers and routers" here. Generally a
> > load-balancer is used to mean something which chooses a server (or
> > cluster of servers) to direct a packet / transaction to. Hashing to
> > choose amongst parallel paths is more likely to be a router (yes, the
> > terminology gets squishy - a router doing this is in fact load-
> > balancing amongst links / paths, but...)
> >
> >
> [acm] Sure, your addition of "and routers" is better, thanks.
>

​Excellent!​



>
> >
> > S 3.
> > >      fields that are used for the forwarding decision, are not known
> when
> > >      measuring the path as a black-box.  Potential assessment scenarios
> > >      include the measurement of one of the parallel paths, and the
> > >      measurement of all available parallel paths that the load balancer
> > >      can use.  Knowledge of a load balancer's flow definition
> > >      (alternatively: its class C specific treatment in terms of header
> >
> > I realize that RFC2330 also used this term, but it was less jarring
> > there (it is also only used once)  - I think that you might want to
> > clarify that "class C" is used here in a different way to "class C
> > addresses".
> >
> > I don't have any text to suggest though...
> [acm]
> I do, earlier in the section:
>
>         This suggests we devise a metric or suite of metrics that attempt
> to
>         determine class C (a designation which has no relationship to
> address
>         assignments, of course).
>

​Oh. Well, there you go then :-) Somehow I'd missed that... ​



> >
> >
> > S 4.
> > >      o  Its total length as given in the IPv4 header corresponds to the
> > >         size of the IPv4 header plus the size of the payload.
> > >
> > >      o  Either the packet possesses sufficient TTL to travel from the
> > >         Source to the Destination if the TTL is decremented by one at
> each
> > >         hop, or it possesses the maximum TTL of 255.
> >
> > I'm confused here - why do you need to add the "or 255 bit"?
> >
> > Are you saying that a IPv4 packet that has a TTL of 255 sent to a
> > destination that is 300 hops away is still "standard-formed"? (not
> > that that would work anyway!)
> [acm]
> Yes, because we may not know the number of hops needed to reach Dest.
> and if we inspect the packet after it has been generated it may
> have the max TTL since it hasn't encountered any decrementing hops.
> >
> > Surely just saying "Either the packet possesses sufficient TTL to
> > travel from the Source to the Destination" is enough? (255, as used by
> > some protocols is more than sufficient for their single hop).
> >
> > This feels like over specifying, leading to confusion.
> [acm]
> Well, I just checked RFC2330, and this TTL bullet is a direct quote.
> Confusion about this has been limited, AFAICT.
>

​Okey dokey.​



>
> >
> >
> > S 4.
> > >         the packet, and the headers appear in the standard-conforming
> > >         order (Next Header).
> > >
> > >      o  All parameters used in the header and Extension Headers are
> found
> > >         in the IANA Registry of Internet Protocol Version 6 (IPv6)
> > >         Parameters, partly specified in [IANA-6P].
> >
> > I'm confused again -- this says that all parameters must be in the
> > "IANA Registry of Internet Protocol Version 6 (IPv6)
> > Parameters". Ok, cool.
> > But which part of that registry isn't specified by
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.iana.org_assignments_ipv6-2Dparameters_ipv6-2Dparameters.xhtml-
> > 3F&d=DwICaQ&c=LFYZ-
> >
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=G64fdxkDTnWJmF84jgKSBF8S_wrWq
> > gmTfJnCQ7jGiW0&s=gtOpgKho-LZA3yORp0NrSwzxLVUdL66yFsnsfj3pYmg&e=
> >
> > (why the "partly")?
> >
> [acm]
> I don't recollect why we said "partly" there.
> But this is recently edited text (Last Call comments, I think)
> and we should be able to resurrect the rationale...
>

​That would be nice -- if there is a problem with the registry, it seems
that we can / should fix it. I'm also not quite sure how I'd determine if
I'm in compliance with the above.

Anyway, all my comments were just comments, thanks for addressing them.
W​



>
> Al
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf