[Last-Call] Re: Opsdir last call review of draft-ietf-mpls-1stnibble-10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Thanks Greg, the proposed changes look much better.

BTW: Sorry for late follow up.

 

-Qin

发件人: Greg Mirsky [mailto:gregimirsky@xxxxxxxxx]
发送时间: 2024年11月12日 16:36
收件人: Qin Wu <bill.wu@xxxxxxxxxx>
抄送: ops-dir@xxxxxxxx; draft-ietf-mpls-1stnibble.all@xxxxxxxx; last-call@xxxxxxxx; mpls@xxxxxxxx
主题: Re: Opsdir last call review of draft-ietf-mpls-1stnibble-10

 

Hi Qin,

I hope that your travel from Dublin was light and untroubled. I've uploaded the new version that includes all the updates we've discussed:

 

I hope that the updates addressed your concerns. Please let me know if you have any questions.

 

Regards,

Greg

 

On Wed, Nov 6, 2024 at 11:44 AM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:

Hi Qin,

thank you for the discussion. Please find my follow-up notes below tagged GIM2>>.

 

Regards,

Greg

 

On Sun, Nov 3, 2024 at 8:24 AM Qin Wu <bill.wu@xxxxxxxxxx> wrote:

Thanks Greg for clarification, please see follow up comment below.

 

发件人: Greg Mirsky [mailto:gregimirsky@xxxxxxxxx]
发送时间: 2024年10月31日 18:58
收件人: Qin Wu <bill.wu@xxxxxxxxxx>
抄送: ops-dir@xxxxxxxx; draft-ietf-mpls-1stnibble.all@xxxxxxxx; last-call@xxxxxxxx; mpls@xxxxxxxx
主题: Re: Opsdir last call review of draft-ietf-mpls-1stnibble-10

 

Hi Qin Wu,

thank you for your thorough review and thoughtful comments. Please find my notes below tagged GIM>>.

 

Regards,

Greg

 

On Thu, Oct 31, 2024 at 6:14 AM Qin Wu via Datatracker <noreply@xxxxxxxx> wrote:

Reviewer: Qin Wu
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document specifies the new IANA registry for the first Nibble Following a
Label Stack. In addition, this document provide requirements for registering
new values and recommendation for MPLS packet processing. This document is well
written and is on the right track, however, I do have a few comments for
questions and clarifications:

 

1. Abstract Abstract said: “this memo sets out
some documentation requirements for registering new values. Finally, it
provides some recommendations that make processing MPLS packets easier and more
robust.” Abstract also said: “This document updates RFC 4928 by deprecating the
heuristic method for identifying the type of packet encapsulated in MPLS.” I am
wondering whether deprecating the heuristic method for identifying the type of
packet encapsulated in MPLS is seen as recommendation or requirements, if yes,
is such duplicated?

GIM>>  The deprecation of the heuristic method is formulated as the requirement in the following in Section 2.1.1.1:

   Furthermore, the heuristic of guessing

   the type of the embedded packet, as discussed above, SHOULD NOT be

   used.

I hope that clarifies the relationship between the deprecation and the requirement.

 

2. Abstract Some place in the abstract uses the term "This
memo", some place in the place uses the term "this document", the same comment
is applied to the introduction section, suggest to make these terms consistent?
Suggest to use the term "This document".

GIM>> These terms, 'memo' and 'document', have been used interchangeably in RFCs. For example, RFC 2223 says, "This memo provides information for the Internet community." I hope you agree to both terms' current use in the draft.

[Qin] Is using ‘memo’and ‘document’interchangeably best practice today? I feel this is old fashion, never used

In the latest RFCs today. You can see only IETF draft boiplate will use memod, e.g.,”status of memo”.

GIM2>> A good question, thank you. Frankly, I don't know if there's a formal guidance regarding the use of either term. Perhaps we can rely on the RFC Editor guidance. WDYT? 

 

3. Section 1 Introduction said: “ This
memo introduces a requirement and a recommendation. The first builds on Section
2.1.1, and the second deprecates the use of the heuristic in Section 2.1.1.1
and recommends using a dedicated label value for load balancing. ” Abstract
also said: “ this memo sets out some documentation requirements for registering
new values. Finally, it provides some recommendations that make processing MPLS
packets easier and more robust. ” How many requirements and recommendations are
specified by this document, one or many, it looks the abstract is not consist
with Introduction for this. Secondly, where these requirements and
recommendations are documented? Only section 2.1.1 and section 2.1.1.1, or we
have some other sections? My suggestion is to have two clear sections to
document requirements and recommendations separately.

GIM>> The document addresses two areas:

·         load-balancing

·         use of post-stack first nibble

For the former, as noted in "This memo introduces a requirement and a recommendation," the draft formulates one requirement and one recommendation. For the latter, it includes additional requirements. Grouping requirements in one section would mix what is being discussed, which might confuse a reader. I hope we can maintain the document's current organization unchanged.

[Qin] My Concern is as the first reader of this document, the abstract lacks consistency with introduction on how many recommendations and requirements are documented.

e.g., in the introduction, at least you can add some text to say:

OLD TEXT:

“This memo introduces a requirement and a recommendation.

”

NEW TEXT:

“This memo firstly introduces a requirement and a recommendation in section xxx.

”

OLD TEXT:

“

This document updates [RFC4928] by deprecating the heuristic method
   for identifying the type of packet encapsulated in MPLS.

 

”

NEW TEXT:

“

This document further updates [RFC4928] by deprecating the heuristic method
   for identifying the type of packet encapsulated in MPLS in section xxx.

 

”

I also feel it lack clarity to mix rationale with recommendations and requirements, what do you think about this?

GIM2>> Thank you for the suggested updates. I looked at the current areas you point out, and propose the following updates:

OLD TEXT:

   This memo introduces a requirement and a recommendation.  The first

   builds on Section 2.1.1, and the second deprecates the use of the

   heuristic in Section 2.1.1.1 and recommends using a dedicated label

   value for load balancing.

NEW TEXT:

   Based on the analysis of load-balancing techniques in Section 2.1.1,

   this memo, in Section 2.1.1.1, introduces a requirement that

   deprecates the use of the heuristic and recommends using a dedicated

   label value for load balancing.

END

 

OLD TEXT:

   This document updates [RFC4928] by deprecating the heuristic method

   for identifying the type of packet encapsulated in MPLS.

NEW TEXT:

   Furthermore, this document updates [RFC4928] by deprecating the

   heuristic method for identifying the type of packet encapsulated in

   MPLS.

END

I hope that the proposed updates make the logic clearer to a novice reader.

 


4. Section 3.1
Section 3.1 said:
“
The assignment policy for the registry is Standards Action.
“
Can we add reference for standard action, I think it should be RFC8126.

GIM>> Agree. I added RFC 8126 as an Informative reference.

[Qin]: Why not normative reference, see example in RFC9184.

GIM2>> As Loa explained, the BCP can be either. If IESG reviewers suggest, we will make the reference Normative. 

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux