[mpls] Re: Review of draft-ietf-mpls-1stnibble-06

[Greg Mirsky <[e-mail]>]

Hi Donald,
thank you for your expedient response. I reverted sortRefs to "true" and
modified the heading as you suggested. Once again, many thanks for your
help in improving this document.

Regards,
Greg

On Wed, Jun 12, 2024 at 4:54 PM Donald Eastlake <[e-mail]> wrote:

> Hi Greg,
>
> The draft you sent looks good, with all the fixes I suggested.
>
> Looking at this, I have two further suggestions:
> 1) I think the references should be in alphanumeric order. I believe you
> can do this by simply adding
>            sortRefs="true"
> as an attribute inside the <rfc ...> element in the xml.
> 2) The current section name for Section 2.4 seems a bit long. Maybe "IP
> Version Numbers versus Post-stack First Nibble" would work.
>
> But these are quite minor and the document looks OK as it is.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>
>
> On Wed, Jun 12, 2024 at 5:58 PM Greg Mirsky <[e-mail]> wrote:
>
>> Hi Donald,
>> thank you for your thorough review and thoughtful comments. Please find
>> my notes below tagged GIM>>. I've updated the document accordingly, please
>> find the new working version and the diff that highlights the updates
>> attached.
>>
>> Best regards,
>> Greg
>>
>> On Tue, Jun 11, 2024 at 1:36 PM Donald Eastlake <[e-mail]> wrote:
>>
>>> Hi,
>>>
>>> I tried to look at this draft with fresh eyes. I think it is technically
>>> sound and a good idea.
>>>
>>> Probably my strongest comment is that, while this draft has a Security
>>> Considerations section, it seems quite weak. How about something more like
>>> the following two paragraphs:
>>>       This document creates a new IANA registry for and specifies
>>> changes to the treatment in the data plane of packets based on the first
>>> nibble of data beyond the MPLS label stack. One intent of this is to reduce
>>> or eliminate errors in determining whether a packet being transported by
>>> MPLS is IP or not. While such errors have primarily caused unbalanced and
>>> thus inefficient multi-pathing, they have a potential to cause more serious
>>> security problems.
>>>       For general MPLS label stack security considerations, see
>>> [RFC3032].
>>>
>>
>> GIM>> Excellent, thank you! Accepted.
>>
>>>
>>>
>>> More minor comments:
>>>
>>> Last line before the 1.1 heading: "determined on the PFN" -> "determined
>>> based on the PFN"
>>>
>> GIM>> Updated accordingly
>>
>>>
>>> Section 2.1.1, point 2, unbalanced parentheses.
>>>
>> GIM>> Cleaned
>>
>>>
>>> Section 2.2, "depend" => "dependent"
>>>
>> GIM>> Done
>>
>>>
>>> Section 2.2: The quoted paragraph from RFCC 4928, its replacement
>>> paragraph, and the OLD TEXT and NEW TEXT below that should all be indented.
>>> I looked at the XML and there do seem to be indent="..." attributes which
>>> has worked for me in the past so I'm not sure what the problem is. Suggest
>>> trying <blockquote>...</blockquote>
>>>
>> GIM>> Strange indeed. I've checked different formats to find out that txt
>> and html work as expected, while htmlized and pdf - don't. I've replaced
>> indents with blockquotes. Please let me know if I got them right.
>>
>>>
>>> Section 2.2: also, it seems like the two substitutions of text in RFC
>>> 4928 should either both use the NEW/OLD TEXT convention or neither of them
>>> should.
>>>
>> GIM>> Does it look right now?
>>
>>>
>>> Section 2.2: The new text for RFC 4928 says "A new document is to be
>>> published". It always seems dangerous to predict the future and, if this
>>> text is adopted and is true, then it won't be true after this "new
>>> document" is published and there will then be an incorrect statement in RFC
>>> 4928 as updated. I'm not sure what would be best here. You could,
>>> presumably, say something like "At the time of this document, it was
>>> planned to ..."
>>>
>> GIM>> Thank you for the suggested text.
>>
>>>
>>> Section 2.3: I guess it's nice to thank IANA but the registry creation
>>> that this document would cause is a routine action for IANA. For drafts
>>> where I am an author, if any individual in IANA makes a suggestion that
>>> improves a draft, I try to add them to the acknowledgements section. But I
>>> don't think it is appropriate to have explicit thanks to the IANA function
>>> for something routine that is done in hundreds or thousands of RFCs,
>>>
>> GIM>> Done
>>
>>>
>>> Section 3.1.1: I don't think this needs to be an extra subsection and it
>>> certainly doesn't need an all capital letters MUST. Suggest just deleting
>>> 3.1.1 and adding the following to the text at the top ov 3,1: "The
>>> assignment policy is Standards Action."
>>>
>> GIM>> Accepted and done.
>>
>>>
>>> Thanks,
>>> Donald
>>> ===============================
>>>  Donald E. Eastlake 3rd   [phone] (cell)
>>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>>  [e-mail]
>>> _______________________________________________
>>> mpls mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>