Re: [babel] 6126bis: new appendix

["STARK, BARBARA H" <[e-mail]>]

Editorial comments in-line.
Barbara  

>    The protocol defined in this document is a successor to the protocol
>    defined in [RFC6126] and [RFC7557].  While the two protocols are not
>    entirely compatible, the new protocol has been designed so that it
>    can be deployed in existing RFC 6126 networks without requiring a
>    flag day.
> 
>    There are two optioal features that make the new protocol

optioal ->optional

>    incompatible with its predecessor.  First of all, RFC 6126 did not
>    define Unicast hellos (Section 3.4.1), and an implementation of RFC

Should RFC 6126 be [RFC6126]? Same comment for all references.

>    6126 will mis-interpret a Unicast Hello for a Multicast one; since
>    the sequence number space of Unicast Hellos is distinct from the
>    sequence space of Multicast Hellos, sending a Unicast Hello to an
>    implementation of RFC 6126 will confuse its link quality estimator.
>    Second, RFC 7557 did not define mandatory sub-TLVs (Section 4.4);
>    thus, an implementation of RFCs 6126 and 7557 will not correctly
>    ignore a TLV that carries an unknown mandatory sub-TLV; depending on
>    the sub-TLV, this might cause routing pathologies.
> 
>    An implementation of this specification that never sends Unicast
>    Hellos and doesn't implement any extensions that use mandatory sub-
>    TLVs is safe to deploy in a network in which some nodes implement the
>    old protocol.
> 
>    Two changes need to be made to an implementation of RFCs 6126 and
>    7557 so that it can safely interoperate in all cases with
>    implementations of this protocol.  First, it needs to be modified to
>    either ignore or process Unicast Hellos.  Second, it needs to be
>    modified to parse sub-TLVs of all the TLVs that it understands and
>    that allow sub-TLVs, and to ignore the TLV is an unknown mandatory

is -> if 

>    sub-TLV is found.  It is not necessary to parse unknown TLVs, since
>    these are ignored in any case.

Suggestion: ", since these are ignored in any case" -> "that are ignored"

>    There are other changes, but these are not of a nature to prevent
>    interoperability:
> 
>    o  the conditions on route acquisition (Section 3.5.3) have been
>       relaxed;
> 
>    o  route selection should no longer use the route's sequence number
>       (Section 3.6);
> 
>    o  the format of the packet trailer has been defined (Section 4.2);
> 
>    o  router-ids with a value of all-zeros or all-ones have been
>       forbidden (Section 4.1.2);
> 
>    o  the compression state is now specific to an address family rather
>       than an address encoding Section 4.5;
> 
>    o  packet pacing is now recommended (Section 3.1).
> 
> _______________________________________________
> babel mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Ww-
> PiMuGBmrgnsxmDiWQjuvjD2a3d9sjPHErqmsKK4o&s=YwB1wNm3C00CXoHIB
> 0D-3MnLvK2IgsV59pdDIEETajI&e=