Re: [babel] WG Last Call for draft-ietf-babel-source-specific (2018-03-26 to 2018-04-09)

[Toke Høiland-Jørgensen <[e-mail]>]

Denis Ovsienko <[e-mail]> writes:

>  ---- On Sat, 02 Jun 2018 09:05:01 +0100 Matthieu Boutier <[e-mail]> wrote ---- 
> [...]
>
>  > > (Is it correct that the model in this specification treats 0/0
>  > > same as any other source prefix, it is just the encoding
>  > > convention that 0/0 is always represented with the absence of the
>  > > sub-TLV? If so, it could be helpful to acknowledge this point in
>  > > the document for clarity.)
>  >  
>  > Thanks, this was not said explicitly in the protocol operation. 
>
> Hello all.
>
> This is an comment for the whole working group, not just Matthieu.
>
> The quote above discusses a property of the
> draft-ietf-babel-source-specific WG document, in that its protocol
> encoding potentially provides one way to represent a route that is not
> source-specific, and 6126bis by definition provides another. This
> document contains normative text that specifies which of the two
> potential encodings must be used on the wire, so that the
> implementations remain compatible.
>
> Having studied the document, on 28 May 2018 I suggested that the
> normative text is not clear enough in this regard. Matthieu agreed and
> on 2 June 2018 pushed a commit that among other changes elaborated how
> this document encoding relates to the encoding of 6126bis:
>
> https://github.com/jech/babel-drafts/commit/801c205e5d9a9cdd22f6d51ba7ca45f28ffbf81f
>
> The document remained unchanged until 28 June 2018, when Juliusz
> committed a change reverting this clarification in this document,
> without providing any comments in the commit message or on the mailing
> list:
>
> https://github.com/jech/babel-drafts/commit/03c04b619eecf51011f7e0549ef1e7bb330680da

Eh? That latter commit looks like a purely stylistic change. The text
still says this:

"A node obeying this specification MUST NOT send a TLV with a
zero-length source prefix: instead, it sends a TLV with no source prefix
sub-TLV. Conversely, an extended implementation MUST interpret an
unextended TLV as carrying a source prefix of zero length. Taken
together, these properties ensure interoperability between the original
and extended protocols (see <xref target="compatibility"/> below).</t>"

> I am spelling those details on the list as they have an effect on the
> quality of a specific deliverable by the Babel WG.

No, they don't...

-Toke