Subject: Re: [Last-Call] Last Call: <draft-ietf-mpls-lsp-ping-registries-update-06.txt> (Updating the IANA MPLS LSP Ping Parameters) to Proposed Standard

From: tom petch <[email-masked]>
Date: Tue, 26 Jan 2021 12:41:32 +0000

On 12/01/2021 22:15, The IESG wrote:
>
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document: - 'Updating the IANA MPLS LSP Ping
> Parameters'
>    <draft-ietf-mpls-lsp-ping-registries-update-06.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-01-26. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.

A recent IESG queried whether or not IANA could be a Normative 
Reference; this I-D makes me hope that that question is resolved.

Abstract LSP needs expanding, not a starred abbreviation

RSC, DDMAP later, likewise

sun-TLVs appears 37 times; perhaps sub-TLVs

/[[RFC8209]/[RFC8209]/

3.1.1
'will be sent' perhaps MUST be

'may be silently ignored' perhaps MAY

6.1.3
'AM Problem/Delay' OAM?

Tom Petch

> Abstract
>
>
>     This document updates RFC 8029 and RFC 8611 that both define IANA
>     registries for MPLS LSP Ping.  It also updates the description of the
>     procedures for the responses sent when an unknown or erroneous code
>     point is found.  The updates are to clarify and align this name space
>     with recent developments.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 27 Jan 2021 14:47:58 +0800

Tom,

Thanks for comments, see inline.

Adrian,

As Shepherd uou might have an opinion on some of my tampering with the 
text below.

>> of the Subject line to allow automated sorting.

I have started a working copy of the document, and will post when 
Deborah tell me.

> Reference; this I-D makes me hope that that question is resolved.

Yes, we resolved this and the SPL terminology was approved by the IESG 
and the comment from Murray Kucherawy was withdrawn.
> Abstract LSP needs expanding, not a starred abbreviation

Fixed this.

Question: Do you think the document title also need to be updated?
> RSC, DDMAP later, likewise

hmmm, this might be a can of wors, with quite substantial ripple 
effects. But it you insist I can open it  :).

The registry is defined in RFC 8029 with <RFC> (no expansion in it).

The <RSC> is in a part of the registry that isd not changed by this 
document, and there is a clear reference to RFC 8029 where it is 
expanded, so if I don't expand in the registry that in the registry that 
would be an update to RFC 8029 . Doable! But the update/expansion would 
be in a section where RSC (Return Subcode) is already expanded and the 
text of RFC 8029 would flow badly.

There is one more thing that is not intended as a chage, the draft says 
(RSC), but the registry says <RSC>, I have been looing for how to enter 
< and > into xml, but not found it, can someone help?

I'm inclined to not expand <RSC> in the registry, maybe we could add a 
note after the registry with the expansion and referencing the correct 
paragraph in RFC 8029, section 3.1.

DDMAP is the same thing, it is correctly expanded in RFC 8029m which if 
referenced. This is also a part of the registry that has not been changed.

> sun-TLVs appears 37 times; perhaps sub-TLVs

fixed
> /[[RFC8209]/[RFC8209]/

fixed

/Loa
> 'may be silently ignored' perhaps MAY

I would like a second opinion on this, I think this is rather 
description than specification.

> 'AM Problem/Delay' OAM?

fixed

/Loa

-- 

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

---

From: tom petch <[email-masked]>
Date: Wed, 27 Jan 2021 09:36:48 +0000

inline three times

> Question: Do you think the document title also need to be updated?

No.  Title is a identifier, something that should be easy to use, read, 
write, it does not have to be all embracing.  The Abstract on the other 
hand does need to inform, do I want to read on or not?

> effects. But it you insist I can open it  :).

RSC I do not know which is why I latched on to it.  Perhaps the IANA 
registry makes sense without it at all but I would add all the 
abbreviations to the Terminology section of this I-D

> < and > into xml, but not found it, can someone help?

&lt; &gt;
as per RFC2629.  I assume that xml2rfc version whatever we are now up to 
has not changed this; it is the same in HTML which is rather better 
documented (Dummies books are an excellent source)