Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)

From: Peter Psenak <[email-masked]>
Date: Tue, 8 Jan 2019 09:13:52 +0100

Hi Benjamin,

please see inline:

On 22/12/2018 15:34 , Acee Lindem (acee) wrote:
> Hi Ben,
>
> See inline.
>
> On 12/21/18, 11:29 PM, "Benjamin Kaduk" <[email-masked]> wrote:
>
>     On Thu, Dec 20, 2018 at 01:07:59PM +0100, Peter Psenak wrote:
>     > Hi Benjamin,
>     >
>     > are you ok with my responses and proposed changed text for the range?
>     >
>     > thanks,
>     > Peter
>     >
>     > On 17/12/2018 12:32 , Peter Psenak wrote:
>     > > Hi Benjamin,
>     > >
>     > > please see inline (##PP):
>     > >
>     > > On 17/12/2018 06:53 , Benjamin Kaduk wrote:
>     > >> Sorry for the slow reply -- you caught me right as I was leaving for
>     > >> vacation.
>     > >>
>     > >> On Wed, Dec 05, 2018 at 09:53:20AM +0100, Peter Psenak wrote:
>     > >>> Hi Benjamin,
>     > >>>
>     > >>> please see inline:
>     > >>>
>     > >>> On 05/12/18 04:44 , Benjamin Kaduk wrote:
>     > >>>> Benjamin Kaduk has entered the following ballot position for
>     > >>>> draft-ietf-ospf-ospfv3-segment-routing-extensions-20: Discuss
>     > >>>>
>     > >>>> When responding, please keep the subject line intact and reply to all
>     > >>>> email addresses included in the To and CC lines. (Feel free to cut this
>     > >>>> introductory paragraph, however.)
>     > >>>>
>     > >>>>
>     > >>>> Please refer to
>     > >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>     > >>>> for more information about IESG DISCUSS and COMMENT positions.
>     > >>>>
>     > >>>>
>     > >>>> The document, along with other ballot positions, can be found here:
>     > >>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/
>     > >>>>
>     > >>>>
>     > >>>>
>     > >>>>
>     > >>>> ----------------------------------------------------------------------
>     > >>>> DISCUSS:
>     > >>>> ----------------------------------------------------------------------
>     > >>>>
>     > >>>> What is the extensibility model for the "AF" (address family) field
>     > >>>> in the
>     > >>>> OSPFv3 Extended Prefix Range TLV?  That is, what do we need to say
>     > >>>> about
>     > >>>> current implementations' behavior to allow future changes?  (I also a
>     > >>>> little bit wonder if we really need a full eight bits, but that's
>     > >>>> basically
>     > >>>> aesthetic.)
>     > >>>
>     > >>> I don't think OSPFv3 will ever support other then IPv6 or IPv4 AF. Also
>     > >>> the text says:
>     > >>>
>     > >>> "Prefix encoding for other address families is beyond the scope
>     > >>>   of this specification."
>     > >>
>     > >> Perhaps it would be better encoded in a 1-bit field (rather than an 8-bit
>     > >> one), then?  That would at least make the (lack of) semantics of the
>     > >> other
>     > >> 7 bits more clear, as the usual "MUST set to zero on transmit and
>     > >> ignore on
>     > >> receipt".
>     > >
>     > > ##PP
>     > > it's too late now to change the encoding. This draft has several years
>     > > of history and there are implementation shipping. Changing the encoding
>     > > would cause the backward compatibility issues.
>
>     I didn't think I was suggesting changing the bits on the wire -- in an
>     8-octet field, we're encoding the values 0 and 1 as:
>
>     00000000
>     00000001
>
>     I'm proposing to change the eight bits to be specified as "the first seven
>     bits are always set to 0 but should be ignored on receipt; the eighth bit
>     represents the 0 or 1 value".  This makes it clear what needs to happen if
>     there's a need to use any of those seven bits (an Update to this document)
>     and also makes it more clear that there are not expected to be any
>     additional AFs defined anytime soon.

currently the draft only supports 0 and 1. It says:

"Prefix encoding for other address families is beyond the scope of this 
specification."

Given that we have other RFCs where 8-bit field is used for AF, can we 
leave it as we have it please?

thanks,
Peter

>
> What would  this accomplish? This seems equivalent to supporting 0 or 1 for an 8 bit field. Are you trying to free up those bits for other purposes? We have other LSRs drafts and RFCs, e.g., RFC 7684, that use this 8-bit AF encoding and I see no value whatsoever in changing it. Please clear the DISCUSS.
>
> Perhaps you should subscribed to the LSR list so that you can apply your protocol encoding expertise to our -00 drafts. Here is the link:
>
>     https://www.ietf.org/mailman/listinfo/lsr
>
> Thanks,
> Acee
>
>
>     Could you help me understand what would be backward incompatible with this
>     proposal?
>
>     > >>
>     > >>>>
>     > >>>> Some of the text in Section 8.1 (see the COMMENT section) reads like it
>     > >>>> might have an "Updates" relationship with other documents, but I
>     > >>>> don't know
>     > >>>> enough to be sure.  Hopefully we can have a conversation to clarify the
>     > >>>> situation.
>     > >>>
>     > >>> please see my comments below.
>     > >>
>     > >> Okay.
>     > >>
>     > >>>>
>     > >>>> ----------------------------------------------------------------------
>     > >>>> COMMENT:
>     > >>>> ----------------------------------------------------------------------
>     > >>>>
>     > >>>> Section 1
>     > >>>>
>     > >>>> Is there a start of the separate document that covers SR with the
>     > >>>> IPv6 data
>     > >>>> plane that we could reference from here?
>     > >>>
>     > >>> this document describes OSPFv3 extension for SR with the MPLS data
>     > >>> plane, not IPv6 data plane. And rfc8402 is referenced.
>     > >>
>     > >> I understand the difference between OSPFv3 SR with MPLS vs. IPv6 data
>     > >> plane
>     > >> (well, at least that there is a difference).  My point is that you say it
>     > >> "will be specified in a separate document".  If there's an existing I-D
>     > >> that is the start of this work, listing it as an informative reference
>     > >> seems helpful to me.  (If there's not, perhaps "at a later date" would
>     > >> work
>     > >> instead of "in a separate document".)
>     > >>
>     > >> But of course this is a non-blocking comment, so feel free to ignore -- I
>     > >> really don't mind.
>     > >>
>     > >>>>
>     > >>>> Section 5
>     > >>>>
>     > >>>>     In some cases it is useful to advertise attributes for a range of
>     > >>>>     prefixes.  The Segment Routing Mapping Server, which is
>     > >>>> described in
>     > >>>>     [I-D.ietf-spring-segment-routing-ldp-interop], is an example of
>     > >>>> where
>     > >>>>     a single advertisement is needed to advertise SIDs for multiple
>     > >>>>     prefixes from a contiguous address range.
>     > >>>>
>     > >>>> I note that the referenced document does not use the word "range" to
>     > >>>> describe the prefix being assigned multiple SIDs; it might be
>     > >>>> helpful to
>     > >>>> say a few more words about how the range of prefixes gets mapped to
>     > >>>> what is
>     > >>>> discussed in the linked document.
>     > >>>
>     > >>>   "prefix being assigned multiple SIDs" - that is not what we are doing
>     > >>> here.
>     > >>
>     > >> Hmm, I must have misspoke; sorry.  My point remains, though, that if I
>     > >> go to
>     > >> I-D.ietf-spring-segment-routing-ldp-interop and search for "range", I
>     > >> will
>     > >> not find anything to help me know which part of that document you are
>     > >> talking about.  I would encourage some additional text to clarify how the
>     > >> terminology used in this document relates to the terminology and work
>     > >> used
>     > >> in the referenced document.
>     > >
>     > > ##PP
>     > > range is not defined in I-D.ietf-spring-segment-routing-ldp-interop,
>     > > it's the SRMS functionality that is defined there.
>     > > The range was defined for IGPs to optimize the encoding for SRMS
>     > > advertisement - with thousands of prefixes the encoding would not scale
>     > > if we advertise the individual SID for every prefix independently.
>     > >
>     > > What about the following updated text in the OSPFv3 draft:
>     > >
>     > > "In some cases it is useful to advertise attributes for a range of
>     > > prefixes. The Segment Routing Mapping Server, which is described in
>     > > <xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>, is an
>     > > example of where SIDs for multiple prefixes can be advertised. To
>     > > optimize such advertisement in case of multiple prefixes from a
>     > > contiguous address range, OSPFv3 Extended Prefix Range TLV is defined."
>
>     That's a big help, at least for me; thanks!
>     I wonder if the first sentence would be better as "useful to advertise
>     attributes for many prefixes at once", but will definitely defer to your
>     judgement of that.
>
>     -Benjamin
>
>     > >>
>     > >>>>
>     > >>>> I'm also not entirely sure how to construct the prefix range just given
>     > >>>> this format description.  Suppose I have an IPv4 prefix of 18.18/16
>     > >>>> and a
>     > >>>> range size of 4; my prefix length is 16 and the address prefix is
>     > >>>> encoded
>     > >>>> as 0x120120000.  Am I then representing the four prefixes 18.18/16,
>     > >>>> 18.19/16, 18.20/16, and 18.21/16?
>     > >>>
>     > >>> yes.
>     > >>>
>     > >>>> Or am I constrained to be a subset of
>     > >>>> 18.18/18 (in which case I don't know what the actual distinct prefixes
>     > >>>> would be)?  The examples in Section 6 suggests the former, but I
>     > >>>> would suggest
>     > >>>> stating this explictly, here.
>     > >>>>
>     > >>>
>     > >>> I would thing that the example in section 16 is clear enough.
>     > >>
>     > >> I generally prefer to describe the normative behavior in actual text
>     > >> description instead of relying on examples to clarify the expected
>     > >> behavior.  That said, this is a non-blocking comment, so feel free to
>     > >> retain the current text.  If you did want to add something, I would
>     > >> propose the strawman:
>     > >>
>     > >> OLD:
>     > >>    The range represents the contiguous set of prefixes with the same
>     > >>    prefix length as specified by the Prefix Length field.  The set
>     > >>    starts with the prefix that is specified by the Address Prefix field.
>     > >>    The number of prefixes in the range is equal to the Range size.
>     > >>
>     > >> NEW:
>     > >>    The range represents the contiguous set of prefixes with the same
>     > >>    prefix length as specified by the Prefix Length field.  The set
>     > >>    starts with the prefix that is specified by the Address Prefix
>     > >> field and
>     > >>    continues with the subsequent prefixes of the same length, forming a
>     > >>    contiguous block of addresses.  Since the Range Size is not
>     > >> restricted to a
>     > >>    power of two, this new block of addresses may not be describable
>     > >> using a
>     > >>    single address prefix/length.  The number of prefixes in the range is
>     > >>    equal to the Range size.
>     > >>
>     > >>
>     > >>
>     > >>>
>     > >>>> Section 6
>     > >>>>
>     > >>>> Should there be any discussion of the historical or future reasons
>     > >>>> why V
>     > >>>> and L are separate flag bits, given that the only legal combinations
>     > >>>> are
>     > >>>> currently 00 and 11, i.e., fully redundant?
>     > >>>
>     > >>> I would rather not get into that discussion here.
>     > >>
>     > >> That's fine, though even just noting the redundancy and that it exists
>     > >> for
>     > >> [historical/...] reasons might help some readers understand more easily.
>     > >>
>     > >>>>
>     > >>>> It may not be necessary to expand ASBR on first usage here, since
>     > >>>> it's in
>     > >>>> the terminology section (and marked as "well-known" at
>     > >>>> https://www.rfc-editor.org/materials/abbrev.expansion.txt).
>     > >>>
>     > >>> ASBR is defined in terminology section.
>     > >>
>     > >> Precisely; you can just use the abbreviation if you want and make the
>     > >> text
>     > >> here shorter.
>     > >
>     > > ##PP
>     > > done.
>     > >
>     > >>
>     > >>>>
>     > >>>>     If the NP-Flag is not set, then any upstream neighbor of the
>     > >>>> Prefix-
>     > >>>>     SID originator MUST pop the Prefix-SID.  This is equivalent to the
>     > >>>>     penultimate hop popping mechanism used in the MPLS dataplane.
>     > >>>> If the
>     > >>>>     NP-flag is not set, then the received E-flag is ignored.
>     > >>>>
>     > >>>> Is it going to be clear that "pop" only applies when this Prefix-SID
>     > >>>> is the
>     > >>>> outermost label?  (Or am I super-confused about how this is supposed to
>     > >>>> work?)
>     > >>>
>     > >>> you can only POP the outmost label.
>     > >>
>     > >> Okay, thanks for confirming.
>     > >>
>     > >>>>
>     > >>>> A similar consideration may apply to the discussion of the NP flag
>     > >>>> as well.
>     > >>>> Also some redundantly expanded ABR and ASBR here as well.
>     > >>>>
>     > >>>>                This is useful, e.g., when the originator of the Prefix-
>     > >>>>        SID is the final destination for the related prefix and the
>     > >>>>        originator wishes to receive the packet with the original EXP
>     > >>>>        bits.
>     > >>>>
>     > >>>> Are we still supposed to call these the EXP bits after RFC 5462?  (I
>     > >>>> had to
>     > >>>> look up what they were; not sure if this means that we should put a
>     > >>>> reference in for them or not, given that I'm not a practitioner here.)
>     > >>>
>     > >>> I can rename to "Traffic Class" if you insist.
>     > >>
>     > >> I do not insist; I'm just trying to understand the common
>     > >> usage/conventions.
>     > >
>     > > ##PP
>     > > it has been updated.
>     > >
>     > > thanks,
>     > > Peter
>     > >
>     > >>
>     > >>>>
>     > >>>>     When the M-Flag is set, the NP-flag and the E-flag MUST be
>     > >>>> ignored on
>     > >>>>     reception.
>     > >>>>
>     > >>>> Do I understand this correctly that this is because the mapping
>     > >>>> server may
>     > >>>> not know the needs of the individual routers, and if the routers had
>     > >>>> specific needs they should advertise the SIDs directly (which would
>     > >>>> take
>     > >>>> precedence over the mapping server's advertisement)?  If so, given the
>     > >>>> following discussion, I wouldn't suggest adding any extra text about
>     > >>>> it,
>     > >>>> but I do want to make sure I'm understanding it properly.
>     > >>>
>     > >>> your understanding is correct. There is also some more details in the
>     > >>> next section.
>     > >>>
>     > >>>>
>     > >>>>     When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range
>     > >>>>     TLV, then the value advertised in the Prefix SID Sub-TLV is
>     > >>>>     interpreted as a starting SID/Label value.
>     > >>>>
>     > >>>> Am I remembering correctly that Prefix-SID can appear multiple times
>     > >>>> within
>     > >>>> OSPFv3 Extended Prefix Range?  Then each Prefix-SID would be
>     > >>>> indicating a
>     > >>>> distinct range but adhering to the same parameters of the range that
>     > >>>> are
>     > >>>> indicated in the Extended Prefix Range TLV?  This seems a little
>     > >>>> weird on
>     > >>>> the face of it (as opposed to a single Prefix-SID sub-TLV per Extended
>     > >>>> Prefix Range), but maybe there's a use case that I'm missing on first
>     > >>>> glance.
>     > >>>
>     > >>> the use case is when you need to advertise Prefix-SID for different
>     > >>> Algorithms.
>     > >>>
>     > >>>>
>     > >>>> Section 7.1
>     > >>>>
>     > >>>> (Probably off-topic: what's the use case for assigning the same
>     > >>>> Adj-SID to
>     > >>>> different adjacencies?)
>     > >>>
>     > >>> load balancing of traffic over multiple links.
>     > >>
>     > >> Thanks for helping me understand better (here and above).
>     > >>
>     > >>>>
>     > >>>> Section 7.2
>     > >>>>
>     > >>>> Perhaps add DR to the terminology section (or expand on first usage)?
>     > >>>
>     > >>> ok, will do.
>     > >>>
>     > >>>>
>     > >>>> Section 8.1
>     > >>>>
>     > >>>>     When a Prefix-SID is advertised by the Mapping Server, which is
>     > >>>>     indicated by the M-flag in the Prefix-SID Sub-TLV (Section 6), the
>     > >>>>     route type as implied by the LSA type is ignored and the Prefix-SID
>     > >>>>     is bound to the corresponding prefix independent of the route type.
>     > >>>>
>     > >>>> Is this considered to be Update-ing the behavior of another RFC?
>     > >>>
>     > >>> no. All we say is that the LSA type in which the SID from SRMS is
>     > >>> advertised does not need to match the route-type of the prefix for which
>     > >>> the SID is adverised.
>     > >>
>     > >> Okay, thanks.
>     > >>
>     > >>>>
>     > >>>>     Advertisement of the Prefix-SID by the Mapping Server using an
>     > >>>> Inter-
>     > >>>>     Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV
>     > >>>>     [RFC8362] does not itself contribute to the prefix
>     > >>>> reachability.  The
>     > >>>>     NU-bit MUST be set in the PrefixOptions field of the LSA which is
>     > >>>>     used by the Mapping Server to advertise SID or SID Range, which
>     > >>>>     prevents the advertisement from contributing to prefix
>     > >>>> reachability.
>     > >>>>
>     > >>>> This MUST reads like it is restating an existing normative
>     > >>>> requirement from
>     > >>>> elsewhere (in which case we should probably just state it as fact and
>     > >>>> provide a reference).  Or is it a new requirement (in which case
>     > >>>> Updates:
>     > >>>> might be in order)?
>     > >>>
>     > >>> not sure I understand. NU-bit is defined in rfc5340. We are just reusing
>     > >>> it here. I can add a reference to it.
>     > >>
>     > >> Thanks for the pointer.  I was wondering whether RFC5340 itself would
>     > >> require the NU bit to be set in this situation -- from a quick skim, it
>     > >> seems that it does not, so there's nothing to do here (other than add
>     > >> that
>     > >> reference, if you want.)
>     > >>
>     > >>>>
>     > >>>>     Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated
>     > >>>> between
>     > >>>>     areas.  Similar to propagation of prefixes between areas, an ABR
>     > >>>> only
>     > >>>>     propagates the OSPFv3 Extended Prefix Range TLV that it
>     > >>>> considers to
>     > >>>>     be the best from the set it received.  The rules used to pick the
>     > >>>>     best OSPFv3 Extended Prefix Range TLV are described in Section 5.
>     > >>>>
>     > >>>> I don't see any usage of "best" in Section 5; I do see direction to
>     > >>>> use the
>     > >>>> numerically smallest Instance ID when multiple Extended Prefix Range
>     > >>>> TLVs
>     > >>>> advertise *the exact same range*.  But this in and of itself does not
>     > >>>> safisfy the claim here that there is guidance to pick a single best
>     > >>>> Extended Prefix Range TLV, so I'm left confused as to what's
>     > >>>> supposed to
>     > >>>> happen.  Perhaps this was intended as a transition to Section 8.2
>     > >>>> instead
>     > >>>> of referring back to Section 5 (especially considering that Section
>     > >>>> 8.1 is
>     > >>>> supposed to be intra-area but this topic is inter-area)?
>     > >>>> (This sort of dangling/unclear internal reference would normally be a
>     > >>>> DISCUSS, but it seems very likely this is just a stale section
>     > >>>> number and
>     > >>>> not a real problem, so I'm keeping it in the COMMENT section for now.)
>     > >>>
>     > >>> right, I will remove the reference to section 5 and correct the text.
>     > >>>
>     > >>>>
>     > >>>> Section 8.4.1
>     > >>>>
>     > >>>> Do we need a reference for 2-Way and FULL?
>     > >>>
>     > >>> these are standard OSPF adjacency states.
>     > >>
>     > >> Okay.  Sorry for my ignorance here (and throughout), and thank you again
>     > >> for your patient explanations of the "basic concepts".
>     > >>
>     > >>>>
>     > >>>> Section 9
>     > >>>>
>     > >>>> I would normally expect some text about "IANA has made permanent the
>     > >>>> following temporary allocations" or similar, so the reader can
>     > >>>> quickly tell
>     > >>>> that this is not a case of codepoint squatting.
>     > >>>
>     > >>> well, I guess what is important is that the IANA allocations has been
>     > >>> made.
>     > >>
>     > >> Indeed.
>     > >>
>     > >> -Benjamin
>     > >> .
>     > >>
>     > >
>     > > .
>     > >
>     >
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Jan 2019 08:19:52 -0600

Hi Acee,

Happy new year; I hope your holidays went well.
(also inline)

On Sat, Dec 22, 2018 at 02:34:37PM +0000, Acee Lindem (acee) wrote:
> What would  this accomplish? This seems equivalent to supporting 0 or 1

This would make it clear that there is not intended to be any extensibility
in the future.

> for an 8 bit field. Are you trying to free up those bits for other
> purposes? We have other LSRs drafts and RFCs, e.g., RFC 7684, that use
> this 8-bit AF encoding and I see no value whatsoever in changing it.

Thanks for the pointer:

%   AF
%      Address family for the prefix.  Currently, the only supported
%      value is 0 for IPv4 unicast.  The inclusion of address family in
%      this TLV allows for future extension.

In particular, the value 0 is not just "IPv4", but "IPv4 unicast", and the
document explictily states that this "allows for future extension"
(presumably to IPv6 unicast or any of various multicast flavors).

With regard to that future extension I see that RFC 7684 is for OSPFv2, but
my quick search at IANA only found a registry for "OSPFv3 Instance ID
Address Family Values"; nonetheless, it does in fact include other entries
for IPv6 and multicast in several combinations.

> Please clear the DISCUSS.

I note that the Discuss is not "encode the AF in a single bit", the Discuss
is "make clear in the document whether this field is extensible, and if so,
how such extensions should be made".  Whether that's only having two
encodable values by virtue of only having a single bit, or an IANA
registry, or a statement to the effect of "only these two values are
defined and no future extension is possible" is not something I care about;
I only care that the actual expected behavior is clearly documented.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Jan 2019 08:33:55 -0600

Hi Peter,

Happy new year, and my apologies to all for the heavy overlap between this
message and the reply to Acee sent just a few moments ago.
(inline)

> "Prefix encoding for other address families is beyond the scope of this 

Well, that would seem to imply that even though this specification doesn't
touch them, there is a possibility of using this for future additional
address families.  So I think you need to say more about where it would be
in scope to do that work; this could involve making a registration in an
IANA registry for new family types, or a future IETF document that updates
this one, or probably some other mechanisms that I'm not thinking of right
now.

> leave it as we have it please?

There are ways to resolve my discuss position that do not involve changing
the encoding or its description, yes.  But see above.

(And it would make the discussion of how to proceed easier if we had a
clear and solid answer about whether future extensions should be permitted
or not.)

-Benjamin

---

From: Peter Psenak <[email-masked]>
Date: Tue, 8 Jan 2019 17:09:01 +0100

Hi Benjamin,

Happy New Year!

Please see inline:

> this one, or probably some other mechanisms that I'm not thinking of right

The document says:

So we do allow new specification to define a new AF if needed for the 
Range TLV. Although we do not see that happening very likely.

> the encoding or its description, yes.  But see above.

so what exactly would help to resolve the discuss?

> clear and solid answer about whether future extensions should be permitted

We are not precluding future extensions to AF if they happen.

thanks,
Peter

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Jan 2019 10:16:21 -0600

> so what exactly would help to resolve the discuss?

Well, there's a few options, and I don't want to try to dictate my
preferences onto your document.  What seems simplest to me would be to just
bite the bullet and establish an IANA registry for these AF values, but if
you wanted to do something else like saying that they are "beyond the scope
of this specification but may occur in future standards-track work" that
would also be fine.  I'm just trying to avoid some reader seeing "beyond
the scope of this specification" and thinking they can do whatever they
want and pick their own codepoint value to squat on.

-Benjamin

---

From: Peter Psenak <[email-masked]>
Date: Tue, 8 Jan 2019 17:58:55 +0100

Hi Benjamin,

> want and pick their own codepoint value to squat on.

would this be fine with you:

"Prefix encoding for other address families is beyond the scope
of this specification. Other address families may be defined in the 
future standard-track IETF specifications."

thanks,
Peter

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Jan 2019 11:38:06 -0600

> future standard-track IETF specifications."

Yes, with or without adding "Prefix encoding for" to the start of the
second sentence; please go ahead and I will clear.

Thank you again for your patience working through this, and my apologies
for the delays.

-Benjamin

---

From: Peter Psenak <[email-masked]>
Date: Wed, 9 Jan 2019 10:28:50 +0100

Hi Benjamin,

> second sentence; please go ahead and I will clear.

I have published a version 23 with the above text.

thanks,
Peter