Subject: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 1 Apr 2020 18:06:45 +0100

Hi all,

As document shepherd I have done another review of this document to see
whether it is ready for working group last call as the authors have 
asked to progress the draft.

Sadly, I don't think this document is ready. The ideas have crystallised
fine, but the write-up here is lacking.

I have a number of small editorials and some larger questions and issues
set out below. I also have one question that has broader scope:

For [IANA-MT] and [IANA-Sub-6] you now have both 'Private Use' and
'Experimental Use'. I struggle to see how this makes sense. The uses
decribed in RFC 8126 are sufficiently similar that it is unusual to
have both categories defined for a single registry. I don't see anything
in the descriptive text in this document that makes clear why you need
both categories and how an implementation would decide which range to
select a code point from.

If we can clean up all these points, the document may be ready.

Best,
Adrian

==

Abstract

s/.././

--

Abstract

"The updates are mostly..."
Text like this always makes me ask, "What about the rest?"

--

All section heading should use capitalisation

--

1.

d/among other things/

--

1.

   RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
   8029, but the registrations can be further clarified and their
   definitions more precise.

Maybe...

   RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
   8029.  This document further clarifies the entries in those
   registries and makes the definitions more precise.

--

1.

   This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by
   updating two groups of registries.

Maybe...

   This document updates RFC 8029 [RFC8029] and RFC 8611 [RFC8611] by
   updating two groups of registries as follows:

--

1.

   First the registries for Message Types [IANA-MT], Reply Modes
   [IANA-RM] and Return Codes [IANA-RC].  The changes to these
   registries are minor.

NEW

   First, the registries for Message Types [IANA-MT], Reply Modes
   [IANA-RM], and Return Codes [IANA-RC] are updated.  The changes to
   these registries are minor.

--

2.

OLD

   o  a small set of code points (4 code points) for experimental use is
      added, actually they are take from the range for "Private Use".

NOTE
The code points are not taken from the range for "Private Use". Rather,
the "Private Use" range is reduced. So...

NEW

   o  a small set of code points (4 code points) for Experimental Use is
      added by reducing the range for "Private Use".

--

2.

   o  In the listing of assignments the term "Vendor Private Use" is
      changed to "Private Use"

I'd move this to the top of the list so that the term "Private Use" has
context when it is used in other bullets.

--

3.

I'm not sure that the text in the base section (i.e., before 3.1) adds
to the document.

--

3.1 first two bullets

s/requires/require/
s/the/they/

However, how I don't see how these bullets belong in this document. What 
do the processing rules have to do with the IANA registries? The
paragraph immediately after the bullets would seem to be enough.

But then I got to Section 4 and discovered that you are also changing 
the use of terminology around mandatory/optional. This goes further 
than the name of the document, the first sentence of the Abstract, and
the whole of the Introduction. So, I think you need to work out what
the document is intended to do (fix the registries, or fix the 
registries *and* fix the descriptions of how parameters are used) and
then clarify the document accordingly.

--

3.1

   Each of the blocks have code point spaces with the following
s/have/has/

--

   The range of each TLV and sub-TLV registry is divided into to blocks,
   one with a range from 0 to 49161 for TLVs and sub-TLVs that require a
   response if not recognized.  Another block in the range from 49161 to
   65535, this block is for TLVs and sub-TLVs that may be silently
   dropped if not recognized.

Are you sure that 49161 shouldn't read 32767 and 32768 in the two cases
here?

s/into to/into two/

--

3.1.1

s/Expereimetal USe/Experimental Use/
s/Privagte/Private/

--

3.1.1

   Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use
   are handled as any other unrecognised TLV or sub-TLV.

   o  If the unrecognized TLV or sub-TLV is from the Experimental Use
      range (37144-37147) or from the Private Use range (31748-32767) a
      the Return Code of 2 ("One or more of the TLVs was not
      understood") will be sent in the echo response.

   o  If the unrecognized TLV or sub-TLV is from the Experimental Use
      range (64512-64515) or from the Private Use range (64515-65535)
      the TLVs SHOULD be silently ignored.

   IETF does not prescribe how recognized or unrecognized Experimental
   Use and Private Use TLVs and sub-TLVs are handled in experimental or
   private networks, that is up to the agency running the experiment or
   the private network.  The statement above relates to how standard
   compliant implementations will treat the unrecognized TLVs and sub-
   TLVs from these ranges.

Firstly, just like the issue with section 3.1, I think you should just
focus on the IANA considerations.

Secondly, this final paragraph seems to say something that may go 
beyond what is in the base RFCs and is an update beyond simply a change
to the IANA section.

But, you could boil this down to a simplified statement of: there are
two sets of ranges, one for "send error if not recognised" and one for
"silently ignore if not recognised". If you do that, then the contents
of 3.1.1 would collapse into 3.1.

--

3.2

OLD
   This section lists the changes to each MPLS LSP Ping Registry, in
   Section 6.1, Section 6.2 and Section 6.3 the changes are detailed and
   it is shown what the IANA registry version of the registration
   procedures and assignments would look like.
NEW
   This section lists the changes to each MPLS LSP Ping Registry.  
   Section 6.1, Section 6.2 and Section 6.3 set out how the new 
   versions of the IANA registries should look, together with the
   registration procedures.

--

3.2.1 

Many of the same issues as shown for Section 2

--

4.

s/ths/that/

--

4.1

s/is nows/is now/

--

4.1

This was presumably a problem in 8029, but perhaps we can fix it here.
You propose...

      TLV and sub-TLV Types greater than or equal to 32768 (i.e., with
      the high-order bit equal to 1) are TLVs and sub-TLVs that SHOULD
      be ignored if the implementation does not understand or support
      them.

You should say under what conditions and how they SHOULD may be varied.
This is probably...

     , but such implementations MAY choose to send an error as it 
     would have done if the high-order bit had been clear.

--

4.1.1 

s/Comments to this changes/Comments to these changes/

s/change in two/changed in two/

--

I stumbled over section 4.1.1. It claims to provide comments on the 
changes and provides three numbered bullet points:
1. This doesn't describe a change
2. This describes two changes
3. Does describe a change, but the text is not clear that it describes
   a change.

--

There is load of duplication in this document because you have:
- some repetition of text from existing RFCs
- duplication between sections describing how the text should look and
  section 6 that instructs IANA

I think you could have trimmed this substantially by:
- simply pointing at the relevant section of the updated RFC
- explaining what you want to change
- pointing at the relevant piece of section 6 for the new text

Result:
- shorter draft
- less scope for errors

--

The whole of section 4.2 (including 4.2.1) says "changes aligned with
the rest of this document" but doesn't actually say what the changes
are.

--

4.2.1

s/tu return am/to return an/
s/ir only/only/

However, that whole paragraph seems to be missing meaning.

--

5.

   This document only updates IANA registries, not how the code-points
   in the registries are used.  This should not create any new threats.

The first sentence seems to be false. That is, you are also updating the
terminology to clarify the rules about when a TLV or sub-TLV can be
ignored if it is not understood.

However, this is a good thing for security because it makes it more 
likely that implementations will be consistent and harder to attack.

--

6. It would be really nice if the whole of section 6 could refer to
registries using precise names (probably in quotes). You want IANA to
be easily able to find the right registries.

--

6.

   IANA is requested to update the LSP Ping name space as described in
   this document and documented in the Appendixies.

What Appendixies?

--

6.1

The captions for the tables are at best confusing, but probably wrong.

--

6.2

Consistent with the comment for section 6, this whole section is very
confusing! Are you actually asking IANA to do anything in this section?

--

In section 6.3, I can't parse what you asking IANA to do.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 1 Apr 2020 17:57:30 +0000

Thanks Adrian for the thorough review and great comments!

On your broader-scope question, I see the difference in definition of private-use versus experimental-use, but I tend to agree with you that for this use case they are overlapping in intent or need.

My view would be to keep only Experimental Use.

Thanks,

Carlos.

> 2020/04/01 午後1:06、Adrian Farrel <[email-masked]>のメール:
> 
> Hi all,
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 2 Apr 2020 18:31:20 +0800

Adrian,

This is to address your comment on "Private Use" and "Experimental Use",
we will review the rest of the comments and update as needed.

> Hi all,
<snip>
> select a code point from.
<snip>

You are right I've been struggling with these two type of code points
also, but came to a slightly different conclusion than you did.

RFC 8126 says:

4.1.  Private Use

    Private Use is for private or local use only, with the type and
    purpose defined by the local site.  No attempt is made to prevent
    multiple sites from using the same value in different (and
    incompatible) ways.  IANA does not record assignments from registries
    or ranges with this policy (and therefore there is no need for IANA
    to review them) and assignments are not generally useful for broad
    interoperability.  It is the responsibility of the sites making use
    of the Private Use range to ensure that no conflicts occur (within
    the intended scope of use).

    Examples:

       Site-specific options in DHCP [RFC2939]
       Fibre Channel Port Type Registry [RFC4044]
       TLS ClientCertificateType Identifiers 224-255 [RFC5246]

4.2.  Experimental Use

    Experimental Use is similar to Private Use, but with the purpose
    being to facilitate experimentation.  See [RFC3692] for details.
    IANA does not record assignments from registries or ranges with this
    policy (and therefore there is no need for IANA to review them) and
    assignments are not generally useful for broad interoperability.
    Unless the registry explicitly allows it, it is not appropriate for
    documents to select explicit values from registries or ranges with
    this policy.  Specific experiments will select a value to use during
    the experiment.

    When code points are set aside for Experimental Use, it's important
    to make clear any expected restrictions on experimental scope.  For
    example, say whether it's acceptable to run experiments using those
    code points over the open Internet or whether such experiments should
    be confined to more closed environments.  See [RFC6994] for an
    example of such considerations.

    Example:

       Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP
       Headers [RFC4727]

It seems to me that "Private Use" are intended for private networks,
where care is taken that the code points are not leaked into the
Internet, but there the network itself is a production network, that
will be run for an unforeseeable amount of time. And that "Experimental
Use" code points are for short lived experiments.

This is different.

I'm very uncertain whether it is sufficiently different to motivate two
different types. If the working group thinks there should be only one
code point, I would argue to keep the code points for "Experimental
Use". If we converge on "one type of code point only, I think this has
a wider impact than this document, and we should probably update RFC
8126 (again).

I'd like to invite comments on this on the mpls wg list.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Apr 2020 12:13:41 +0100

Thanks Loa,

I agree with your interpretation of 8126.

I think that the challenge with "experiments on the open Internet" is that the experiments have to have built into them some way to protect against two experiments using the same codepoint. That's not usually done in my experience, meaning that the two allocation classes are often pretty similar. Maybe there is some difference in duration of the use of a code point.

I'd certainly be happy with collapsing these registries to use just one range. I would say that keeping the resulting range small (just a few code points) is desirable.

Best,
Adrian

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: 02 April 2020 11:31
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Review of draft-ietf-mpls-lsp-ping-registries-update-01

Adrian,

<snip>
<snip>

RFC 8126 says:

4.1.  Private Use

    Examples:

4.2.  Experimental Use

    Example:

This is different.

/Loa

--

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 2 Apr 2020 18:38:08 +0000

> 2020/04/02 午前7:13、Adrian Farrel <[email-masked]>のメール:
> 
> Thanks Loa,
> 

+1

Thanks,

Carlos.

---

From: Loa Andersson <[email-masked]>
Date: Fri, 3 Apr 2020 14:23:43 +0800

Carlos and Adrian,

So for the current draft I'll use "Experimental Use" and remove "Private
Use", my rationale for that is that I get questions about "Experimental
Use", but so far has had no question of "Private Use".

Working Group,

Please comment on this, either support or objections.

/Loa
for the co-authors

--

---

From: tom petch <[email-masked]>
Date: Fri, 3 Apr 2020 16:00:29 +0000

From: mpls <[email-masked]> on behalf of Loa Andersson <[email-masked]>
Sent: 03 April 2020 07:23

Carlos and Adrian,

Working Group,

<tp>

I think that you should keep both since they have different uses.  Experimental is for us, the IETF, if we cannot quite make up our minds how to proceed yet.
Private use is for an organisation or group thereof to go their own way and fork from the work of the IETF.  This is not desirable but history shows that it happens and I think that MPLS OAM is an area where the chances of this are higher than with some IETF protocols.
If there is no private use, then such an organisation will camp on the Experimental which generates a problem for deployed code.

TP

/Loa
for the co-authors

--

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Mon, 6 Apr 2020 13:14:40 +0800

Tom,

Interesting, looks like we need to continue the discussion on this for a
while.

Working group,

Please respond to this question:

For the LSP Ping registries do we need both the "Experimental Use" and
"Private Use" allocation policies? If we do not need both, which can be
dropped?

/Loa

PS

I have had a DOS attack against my mail server, it took us three days to
fix everything.

--

---

From: Mach Chen <[email-masked]>
Date: Wed, 8 Apr 2020 02:10:06 +0000

Hi all,

Although I think the probability of using "Private Use" is low, I incline to agree with Tom here. It's safer to keep both the "Private Use" and "Experimental Use". And since we have been along with them for so many years, seems it's no harm to keep keeping them. 

Regards,
Mach 

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Monday, April 6, 2020 1:15 PM
> To: tom petch <[email-masked]>; Carlos Pignataro (cpignata)
> <[email-masked]>; Adrian Farrel <[email-masked]>
> Cc: mpls <[email-masked]>; [email-masked]
> Subject: Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01
> 
> Tom,
> 
> Interesting, looks like we need to continue the discussion on this for a while.
> 
> Working group,
> 
> I have had a DOS attack against my mail server, it took us three days to fix
> everything.
> 
> > So for the current draft I'll use "Experimental Use" and remove
> > "Private Use", my rationale for that is that I get questions about
> > "Experimental Use", but so far has had no question of "Private Use".
> >
> > Working Group,
> >
> > I think that you should keep both since they have different uses.
> Experimental is for us, the IETF, if we cannot quite make up our minds how to
> proceed yet.
> > Private use is for an organisation or group thereof to go their own way and
> fork from the work of the IETF.  This is not desirable but history shows that
> it happens and I think that MPLS OAM is an area where the chances of this
> are higher than with some IETF protocols.
> > If there is no private use, then such an organisation will camp on the
> Experimental which generates a problem for deployed code.
> >
> > TP
> >
> > /Loa
> > for the co-authors
> >
> >>> I think that the challenge with "experiments on the open Internet" is
> that the experiments have to have built into them some way to protect
> against two experiments using the same codepoint. That's not usually done
> in my experience, meaning that the two allocation classes are often pretty
> similar. Maybe there is some difference in duration of the use of a code point.
> >>>
> >>> I'd certainly be happy with collapsing these registries to use just one
> range. I would say that keeping the resulting range small (just a few code
> points) is desirable.
> >>>
> >>
> >> +1
> >>
> >> Thanks,
> >>
> >> Carlos.
> >>
> >>> Best,
> >>> Adrian
> >>>
> >>> To: [email-masked];
> >>> [email-masked]
> >>> Cc: [email-masked]
> >>> This is to address your comment on "Private Use" and "Experimental
> >>> Use", we will review the rest of the comments and update as needed.
> >>>
> >>>> I have a number of small editorials and some larger questions and
> >>>> issues set out below. I also have one question that has broader scope:
> >>>>
> >>>> 'Experimental Use'. I struggle to see how this makes sense. The
> >>>> uses decribed in RFC 8126 are sufficiently similar that it is
> >>>> unusual to have both categories defined for a single registry. I
> >>>> don't see anything in the descriptive text in this document that
> >>>> makes clear why you need both categories and how an implementation
> >>>> would decide which range to select a code point from.
> >>> <snip>
> >>>
> >>> You are right I've been struggling with these two type of code
> >>> points also, but came to a slightly different conclusion than you did.
> >>>
> >>> RFC 8126 says:
> >>>
> >>> 4.1.  Private Use
> >>>
> >>> will be run for an unforeseeable amount of time. And that
> >>> "Experimental Use" code points are for short lived experiments.
> >>>
> >>>
> >>> This is different.
> >>>
> >>> I'm very uncertain whether it is sufficiently different to motivate
> >>> two different types. If the working group thinks there should be
> >>> only one code point, I would argue to keep the code points for
> >>> "Experimental Use". If we converge on "one type of code point only,
> >>> I think this has a wider impact than this document, and we should
> >>> probably update RFC
> >>> 8126 (again).
> >>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Apr 2020 09:39:09 +0100

Hi Mach,

I thought the whole reason we had this document was because what we have had
for so many years is wrong.

If the argument is that "we have been doing it for a long time and it hasn't
caused any problems" then let's abandon this draft and spend our time more
profitably!

However, I believe that Loa makes a good argument that the draft is needed,
and we should take that opportunity to work out what we really want.

Now, a very strong argument from anyone would be "we're already using code
points from this part of the registry, please don't mess with it".

Best,
Adrian

-----Original Message-----
From: Mach Chen <[email-masked]>
Sent: 08 April 2020 03:10
To: Loa Andersson <[email-masked]>; tom petch <[email-masked]>; Carlos
Pignataro (cpignata) <[email-masked]>; Adrian Farrel
<[email-masked]>
Cc: mpls <[email-masked]>;
[email-masked]
Subject: RE: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

Hi all,

Although I think the probability of using "Private Use" is low, I incline to
agree with Tom here. It's safer to keep both the "Private Use" and
"Experimental Use". And since we have been along with them for so many
years, seems it's no harm to keep keeping them.

Regards,
Mach

> Subject: Re: [mpls] Review of
draft-ietf-mpls-lsp-ping-registries-update-01
while.
> I have had a DOS attack against my mail server, it took us three days to
fix

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Apr 2020 17:56:30 +0800

Adrian,

I think both you and Mach are in part wrong. 

First, the way the registries has been causing problems. 

Second, as for Experimental and Private Use we have not had that. 

Third, some of us has been confused thinking that code points assigned by Experimental RFC are experimental code points.

Fourth, we should take the time necessary to get this right. 

Five, it is likely that that the next version on the document will only address part of the comments from Adrian, especially the idea that we need to condense the document into less text. 

/Loa 

Sent from my iPhone

> On 8 Apr 2020, at 16:39, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Mach,
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Apr 2020 18:34:23 +0800

Adrian,

inline please

> paragraph immediately after the bullets would seem to be enough.

The problem is that the code points have been named based on the
processing rules.

/Loa

-- 

My mail server it uner a DOS attack, we are working to fix it but it
may take some time.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Apr 2020 18:38:46 +0800

All,

The first bullet were not clear.

> First, the way the registries has been causing problems.

First the way the registries has been set up have caused problems.

/Loa
>>> Cc: mpls <[email-masked]>; draft-ietf-mpls-lsp-ping-registries-update@ietf

--

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 8 Apr 2020 17:13:46 +0000

Adrian,

My view and preference is that, as per truth #12 in [1]:

   (12) In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away.

We can support existing and future uses with Experimental ranges only.

That said, if you find solid arguments to keep both, I’m also OK.

Thanks,

Carlos.

[1] https://tools.ietf.org/html/rfc1925#section-2

2020/04/08 午前4:39、Adrian Farrel <[email-masked]<mailto:[email-masked]>>のメール:

Hi Mach,

Best,
Adrian

-----Original Message-----
From: Mach Chen <[email-masked]<mailto:[email-masked]>>
Sent: 08 April 2020 03:10
To: Loa Andersson <[email-masked]<mailto:[email-masked]>>; tom petch <[email-masked]<mailto:[email-masked]>>; Carlos
Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>; Adrian Farrel
<[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

Hi all,

Regards,
Mach

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Monday, April 6, 2020 1:15 PM
To: tom petch <[email-masked]>; Carlos Pignataro (cpignata)
<[email-masked]>; Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>; draft-ietf-mpls-lsp-ping-registries-update@ietf.
org
Subject: Re: [mpls] Review of
draft-ietf-mpls-lsp-ping-registries-update-01

Tom,

Working group,

/Loa

PS

From: mpls <[email-masked]> on behalf of Loa Andersson
<[email-masked]>
Sent: 03 April 2020 07:23

Carlos and Adrian,

Working Group,

<tp>

I think that you should keep both since they have different uses.
Experimental is for us, the IETF, if we cannot quite make up our minds how
to
proceed yet.
Private use is for an organisation or group thereof to go their own way
and
fork from the work of the IETF.  This is not desirable but history shows
that
it happens and I think that MPLS OAM is an area where the chances of this
are higher than with some IETF protocols.
If there is no private use, then such an organisation will camp on the
Experimental which generates a problem for deployed code.

TP

/Loa
for the co-authors

Thanks Loa,

similar. Maybe there is some difference in duration of the use of a code
point.

I'd certainly be happy with collapsing these registries to use just
one
range. I would say that keeping the resulting range small (just a few code
points) is desirable.

+1

Thanks,

Carlos.

Best,
Adrian

-----Original Message-----
From: Loa Andersson <[email-masked]>
Sent: 02 April 2020 11:31
To: [email-masked];

Adrian,

<snip>

I have a number of small editorials and some larger questions and
issues set out below. I also have one question that has broader
scope:

RFC 8126 says:

4.1.  Private Use

    Private Use is for private or local use only, with the type and
    purpose defined by the local site.  No attempt is made to prevent
    multiple sites from using the same value in different (and
    incompatible) ways.  IANA does not record assignments from
registries
    or ranges with this policy (and therefore there is no need for
IANA
    to review them) and assignments are not generally useful for
broad
    interoperability.  It is the responsibility of the sites making
use
    of the Private Use range to ensure that no conflicts occur
(within
    the intended scope of use).

    Examples:

4.2.  Experimental Use

    Experimental Use is similar to Private Use, but with the purpose
    being to facilitate experimentation.  See [RFC3692] for details.
    IANA does not record assignments from registries or ranges with
this
    policy (and therefore there is no need for IANA to review them)
and
    assignments are not generally useful for broad interoperability.
    Unless the registry explicitly allows it, it is not appropriate
for
    documents to select explicit values from registries or ranges
with
    this policy.  Specific experiments will select a value to use
during
    the experiment.

    When code points are set aside for Experimental Use, it's
important
    to make clear any expected restrictions on experimental scope.
For
    example, say whether it's acceptable to run experiments using
those
    code points over the open Internet or whether such experiments
should
    be confined to more closed environments.  See [RFC6994] for an
    example of such considerations.

    Example:

       Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and
TCP
       Headers [RFC4727]

This is different.

/Loa

--

--

--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 16 Apr 2020 19:08:16 +0800

Working Group,

This is kind of a "Half-Way Inn"-point for updating the shepherd 
comments on draft-ietf-mpls-lsp-ping-registries-update-01. I have
discussed with Adrian and we have agreed on doing the update in two
steps. First everything but the Experimental and Private Use issue.
Tha will be done in the next version waiting for the discussion in
the working group to conclude, and (at least for myself) understanding
if there would be a problem removing e.g. "Private Use".

The draft is available at:

https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/

SHOULD
------

One thing I have done (after discussing with the Shepherd) is to
address an issue I have always had with "SHOULD". In this document we
say that if a node receives a MPLS  Echo Request message (with the high
order bit set)  that is not understoods or found to be in error, the
node should silently ignore the the TLV or sub_TLV and step over it.

SHOULD indicates that there are other options, but RFC 8029 does not say
anything about the options. We now suggest that the option available are
to send an error message in reply.

The suggested text for this is:

    An implementation that does not understand or support a received
    TLV or sub-TLV with Type greater than or equal to 32768 (i.e., with
    the high-order bit equal to 1) SHOULD ignore and step over the TLV
    or sub-TLV, however an implementation MAY send an echo response
    with Return Code 2 ("One or more of the TLVs was not understood")
    as it would have doen if the high order bit had been clear.

The text should be added to section 4.1.

This needs to be discussed, the alternative would be to the SHOULD
to a must.

Experimental and Private Use
----------------------------

We also have an open discussion on the code point ranges for
Experimental and Private Use.

When the discussion matures a bit I will discuss with my co-chairs on
a consensus call on Experimental and Private use.

In the mean we can see these responses time this is the first step,
towards a wglc.

/Loa

> If we can clean up all these points, the document may be ready.

done

ok- removed "mostly", I also change "registry" to "name space".
I have done this, but help with spotting further capitalizations
are appreciated.
done + added that we are discontinuing the use of "manadatry" and
"optional" shorthand and instead describe the actions required.

done
>     updating two groups of registries as follows:
done
done
done
done

done - but the second bullet has been removed, and the language for the
two other bullets is changed to match what is proposed in this document.
> then clarify the document accordingly.

The abstract and Introduction has been updated.

done

hmm - you are right, changed
> s/into to/into two/
done

done

done
done
>       would have done if the high-order bit had been clear.

clear

This from section4.1.1 and  4.2.1, I have removed the both section.
> s/change in two/changed in two/

yes, but not that much shorter

The registries changed are
- Message Type
- Reply Mode
- Return Codes
- TLVs
- all the sub-TLV registries, with the exception of sub-TLVs for TLV #9

I think this is clearly documented.

That was residual text, there were appendixies before, but they were 
move in to document.

Can you clarify don't grok!

There are both new code point types and changed registration procedures.

6.2 does registration procedures, 6.3 does the resulting allocation 
after the changes in this document, the first table is for TLVs, the
second for sub-TLVs.

/Loa

-- 

My mail server it under a DOS attack, we are working to fix it but it
may take some time.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Apr 2020 12:06:15 +0100

Thanks Loa, the update is a considerable improvement and addresses many of my review comments. There will be a further pass needed to fix the Swenglish, but we can wait until we have addressed the remaining two big open issues.

> SHOULD
[snip]
> The text should be added to section 4.1.

I see you have already done this.

> This needs to be discussed, the alternative would be to the
> SHOULD to a must.

I like the formulation you have, and I think that a change to "MUST" would be more difficult because it would need a survey of existing implementations to see whether anyone has deviated from the "SHOULD".

> a consensus call on Experimental and Private use.

I don't have much to add to this discussion having already stated my opinion. I don't want to just keep saying the same thing as that doesn't really advance the discussion.

I would like to hear from all of the co-authors as (presumably) they have an opinion about what the document currently contains.

Tom made his view very clear. I don't agree with his view about the principal usage of Experimental codepoints, but I do agree that he has identified a use case.
I think that the distinction of "use on the open Internet" is of limited value in choosing between Experimental and Private Use because in both cases precautions have to be taken to ensure that two distinct implementations don't clash when using a codepoint. Both ranges are safe when used in private networks, but if either is used on the open Internet then some coordination or other mechanism is needed to protect implementations. Often this is handled with a special coding (a signature) behind the codepoint if there is a perceived risk.

I would, of course, also like to know if anyone is using any of the Private Use ranges for anything?

Best,
Adrian