[manet] Re: Mahesh Jethanandani's Discuss on draft-ietf-ma net-dlep-traffic-classification-13: (with DISCUSS and COMMENT )

"Black, David" <[email protected]>
Newsgroups gmane.ietf.manet
Message-ID <MN2PR19MB40451A207A02F5C3EA992DA883A12@MN2PR19MB4045.namprd19.prod.outlook.com>
I believe that all of the concerns that I had raised have been resolved, on the IETF last-call email list, please see:


  *   https://mailarchive.ietf.org/arch/msg/last-call/3gjsbVaePVUxLoZiwJfcqpEPlMc/ ; and
  *   https://mailarchive.ietf.org/arch/msg/last-call/pg2j-7cf2Z8NTijU5JhOtht35oM/ for the related flow-control draft.

Thanks, --David

From: Don Fedyk <[email protected]>
Sent: Thursday, March 27, 2025 8:40 AM
To: The IESG <[email protected]>; Mahesh Jethanandani <[email protected]>; Black, David <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: Mahesh Jethanandani's Discuss on draft-ietf-manet-dlep-traffic-classification-13: (with DISCUSS and COMMENT)


[EXTERNAL EMAIL]
Hi Mahesh

We have addressed the Nits but I will give a bit of background on your other DISCUSS comment -The comment is not actually on the traffic classification document but the mostly the Flow control document.
I believe the issues were addressed,  but agree the email chain does not have closure. See [Don] below, but I have also copied David just in case.

Thanks


________________________________
From: Mahesh Jethanandani via Datatracker
Sent: Thursday, February 6, 2025 4:32 PM
To: The IESG
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Mahesh Jethanandani's Discuss on draft-ietf-manet-dlep-traffic-classification-13: (with DISCUSS and COMMENT)

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-manet-dlep-traffic-classification-13: 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/about/groups/iesg/statements/handling-ballot-positions/ [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!LpKI!lGGUlhXA9NShvLKFe9saTImwPGPL99a5nNuM8pn03MiknHLGS_asr8kMl_hRC0uD7vhZZ7IIrTQUJOU$>
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-traffic-classification/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-manet-dlep-traffic-classification/__;!!LpKI!lGGUlhXA9NShvLKFe9saTImwPGPL99a5nNuM8pn03MiknHLGS_asr8kMl_hRC0uD7vhZZ7II1E92zQU$>



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"Abstract", paragraph 0
>    This document defines a new Data Item for the Dynamic Link Exchange
>    Protocol (DLEP) to support traffic classification.  Traffic
>    classification information identifies traffic flows based on frame/
>    packet content such as destination address.  The Data Item is defined
>    in an extensible and reusable fashion.  Its use will be mandated in
>    other documents defining specific DLEP extensions.  This document
>    also introduces DLEP Sub-Data Items, and Sub-Data Items are defined
>    to support DiffServ and Ethernet traffic classification.

I would note that both RTGDIR and TSVART's early review of the document had
issues with the document. However, I did not see a Last Call or Telechat review
of the same. But this could easily have been missed because there are four
documents, and some of these issues could have been debated as part of the
other documents. Even otherwise, there is no e-mail thread that I could find
that discusses how the issues were resolved. In either case, it would be nice
to know from the Shepherd that the issues raised by David Black were addressed,
and more specifically how they were addressed.

[Don]
There was a period of several meetings where David had expressed some concerns
and Lou (and other authors) had discussed them.
 It was my recollection at the time that David Black
Was satisfied before we moved on. But I cannot find a final email - it may have been verbal.

Last message I see is March 12th 2024  from David Black



Lou,



I think we're close to done.  There are a few more things that need attention:



i) The security considerations text was only updated in the flow-control draft.  The other 3 drafts need corresponding security considerations text updates.

[Don] This section has been updated several times now.



ii) A diff of da-credit-extension-15 against -12 reveals a couple of updates at the end of section 3 (Management Considerations) that need to be applied to ether-credit-extension-03 .

[Don] This checks out as being done.



iii) New text in section 2.3.2 of the flow control draft: "TIDs in different Credit windows must not overlap."

That text solves the problem that it was intended to address, but raises a couple of secondary concerns:

    - Which entity checks for overlaps?  I think it's the modem.

    - What happens if overlaps are found?  I think it a suitable "you got it wrong" DLEP error goes back to the router and either the overlapping TIDs or all TIDs in the message (which one?) are not used.

   A sentence or two should be added to explain.

[Don] The modification in the draft after this comment draft-ietf-manet-dlep-credit-flow-control-14 has:

    If a router

    determines that a newly received Data Item results in credit windows

    with overlapping TIDs, the Data Item MUST be treated as an error as

    described above.



Which addresses the comment.





Finally, in looking back on all the emails, I want to record here that item [H] on amount of imprecision (e.g., what does "significantly different" mean?) was not pursued in revising the drafts as your email characterized that as implementation dependent.  That seems ok to me, as this is a modem implementation decision on how aggressive the modem chooses to be in protecting its resources.





Thanks, --David




----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) [github.com]<https://urldefense.com/v3/__https:/github.com/larseggert/ietf-reviewtool)__;!!LpKI!lGGUlhXA9NShvLKFe9saTImwPGPL99a5nNuM8pn03MiknHLGS_asr8kMl_hRC0uD7vhZZ7II8kss548$>, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.


Section 2, paragraph 2
> fic Classification Data Item This sections defines the Traffic Classification
>                                   ^^^^^^^^
Consider using the singular form after the singular determiner "This".

Section 6.2, paragraph 1
> ritical to the acceptance of DLEP. We morn his passing on November 23, 2023.
>                                    ^^^^^^^
s/morn/mourn/

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.