MAC service data unit: - UtherSRG (talk) 18:30, 12 March 2024 (UTC) [ reply ] Comment : This was deleted via the aforementioned PROD, but then REFUND'd (by me) to draft space so that the requestor could address the notability issue raised in the prod.  That issue has not been addressed, but the requestor moved it to article space.  Requested they move it back to draft, but they declined.  - UtherSRG (talk) 18:30, 12 March 2024 (UTC) [ reply ] Note:  This discussion has been included in the deletion sorting lists for the following topics: Technology and Internet .  UtherSRG (talk) 18:30, 12 March 2024 (UTC) [ reply ] Delete : This is a DICDEF with a photo.  For the two sentences of text, we could add them to another article, but I don't see what the point would be.  And to be honest, I've read these sentences and still have no idea what this article talks about.  Oaktree b ( talk ) 18:52, 12 March 2024 (UTC) [ reply ] Comment from the requester.  MAC service data unit or MSDU is mentioned in Frame aggregation , Protocol data unit , IEEE 802.11e-2005 , Maximum transmission unit , IEEE 802.11n-2009 and Jumbo frame .  I believe there were a few other incoming links before this was deleted via PROD.  Removing this definition from the encyclopedia doesn't seem to serve readers.  If the consensus is that the article needs to be deleted we should look for WP:ATDs to help readers through the jargon soup of computer networking in its absence.  ~ Kvng ( talk ) 19:14, 12 March 2024 (UTC) [ reply ] Keep - Significant coverage in multiple reliable sources.  Here are the first few Books search results: [5] , [6] , [7] , [8] , [9] .  ~ Kvng ( talk ) 19:19, 12 March 2024 (UTC) [ reply ] Comment .  The term is indeed very widely used - and trivial in a proper context, see definition at [10] : in non- OSI model networks (the ones actually used) this is just the data that MAC exchanges with the  application ("user"), or LLC (if there is an LLC sublayer).  Without an explicit context the definitions become hard to understand, like the one here.  To provide context, it is easier to merge someplace where the context is provided, say, into Media access controller .  -- Dimawik ( talk ) 00:04, 13 March 2024 (UTC) [ reply ] Please do ! vote.  I would accept merger into media access controller as WP:ATD .  - UtherSRG (talk) 14:41, 14 March 2024 (UTC) [ reply ] The reason I did not vote is simple: the proper solution involves a lot of work, as it requires describing the overview of the IEEE 802 stack somewhere, with a diagram and names of service units passing through the interfaces.  The best place at this moment is IEEE 802 , but it currently contains very little information and is mostly dedicated (properly) to the standardization group itself.  A new article, similar to OSI model should be written, and this will be a proper place to merge.  It is also possible that links to this non-existent (unless I am missing something) article might actually help to rewrite this article.  I don't mind writing the article ( IEEE 802 reference model ) myself, by I am short on time right now, and the task is non-trivial.  Dimawik ( talk ) 20:19, 14 March 2024 (UTC) [ reply ] We don't have to make things great with this WP:AFD - WP:NOTCLEANUP .  We do want to avoid making things worse.  I agree that this article lacks context and have just tagged it as such.  There is a lot of room for improvement in this area but just deleting bits of it around the edges is not improvement and it is not the Wikipedia way - WP:DEMOLISH , WP:NODEADLINES .  ~ Kvng ( talk ) 01:08, 15 March 2024 (UTC) [ reply ] I agree with your reasoning.  I will add the bare minimum of context right now.  Dimawik ( talk ) 01:42, 15 March 2024 (UTC) [ reply ] Relisted to generate a more thorough discussion and clearer consensus.  Relisting comment: Relisting.  Media access controller is a Redirect so not a proper Merge target.  Would its target article, Medium access control be acceptable or are there more arguments to Delete or Keep this article?  Please add new comments below this notice.  Thanks, L iz Read!  Talk!  18:34, 19 March 2024 (UTC) [ reply ] Relisted to generate a more thorough discussion and clearer consensus.  Relisting comment: Please see previous relisting comment and reply to it.  Please add new comments below this notice.  Thanks, L iz Read!  Talk!  22:40, 26 March 2024 (UTC) [ reply ] @ Liz : , I believe Dimawik already answered that above The proper solution involves a lot of work, as it requires describing the overview of the IEEE 802 stack somewhere, with a diagram and names of service units passing through the interfaces.  There is more than a merge required if we want to cover this subject as part of another article e.g. Medium access control .  ~ Kvng ( talk ) 01:40, 28 March 2024 (UTC) [ reply ] My only question is that a page was being proposed as a Redirect/Merge target article that was a Redirect.  So, I was asking if they wanted that Redirect's target article to be the actual target or whether they would prefer a different target article.  That was my question.  I'd still like to hear from Dimawik and UtherSRG who favored this outcome.  L iz Read!  Talk!  23:32, 28 March 2024 (UTC) [ reply ] Yes, a merge or redirect to medium access control would work for me.  - UtherSRG (talk) 10:02, 29 March 2024 (UTC) [ reply ] @ UtherSRG , would you be able to do that merge?  I find the same issue that Dimawik identified.  Just merging MAC service data unit without providing context would not improve either the source or destination articles.  ~ Kvng ( talk ) 13:45, 29 March 2024 (UTC) [ reply ] No, I won't do the merge.  BLAR is fine for now.  When you or someone else gets the time and patience, they can easily see the info in the history.  - UtherSRG (talk) 17:33, 29 March 2024 (UTC) [ reply ] My suggestion now is to Draftify it.  I will merge the material into (IEEE 802 reference model that I put into my scheduke.  I have made a picture already.  In these coordinates, the MSDU is just the data passing through MSAP.  Dimawik ( talk ) 20:48, 30 March 2024 (UTC) [ reply ] @ Dimawik , Thanks for your interest in helping with this.  Why do you think we need to draftify?  Is there some harm done to readers by leaving it in mainspace until the work can be done?  It seems like it is a likely search term and I think it would be better for readers to see an unfinished article than nothing at all.  Leaving it in mainspace also offers the chance that another expert will see it and help us out with improvements.  ~ Kvng ( talk ) 17:12, 31 March 2024 (UTC) [ reply ] The article as-is is not very helpful, but is indeed not hurtful either.  So your (keep) proposal also makes sense.  Dimawik ( talk ) 03:27, 1 April 2024 (UTC) [ reply ] The above discussion is preserved as an archive of the debate.  Please do not modify it.  Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review ).  No further edits should be made to this page.

Discussion outcome: no consensus