Re: [Last-Call] Last Call: <draft-ietf-6man-ra-pref64-07.txt> (Discovering PREF64 in Router Advertisements) to Proposed Standard - PLC consistency

[Alexandre Petrescu <[e-mail]>]

Jen,

Le 07/11/2019 à 10:02, Alexandre Petrescu a écrit :
> 
> 
> Le 06/11/2019 à 21:08, Jen Linkova a écrit :
>> On Wed, Nov 6, 2019 at 6:19 PM Alexandre Petrescu 
>> <[e-mail]> wrote:
>>> draft says:
>>>> Scaled Lifetime field SHOULD by default be set to the lesser of
>>>> 3 x MaxRtrAdvInterval divided by 8, or 8191
>>> 
>>> If MaxRtrAdvInterval is 1 (RFC6275 'Mobile IPv6', radvd.conf)
>>> then the division wont work, so the 'lesser' wouldnt be
>>> computed.
>> 
>> We can add the following text: 'if 3 x MaxRtrAdvInterval  is less
>> than 8 then the Scaled Lifetime field SHOULD by default be set to
>> 1',

Sounds reasonable text resolution, I agree.

>> On the side note: it looks to me that RFC6275 contradicts 'MUST' in
>>  RFC4861:
>> 
>> RFC6275: "Routers supporting mobility SHOULD be able to be
>> configured with a smaller MinRtrAdvInterval value and
>> MaxRtrAdvInterval value.... MinRtrAdvInterval 0.03 seconds,
>> MaxRtrAdvInterval 0.07 seconds" while RFC4861  states that
>> "MaxRtrAdvInterval ..MUST be no less than 4 seconds" and
>> "MinRtrAdvInterval...MUST MUST be no less than 3 seconds").
>> 
>> At the same time RFC6275 is not formally updates RFC4861...

I do not know.

On one hand, I fully agree: RFC6275 does not formally update RFC4861:
there is no "Updates:" tag in its front page.  In that sense one might
think about requesting an Errata for adding such a tag, in the DMM WG.

On another hand, while working with implementation I never cared to
check whether the RFC formally updates one another.  The software _had_
to be updated, yes, but not cared about the RFC because once it's an RFC
one can hardly touch on it.

Alex

>> 
>>> Then, by 'lifetime', in the cited text below and throughout the 
>>> document, one means the 'Scaled Lifetime' of this option, right?
>> 
>> It actually does not matter, as zero Scaled lifetime means zero 
>> lifetime, and non-zero Scaled Lifetime means non-zero actual
>> lifetime.
>> 
>>>> Routers SHOULD check and compare the following information:
>>>> 
>>>> o  set of PREF64 with non-zero lifetime;
>>>> 
>>>> o  set of PREF64 with zero lifetime.
>>> 
>>> Finally, for my curiosity, I wonder what kind of algorithm for
>>> checking is consideredin each case.  Is it a precise checking, or
>>> more relaxed? For example, how does it compare a /96 to a /64
>>> (with a precise checking they cant match, but with a longest
>>> match checking they could); would an absolute or a partial
>>> majority in the set be needed to win the check, etc.
>> 
>> 2001:db8::/96 and 2001:db8::/64 are two different prefixes IMHO. 
>> 'Longest prefix match' etc applies when you are finding a prefix a 
>> particular IP address belongs to, not when you compare two
>> prefixes.
> 
> Ok.
> 
> And with respect to the question of how many members in a set must be
>  equal in order to declare consistency?  All of them?
> 
> Alex
> 
>> Also please note that it's just a check for configuration
>> consistency within a LAN/PvD.
>> 
>>>> 
>>>> Abstract
>>>> 
>>>> 
>>>> This document specifies a Neighbor Discovery option to be used
>>>> in Router Advertisements to communicate NAT64 prefixes to
>>>> hosts.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> The file can be obtained via 
>>>> https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/
>>>> 
>>>> IESG discussion can be tracked via 
>>>> https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/ballot/
>>>>
>>>>
>>>>
>>>> 
No IPR declarations have been submitted directly on this I-D.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ IETF-Announce
>>>> mailing list [e-mail] 
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>> 
>>> 
>>> -- last-call mailing list [e-mail] 
>>> https://www.ietf.org/mailman/listinfo/last-call
>> 
>> 
>> 
>